New high-speed computers will have more and more cores as the years go by, and the ramp-up has started and is going very quickly. To take advantage of those processors, some programs will need to use interesting (complicated and novel) concurrency.
But the history of concurrent software is littered with approaches that just turned out to be too hard to use, and the software was slow to develop and very hard to debug. Now that we’re all in the same boat, how do we solve the software problem?
Many language designers think that the answer lies in pure (side-effect free) programming. The best known, and quite practical, languages that are pure are Haskell and Erlang.
But many new languages are arriving based on the idea that you should use mostly side-effect-free code, and then when side-effects are needed, use transactions. This is at least a trend if not a movement or revolution.
When Guy Steele came back from the JAOO Conference, I asked him for a quick report, and he sent me this (very slightly copy edited, used with Guy’s permission):
I was stunned by the end of the first day of JAOO 2008 when I realized that Anders Hejlsberg had given a plenary talk on C#, I had given a talk on Fortress, Bill Venners had given a talk on Scala, and Erik Meijer had given a talk on functional programming, and we had all delivered approximately the same message to this object-oriented crowd: the multicores are coming—no, they’re here—and the only plausible way to deal with them in the long run is to rein in the side effects inherent to the OO point of view and move as much as possible to a functional programming style with mostly-immutable data structures and implicit parallelism.
I am very excited by the new Clojure language, which is a dialect of Lisp based on exactly these same principles. Rich Hickey apparently wasn’t at JAOO, but would have found friends there!
Normally I don’t try to learn a language unless I’m about to actually program in it. But it’s worth learning a language when you pick up fundamental new ideas that might be helpful (or just interesting). Haskell is like that (thanks, Alan Bawden, for letting me know).
If you might have to write highly-concurrent programs in the future, I recommend that you keep your eyes on all this.
