Meredydd Luff's is an interesting study and paper. However, (1) The title is explicit that this was about PARALLEL programming, and that's what the task was. The results from a CONCURRENT programming task might well be different. For parallel programming, something like HPJava might be better.
(2) Decades ago, designing Concurrent Pascal, Per Brinch Hansen realised that a huge benefit in writing concurrent code came from the things that the compiler *wouldn't* let you do. He came to despair of getting other language designers to see this. If you take a sequential programming language focussed on smashing variables as its main technique, and you add concurrency features to it (which is pretty much how Java was designed), you get all the old problems as well as all the new ones as well as all the ones resulting from combining them. Part of the reason for the washout in this study must have been the sheer difficulty of doing almost anything in Java, and another large part the difficulty of manually checking for the bad things an issue-aware compiler would have ensured couldn't happen. I mean, how do you write reliable concurrent code in Java without understanding the Java memory model? And how many of us *DO* understand it? (3) About the message passing/actor model: "I do not pretend that this grafting of isolation onto a shared-memory language is an elegant one -- merely that it models the user experience I wished to emulate." But it DOESN'T model the user experience that I get in languages like Occam, Ada, Go, Inferno, Concurrent ML, or Erlang. First of all, in Go, Concurrent ML, Occam, and Erlang, processes are lightweight. i would no more worry about creating a few thousand processes in CML or Erlang than I would about a few thousand interface calls in Java. Second, for all of those languages except Erlang, message sending is type checked. (Sing# does this quite nicely.) But the Java version shown in the paper defers this checking until run time; a string must match a method name. This makes message sending bothersomely slow (instead of pleasantly fast) and dangerous (instead of being exactly as safe as a procedure call). Above all, it doesn't seem to be the message passing approach at all, but rather "information-bearing interrupts". All the languages I mentioned above that support something like message passing have *selective receive*. Information arrives at the receiving process ONLY when it asks for it, only when it's ready for it, and the receiving process can choose exactly which communication channels it is willing to listen to. The paper describes a scheme where the sender *FORCES* a method call in the receiver. This is a very very different model of who is in charge. I would have said that plain old Java processes communicating through ConcurrentLinkedQueue s would be a closer emulation. (Amongst other things, it's type checked.) Are the materials available anywhere? I couldn't see them at http://www.cl.cam.ac.uk/~wmfl2/ -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).
