Concurrency and the Core Explosion
An offhand comment in my May 18, 2007 entry gave rise to several interesting emails, all about whether or not concurrency in programming is important. I'll weigh in here with an interesting and perhaps inflammatory opinion:
1. Concurrency is extremely important.
2. It's also conceptually difficult, and we don't have a consensus on the best ways to implement it.
3. C and C++ are not likely to evolve toward concurrency. Pascal could, and should. (Maybe it already has...)
First of all, the backstory: We're running into various inconvenient laws of physics in our quest to make CPUs faster. So instead we're adding entirely separate processor cores, each of which can sustain a completely independent thread of execution. Dual-core CPUs are now commonplace, quad-cores, while still exotic, are here, and we'll have eight or sixteen cores within four years or so. Neato-cool! Now, how do we translate eight cores into faster app response?
Alas, we have almost no idea. Hence point 2: We are linear thinkers in most respects, and the simple concept of carving up what we have always considered a totally linear idea into multiple parallel ideas ties our heads in knots. Note well that there is a subtle but important difference between spawning separate processes to do different things at the same time and recasting a single algorithm so that its work is done in parallel on multiple processors. Both are challenges, but the second challenge is way trickier than the first.
Even the first is gnarly, as anyone who has fooled with threads will attest. Locks and mutexes and semaphores, oh my! I've been poking around online, refreshing my memory with respect to concurrency in programming languages, and there's a lot to see. I learned only yesterday that Ericsson evolved Erlang from an earlier language called Eri-Pascal that was Pascal extended for concurrency. (And Eri-Pascal came out of something even older, called CHILL.) Pascal has a long history of attempts at concurrency, with some of them going back to the early 1970s. (See Concurrent Pascal and Pascal-FC.)
There's a cautionary revelation in seeing Erlang as a child of Pascal: The child doesn't look a great deal like the father. We may not be able to implement safe concurrency by strapping a bunch of new stuff onto existing languages. We may have to go back and re-think a great deal of what we take for granted in programming, which on my early glance appears to be what Ericsson did with Pascal to produce Erlang. Languages with massive installed bases like C, C++, and Java may not have enough wiggle room to evolve toward concurrency. We'll see-and again, a really good concurrent C may look so little like C that C fanatics won't use it. Furthermore, C may be too close to the hardware to gracefully accept the radical semantic changes necessary to support concurrency in a safe and intuitive manner.
I'm still thinking. But if you're a Delphi or Pascal guy, I strongly advise you to study up on the challenges of concurrency, including the Actor Model. Download Erlang and play with it. A new Erlang book from The Pragmatic Programmers will be out in July. Part of Erlang's White Book is available online. The Core Explosion (fortunately not the one that Larry Niven wrote about) will change the way programming is done. Be ready for the change-or better still, be one of the forces that guide it. The language wars are not over, and C may not win the next one.