Wanted: One new computing paradigm : preferably an old one that is known to work but newly packaged up as a shiny new thing

Bill points to hand wringing on the parallel-programming model problem and wonders if it is overblown.

It is a real problem in my opinion. I have been long enough in this game to have realised an unfortunate truth. Namely, that Computer Science fundamentals are re-learned by each new generation in the field. The "science" doesn't seem to move on much in a formal sense. Instead, stories are handed down in an ad-hoc fashion from generation to generation around digital campfires.

If I had a penny for everytime I have witnessed developers falling into well established tarpits related to distributed atomic operations, reliable messaging, pattern matching, O N-squared performance, cyclic graphs, noun/verb conflation etc. etc. etc....The sad thing is that in that penny jar would be a bunch of my own pennies. Although "classically trained" as they say, I carried very little genuinely useful lore into the field.

Anyway, against this slightly depressing backdrop comes the multi-core era and all around us, there will be rampant re-invention and rampant chewing of long known gristle. A lot of it will be brought on by the perceived need to treat multi-core as just a library problem. You can get a library to bail you out of inventing your own math library, so why not just buy or develop a library for multi-core. That way, you get to keep the current paradigm and the current fav programming language and IDE and dev/debugging methods...

Some things I fear developers will re-invent in struggling to fit multi-core into their current tooling world view: Erlang, Occam, Hoare's CSP, Petri Nets, PI Calculus, Queue-based batch processing, parallel statecharts.

They are all coming to Java/C# libraries - and the IDE's that service them - near you soon. In some sense, the arrival of these things "re-invented" in today's OO-languages-of-choice will be real progress. Reason being, there will be literally years of fighting non-determinism with debugging tools first. I shudder at the thought but fear that this is a road that must be travelled.

"'Non-determinism' you say? Surely my wonderful visual IDE debugger has a module for handling that?"

Right.