The problem is trying to decide which of these mutable resources are likely to be accessed in a concurrent fashion, provide locks to enforce mutual exclusivity; ensuring no other processes is working from an intermediate, invalid state; and all without becoming deadlocked. Traditional debugging and even test—driven approaches aren’t much help, because the errors are dependent on the order in which the processes are scheduled to be executed; not very repeatable, and certainly not controllable.

So the course left me itching to have a go, but aware that concurrent object oriented development needs to be done in the right language, oh, and very carefully. A little reading around the topic lead me to the idea of immutable state development.

Now in OOP terms an immutable state is not very helpful, nothing much ever happens. We rely on the software state being stored in the attributes of all those objects, and actions being driven by the exchange of messages between them. But in the functional programming paradigm an immutable state is implicit, since the state is stored in the way functions execute each other, and themselves, no data is actually stored in variables. This means that processes can be executed in any order without any danger of seeing an invalid state: no need for any locking and a much simpler programming job!

I’ve only just started investigating these ideas, but with the thrust of computing performance in the direction of multiple processors, either on a single machine or via the ‘cloud’, it seems that concurrent, parallel programming may be very important in the future. A couple of languages I want to check out are Erlang and Clojure. Finally, I found the Ruby on Rails Podcast interview with Jim Weirich an interesting perspective on the programming.