Question

Some languages (C# or Java) have immutable strings while others (e.g. Ruby) have mutable ones. What are the reasons behind those desgin choices?

Answer 1

One reason why immutable strings are good is that it makes Unicode support easier. Modern Unicode can no longer fit efficiently into a fixed-size data cell, which kills the one-to-one correspondence between string index and memory address which gives mutable strings their advantage.

---

In the past, most Western applications used single-byte characters (various ASCII-based codings, or EBCDIC…), so you could usually handle them efficiently by treating strings as byte buffers (as in traditional C applications).

When Unicode was fairly new, there wasn’t much requirement for anything outside the first 16 bits, so Java used double-byte characters for its Strings (and StringBuffers). This used twice the memory, and ignored any problems that might occur from Unicode extensions beyond 16 bits, but it was convenient at the time.

Now Unicode is not so new, and while the most-used characters still fit in 16 bits, you can’t really get away with pretending the Basic Multilingual Plane is all that exists. If you want to honestly claim Unicode support, you need either variable-length characters or even larger (32-bit?) character cells.

With variable-length characters, you can no longer index into an arbitrary-length string in O(1) time — barring additional information, you need to count from the beginning to figure out what the N’th character is. This also kills the main advantage of mutable string buffers: the ability to seamlessly modify substrings in place.

Fortunately, most string manipulation doesn’t actually need this modify-in-place ability. Lexing, parsing, and search all proceed on a sequential, iterative basis, from beginning to end. General search-and-replace was never in-place to begin with, since the replacement string doesn’t have to be the same length as the original.

---

Concatenating large numbers of substrings doesn’t actually need modify-in-place to be efficient, either. You do need to be more careful about it, though, since (as others have pointed out) a naive concatenation loop can easily be O(N^2) by allocating a new string for each of N partial substrings…

One way to avoid naive concatenation is to provide a mutable StringBuffer or ConcatBuffer object designed to do concatenation efficiently. Another way would be to include an immutable string constructor that takes an iterator into a sequence of strings to be (efficiently) concatenated.

But, more generally, it is possible to write an immutable string library that efficiently concatenates by reference. This kind of string is often called a “rope” or “cord” to suggest that it is at least a bit more heavyweight than the basic strings it’s composed of, but for concatenation purposes it is much more efficient, since it doesn’t need to recopy the data at all!

The above Wikipedia link says that “rope” datastructures are O(log N) to concatenate, but the seminal paper “Purely Functional Data Structures” by Okasaki shows how to do concatenation in O(1) time.