@bazza: I see what you mean...
Apologies for the earlier flaming. Been twitchy for the last few months. Information overload probably.
>> My whole point is that there's nothing really new to SCALA's concurrency models. Both the Actor and CSP concurrency models date back to the 1970's.
Well ... yes. Although Milner's "Communicating Mobile Processes" added something. No, I haven't managed to fully get through his book yet.
>> CSP encouraged the development of the Transputer and Occam. They were both briefly fashionable late 80's to very early 90's when the semiconductor industry had hit a MHz dead end.
Sure did. I had two of those PC-ISA transputer evaluation boards. The T400 CPU [2 links only] is still in my "collection", not yet encased in lucite.
>> Remember, you only programme concurrent software if you have a pressing performance problem that a single core of 3GHz-ish can't satisfy. But if that's the case, does a language like SCALA (that still interposes some inevitable inefficiencies) really deliver you enough performance?
Mnnno... The trend toward less powerful ("green/power-saving") cores in multicore packages as well the demand for less-specialized applications for which multiple processes make sense (servers that need more than a single event-handling loop for example) pushes in the direction of giving developers tools that enable them to actually exploit all this hardware, with abstractions that are better than the ones standard Java itself provides.
Nothing that could not be had in earlier approaches to be sure (Occam. Limbo. Linda for IPC. Or you could whip our the MPI library), but now the demand for easy multi-processing can be satisfied with something that is in the general orbit of the Java Mass [i.e. runs where the JVM runs, can use the Java libraries, can integrate with existing code, can be sold internally, can be used with a known IDE, has a somewhat familiar syntax] so it's arousing interest.
Thus Scala. A bit further, with less-familiar syntax, Clojure with its "transactional memory". And even further, with less-familiar syntax and on a non-Java VM, Erlang.
>>Wouldn't the academic effort be more effectively spent in developing better ways to teach programmers the dark arts of low level optimisation?
When you write Scala code, it will run on a VM, yes. But then again, the VM will compile it down at runtime, and if you need to, and you can optimize that. If the language-level abstraction is well chosen, that should give you all the optimization you need.
Java developer in a multi-core era:
Communicating Sequential Processes for Java:
Clojure and concurrent programming:
Communicating Mobile Processes. Introducing occam-pi: