Immutability

Aside from the case of reads and writes of reference types in the context of concurrency, what's so good about immutability?

No need to have anything beside that, concurrency and parallelism are enough to make immutability "good".
When you're making a calculation in your mind, you don't worry that some of the numbers might be "mutated" or "overwritten" in the process, hence you can perform the operations in any order, or relay some of the subcalculations to other people without caring exactly in what order they perform them. Why should it be different when programming computers?

Immutability is GAY, inbreed is for HOMOSEXUALS

>>1
As >>2-san noted, concurrency is good enough a reason. However the direct consequence of immutability is that it enables referential transparency and memoization.

http://en.wikipedia.org/wiki/Referential_transparency_%28computer_science%29
http://en.wikipedia.org/wiki/Memoization

>>4
What?

Immutability is not a sufficient or even necessary condition for memoization or what you call ``referential transparency''.

For example, I can write a merge sort which modifes all sorts of things (bindings, objects etc.), and every time you give it the same input, it will give you the same output. It will even take the same steps to get to it.

I don't understand your answer at all.

>>4
Memoization is only useful for pure functions, not for non-mutating functions. For instance, if a function doesn't mutate anything, but does print to stdout, then it can't be memoized.
As for referential transparency, it's usually more of a performance overhead than a win - when you're programming sequentially. There's no point in keeping a value in memory if you're not going to come back to it.

http://existentialtype.wordpress.com/2011/04/09/persistence-of-memory/
Notice how the only advantages of immutability he comes up with are the ones having to do with concurrency and parallelism.

Not counting concurrency?
You can share the same copy of a value among all uses of the value. This extends to parts of the value (substrings, subtrees, or tails of lists) and across multiple functions and multiple threads. You have a guarantee from the compiler that the value will always be the same. If that value's a huge array (say, an image file) or binary tree, that's a big savings in memory and time spent making unnecessary copies.

>>8
Obviuously, those cases are trivial. The question of mutability/immutability arises only when you do need to either mutate or transform it. And the transforming approach makes sense only when your data structure needs to have multiple futures. In all other cases mutation is better.