On Wed, Feb 16, 2011 at 11:10 AM, Russel Winder <rus...@russel.org.uk>wrote:
> Prompted by various discussions elsewhere, I am on the search for recent > experimental results and/or people doing or about to do experiments. > The questions all relate to the models of parallel software: > shared-memory multithreading, Actor Model, Dataflow Model, Communicating > Sequential Processes (CSP), data parallelism. > > Question 1 is: is synchronous message passing easier for programmers to > work with than asynchronous message passing. > > Question 2 is: are the case classes of Actor Model easier for > programmers to work with than the select statement of Dataflow Model and > CSP. > > I am not sure what you mean by "case classes of Actor Model". You seem to be using some implementation-specific terminology, presumably from the Scala implementation of Actors. For example, did you know that the Scala implementation of Actors in the Scala standard library doesn't actually impose fairness constraints on message delivery, and therefore isn't identical to Hewitt/Agha's Actor Model(TM)? When I heard Actor Model in capital letters, I think of the work done by Carl Hewitt. If you can refer to a place where Carl says "case classes", I would appreciate that reference. I've read most of his and Gul Agha's work on Actor Model, and am not familiar with "case classes" vocabulary. And what does "easier" here mean? The original Actor Model was intended to be used by semanticists for e.g. proving that a server always provides service to its clients. See Hewitt and Lieberman's AI Memo 505 for an example of proving properties of a guardian in an actor language. I also don't understand the "select statement of Dataflow Model". I also reject the idea that synchronous message passing vs. asynchronous message passing is a good topic for empirical study. There are much bigger theoretical issues like deadlocks and whether buffers are being used. I also see synchronous vs. asynchronous juxtapositioned without much thought to the context. It is all well and fair to say some researchers try to do studies without background in cognitive psychology, but it is equally true that cognitive psychologists peddle garbage studies without actually understanding how to do software design and what are actually considered "trade-offs" or even "opposites". Moreover, most studies I see are biased, but being a cognitive psychologist is certainly not enough to detect this bias. You have to understand the problem domain. A classic example of this is William Cook's award winning paper Web Services vs. Distributed Objects: A Case Study of Performance and Interaction Design http://www.cs.utexas.edu/~wcook/Drafts/2006/WSvsDO.pdf -- The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).
