I recently found this great talk by Rich Hickey (the developer of Clojure):

http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

I think his ideas about immutability are very interesting. One thing I thought about is the cost associated with this. For example, I was considering an image manipulation algorithm. Images can require a lot of storage/memory. I'm sure that a persistent data structure could be devised to allow for efficient manipulation. However, using a mutable data structure and some intelligent logic might still provide an edge in terms of performance, and it is possible this could be quite significant.

On the other hand, there are many other problems in computer science where his ideas would certainly make things easier. In some ways, it seems like mutability could be considered an optimization - maybe sufficient static analysis can produce faster code in this regard.

The concept that everything is an immutable value also intrigues me. We can implement this approach in C++ for example:

class Person {
    public:
        std::string name;
        int age;
    
        Person updateAge (int newAge) {
            Person newPerson = *this;
            newPerson.age = newAge;
        
            return newPerson;
        }
    
        Person updateName (std::string newName) {
            Person newPerson = *this;
            newPerson.name = newName;
            
            return newPerson;
        }
};

Person p;
p = p.updateAge(10).updateName("John D");

We can achieve some of the same semantics proposed by Rich Hickey. The important idea is that ''p'' is never in an inconsistent state, even if accessed from multiple threads.

One initial concern with this approach is the amount of data that is being copied for each state change. In many cases, as proposed by Rich, this can be minimized, however I still wonder weather this can be made as fast as the case where data is mutable. Another thing to keep in mind is that if immutable data makes it easier to create concurrent programs, maybe the end result will be still be reduced processing time.

This article by Ted Leung has a great summary of different kinds of concurrency constructs:

http://www.sauria.com/blog/2009/10/05/the-cambrian-period-of-concurrency/

One language which I find particularly interesting is IO, which supports actor-based concurrency and coroutines. It has first-class support for ''futures'' and asynchronous message sending, which I think is a very interesting concept.

Reia is another interesting language with a focus on immutability and concurrency. It compiles into Erlang abstract format. It has a syntax very similar to ruby, but in many ways more consistent and concise.