On Thu, 2011-01-13 at 10:34 -0800, Cédric Beust ♔ wrote: [ . . . ] > I am seeing a lot of claims going unchallenged, such as the fact that > the actor model is superior to the traditional java.util.concurrent > API's.
Sadly almost the whole of computing since 1936 has been based on marketing and advocacy research, with (fortunately) some seriously good quality engineering from time to time. Basically there is essentially no science in computer science. So not only is there nothing other than claims that Actor Model is a good thing, there is nothing other than claims that CSP is a good thing, likewise dataflow. In fact there is no experimental evidence that object-oriented is good, that functional is good, or even structured programming. It's all been opinion. And marketing. > I'm keeping my mind open but so far, I haven't seen any blinding proof > of this claim. What I would really like to see is a non-trivial (i.e. > requiring a few hundreds of lines of code to solve) concurrent problem > written with both java.util.concurrent and Actors (might want to throw > in fork-join in there while we're at it) and a tentatively objective > analysis of the pros and cons of each approach, on several axes: > maintainability, testability, readability (more subjective), > debuggability, etc... I'll turn it the other way around: advocates of java.util.concurrent being all that is needed, need to provide proof that, in fact, it is even capable (*). Clearly there needs to be a grid of frameworks and problems with a set of metrics. java.util.concurrent has no special position in this experiment, it's only special position is that it is in the standard distribution. If we can decide on a few problems, and on which version control system to use, it cannot be beyond the wit of Java Posse folk to create a repository with all the necessary code. I have made a start (**) at investigating scaling in a very large number of languages using the problem of calculating PI via quadrature. This is a trivial, embarrassingly parallel problem that is amazingly useful in presentations and training courses, even though it is a microbenchmark with all the problem that brings (***). > My gut feeling is telling me that while the Actor/Immutable/lock free > model appears simpler, it also introduces a radical shift in the way > you implement your solution that might be detrimental to its > maintenance on the long run. At the end, you might end up with a > simple locking model (since there are no locks) but at the expense of > a more spaghetti-ish structure, since all these actors are now sending > asynchronous messages to each other and retracing and debugging such a > flow can be challenging. Personally I challenge that shared memory multi-threading should have the position of orthodoxy that it has managed to acrete to itself. Actor Model is 1973. CSP is 1976-1983. There is the Newsqueak thread of work leading to Go. Threads came later than this: all of these merging models were simply thrust aside by the obsession that 1970s operating systems processes and their inter-process communications systems were too heavyweight and slow -- even though it may have been true, it was no reason to invent shared-memory multi-threading as an application programming necessity. Basically techniques that are necessary in operating systems programming have been forced into applications programming technology where they actually ought to be considered anathema. Hummm . . . I think I am getting close to a rant. Time to stop. > Another gut feeling that I haven't been able to shake off is the fact > that the actor model introduces a single locking choke point (the > inbox queue) while Java's traditional locking approach allows you to > position your lock wherever you want, and over an arbitrarily large > (or small) portion of code. Determining such a locking can be > challenging, but once you've solved that particular problem, it's hard > for me to imagine that there are more optimal ways of solving this > problem. So use Dataflow instead. Just because Actor <odel is getting a lot of airplay just now doesn't mean its the only alternative. And of course there is CSP which actually has a mathematical underpinning, unlike every other of the alternatives. For me Actor Model is getting to much mind set, others viable models need a go to avoid all the advocacy and marketing. (*) In fact I am a huge advocate of java.util.concurrent for any and all concurrent and parallel Java programming as anyone who has been in any of my sessions on this sort of thing can attest to. But . . . that doesn't make it right. It just makes it less worse. (**) Bazaar branch rendered by Loggerhead at http://www.russel.org.uk:8080/Pi_Quadrature, Bazaar branches for branching at http://www.russel.org.uk/Bazaar/Pi_Quadrature. (***) And, oh boy, isn't Java and the JVM a right pain when it comes to microbenchmarking. Bizarrely Scala does not have the same problems Java has when it comes to priming the JVM JIT, yet no Scala advocate has yet been able to provide me with a good rationale as to why. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
