The Multicore Revolution And Language Design

The software development community is about the fall off a cliff.

  • Single-threaded programs will never run faster than they run today

Think about it: clock speeds have maxed out and no mainstream programming language is automatically parallelizable. Pissing matches about Java versus CLI generics are irrelevant. The Intel and AMD roadmaps show that for the next decade, any real advances in speed will come from programs that can exploit multicore chips. Sure, there'll be incremental improvements, but exploiting Moore's Law will require programs that can split themselves up into fragments.

This will be the theme of the next decade of programming.

I'm utterly convinced of this, as convinced as I was in 1989 that Computer Language magazine needed to embrace object-orientation and event-driven GUI programming and as convinced as I was in 1995, when I was so impressed by the first beta of Java that I quit the publishing industry to develop Internet software.

Every high-paying programming job is going to require exploiting multicore chips. There will certainly be maintenance jobs, there will certainly be niches for low-performing vertical apps, but justifying a six-figure salary as a programmer, designer, or architect will require a mastery of multithreaded application development.

So in terms of analyzing language design for the mainstream, parallelization has to become the central concern, because parallelization is what productivity is going to be about. I started writing this intending to talk about C#'s anonymous delegates and that language's use of references for outer-variable capture. It's an interesting topic, but I wanted to put down the stake on the whole multithreading thing. More tk...