> I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its c

> I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs. However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives: 1. Concurrency in servers 2. Graphical user interfaces 3. exploiting multiple cores for complex parallel computations, like number crunching It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors). However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector. And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure. This is a drawback which is rooted by the implementation. But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.