On 13 Jan 2011 18:34, "Cédric Beust ♔" <[email protected]> wrote: > > > > On Thu, Jan 13, 2011 at 4:57 AM, Reinier Zwitserloot <[email protected]> wrote: >> >> I'm a bit confused as to why Scala programmers have the gall to claim the moral high ground in regards to multi-core programming. > > > I'm a bit skeptical as well, but without the harsh language :-) > > 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. > > 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... > > 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. > > 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. >
+1 You'd also want to add reliability as a metric (this being one of the core selling points for actors), and compare against data flow concurrency as well. > -- > Cédric > > > > -- > You received this message because you are subscribed to the Google Groups "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]<javaposse%[email protected]> . > For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
