Mental models for concurrency

15 Oct 2014

A couple of weeks ago I was watching Rich Hickey's presentation Are We There Yet?. I'm learning Clojure and this video is a great resource to see the motivation behind it. In this talk, Rich Hickey mentions the ups and downs of Object Oriented Programming, and wonders if this is the best we can do or if we're just too comfortable with the ease that OOP brings to programming.

In OOP we write programs that map the world around us into objects, we give them identities and values and try to control and orchestrate everything. Rick gives the example of a stadium full of people, our programs try to "stop time" and know the state of everything to make decisions ("wait nobody move let me take a picture of the ball in mid-air"), he proposes a better time model that works much more like real life does (observers take pictures and don't try to control or stop anything).

I think changing our mental models is a stepping stone for concurrent (and better) programming. Metaphors are useful in OOP to model the world around us, but maybe we can do better. We can create efficient solutions that work independently from the state of the system (much like a city and the hundreds of departments that run it, each working the details in the small, and yet the big picture somehow works).

OO typically unifies identity and state, i.e. an object (identity) is a pointer to the memory that contains the value of its state. There is no way to obtain the state independent of the identity other than copying it. There is no way to observe a stable state (even to copy it) without blocking others from changing it. There is no way to associate the identity's state with a different value other than in-place memory mutation. In other words, typical OO has imperative programming baked into it! OO doesn't have to be this way, but, usually, it is (Java/C++/Python/Ruby etc).[1]

Just like OOP makes it easy to map the world around us, Clojure enforces writing programs that separate the what of the task being done, from when it gets done.

In Clojure's model, an identity is not a state, it has a state (or multiple states associated). An identity can be in different states at different times, but the identity itself doesn't change.

Clojure's Epochal Time Model

Values never change, new values are functions of old values. The nice thing is that we recognize there will be other participants, and our programs must understand that the best they can get from some identities is a snapshot, since they can get new states.

Notes

  1. Clojure.org - State and Object Oriented Programming