Hold on to that thought. I'll check back in with you in, say, 5 years. By then, we should have all endured enough unnecessary pain to lurch back in the other direction. :)
We're well into the era where scarce computing resources no longer limits us the way they used to. We're over some kind of hump with regards to that. Since computing power is more abundant, the limiting factor we're currently running into has to do with the cognitive overhead incurred by our current tools, since tools always lag behind somewhat. Our current tools are primarily built to be efficient with machine resources, but are not necessarily built to make efficient use of cognitive resources.
As cognitive resources become the bottleneck, it's sensible to invest in tools that decrease cognitive burden. So we're seeing an upswing in popularity with methods and techniques aimed at limiting the amount of unnecessary, incidental complexity generated. "Easier to use" is nice, but "less complex" is imperative right now.
Immutability is one of those techniques that can be leveraged to limit growth of complexity.
>Immutability is one of those techniques that can be leveraged to limit growth of complexity.
What you're saying is perfectly rational, right down to your emphasis on can. I don't take exception to immutability as one tool. My problem is with the notion that it is the only tool and the corollary that mutability is always wrong.
But, from an OOP perspective, modelling state changes is natural and desirable. So mutability seems a sensible default.
It's only the recognition of issues that can arise from state changes that has us wanting to lop off the entire feature. A rather strange and drastic "solution" in my view.
Mutability is a feature, of course. Lots of useful algorithms need mutable data structures (e.g., dynamic programming, unification, etc.), and have no counterparts that rely solely on immutable ones.
However, totally unconstrained mutability is definitely a shortcoming. The ability to look at a type signature and be immediately able to tell what might or might not change is a big win for maintainability, especially in big projects.
By the way, constraining mutability doesn't require a purely functional language. The ML family (Standard ML, OCaml) allows all expressions to have arbitrary side effects (when evaluated), but all values other than reference cells are immutable.
