Folks, There have been tasks looking at using different techniques for concurrent and parallel programming.
I posted one example to the Lambda the Ultimate front page a few months ago. Please see "Is Transactional Programming Actually Easier?": http://lambda-the-ultimate.org/node/4070 Something Alan Kay is fond of asking about is, something to the effect of, What's the ramp-up time for somebody to go from beginner to expert and make big contributions to a specific field? If our only solution today is brute-force reading or re-inventing the wheel, then we're setting the bar too high. A good example here is this discussion. What would you type into Google or even a deterministic symbolic processing engine like Wolfram Alpha, if you wanted to know ways you could measure how "hard" it is to learn a concurrency or parallel programming technique? For example, how would you find the Shalishan benchmarks, or the Parallel Computing Works! report by Geoffrey Fox? What are the odds you would find that stuff there, and not have to re-invent the wheel? Some people focus too much on making education and programming accessible to the masses. It is an equally interesting quesiton in programming pscyhology if we can amplify the thought power of a select few. I believe this latter view gets neglected too much, because we've yet to adjust to the realization that computers can currently -- and will be -- smarter than us going forward. Cheers, John "Z-Bo" Zabroski On Fri, Feb 18, 2011 at 12:16 AM, <o...@cs.otago.ac.nz> wrote: > 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). > >