The problem with threads
A couple of years ago I came across an article on Dr Dobbs Journal about the future of programming in a world of multi-core machines.
It was a refreshing read, that took me back the early 90's at college and to some of the distributed operating system classes I took there. Back then we had a 80 CPU box to play around, the size of a 4U rack more or less (compare to this for fun), so conventional threaded programming was already looked at as "odd".
Recently I came across a paper by Prof. Edward A. Lee called "The Problem with Threads". I had it sitting on my "Things to read"-pile for quite some time until I saw it mentioned on O'Reilly Radar by Nat Torkington.
Its a beautiful read, I highly encourage it to you all. One quote in particular, about threaded programming and the impossibility of creating a correct threaded program make my laugh:
To offer another analogy, suppose that we were to ask a mechanical engineer to design an internal combustion engine by starting with a pot of iron, hydrocarbon, and oxygen molecules, moving randomly according to thermal forces. The engineerâs job is to constrain these motions until the result is an internal combustion engine. Thermodynamics and chemistry tells us that this is a theoretically valid way to think about the design problem. But is it practical?
This paper made me realize that I should probably take my resolution to learn Erlang more seriously.
I mean, I can write code in 6 or 7 imperative languages, but I always avoided functional programming. Yet, reading through the book Concurrent Programming in Erlang I had a lot of fun.
So now, I'm thinking more and more on some of my pet projects and which one I'll write in Erlang, just for kicks. I'm going to read it again to get the core concepts a bit more space inside my head.
Can't wait to see the carbon-version of the new Erlang book.
That, and Harry Potter and the Deathly Hallows, of course....