Why did Matz decide to make Strings mutable default in Ruby?

Question

Reverse this question: Why can't strings be modified in Java and .NET?

Was this choice made in Ruby just because operations (adding, etc.) were efficient in mutable strings, or was there some other reason?

(If it were only efficiency, that would seem strange, since the Ruby design did not seem to give a high premium for effective implementation.)

Answer 1

This is consistent with the design of Ruby, as you have noticed. Immutable strings are more efficient than mutable strings — less copying because strings are reused — but making the job harder for the programmer. Intuitively see strings as mutable - you can combine them together. To deal with this, Java silently translates the concatenation (via + ) of two strings into a StringBuffer object, and I'm sure there are other similar hacks. Instead, Ruby chooses that strings change by default due to performance.

Ruby also has a number of destructive methods, such as String#upcase! that rely on mutable strings.

Another possible reason is that Ruby is inspired by Perl and Perl uses mutable strings.

Ruby has characters and frozen strings, both of which are immutable. As an added bonus, characters are guaranteed to be unique for every possible string value.

Answer 2

These are my opinions, not Matz. For the purposes of this answer, when I say that the language has "immutable strings", this means that all its strings are immutable, i.e. There is no way to create a row that has been modified.

• The "fixed string" construct considers both identifiers (for example, hash keys and other internal VM attachments) and data storage structures. The idea is that it is dangerous for mutable identifiers. For me, this sounds like a violation of a single responsibility. In Ruby, we have a character for identifiers, so strings can act as data stores. It is true that Ruby allows strings to be used as hash keys, but I believe that it is incorrect for the programmer to store the string in a variable, use it as a hash key, and then modify the string. In the mind of the programmer, there is (or should be) a separation of the two uses of strings. Often the string used as a hash key is a literal string, so the likelihood of its mutation is small. Using a string as a hash key is not much different than using an array of two strings as a hash key. As long as your mind is well versed in what you use as a key, then there is no problem.

• Having a row as a data store is useful in terms of cognitive simplicity. Just consider Java and its StringBuffer . This is an additional data structure (in the already large and often unintuitive standard library) that you need to manage if you are trying to perform string operations, such as inserting one row into a specific index of another row. Therefore, on the one hand, Java recognizes the need to perform such operations, but since the programmer is exposed to immutable strings, they had to introduce another structure so that operations could still be possible without forcing us to reinvent the wheel. This puts an additional cognitive burden on the programmer.

• In Python, it seems that the easiest way to insert is to grab the substrings before and after the insertion point, and then merge them around the inserted row. I suppose they could easily add a method to the standard library that inserts and returns a new row. However, if the method is called insert , beginners may think that it mutates the string; to be descriptive, it would have to be called new_with_inserted or something strange. In everyday use, “insertion” means that you change the contents of things inserted in (for example, inserting an envelope into a mailbox changes the contents of the mailbox). Again, the question arises: "Why can't I change the data store?"

• Ruby provides freezing of objects, so they can be safely circumvented without introducing subtle errors. It's nice that Ruby treats strings in the same way as any other data structure (arrays, hashes, class instances); they can all be frozen. Consistency is programmable. Immutable strings make strings stand out as "special" data structures if they are not, if you use them as a data store.