Sorry to the group if that last e-mail came off as rant'ish.

I think some focus on studies would be nice, but why does it feel like (to
me) that we are aimlessly picking "this versus that" studies?

I would start instead by using expert knowledge, and work from there.  For
example, parallelism expert Guy Blelloch has some very bossy opinions about
how we should be educating students to program multicore machines.  Why not
conduct a study to validate that his approach produces better programmers?
To me, that's interesting, because you are taking advantage of what a world
expert thinks and then using your knowledge about how to conduct studies in
order to say, *Wow, look what the students learned doing it this way!*

The problem with this versus that studies is that ultimately they have
proven to be limited to the task they measure, and cannot be extrapolated to
larger projects.  Studies asking the same question, but using different
tasks, have consistently produced different results!

On Fri, Feb 18, 2011 at 3:03 PM, John Zabroski <>wrote:

> On Wed, Feb 16, 2011 at 11:10 AM, Russel Winder <>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

The Open University is incorporated by Royal Charter (RC 000391), an exempt 
charity in England & Wales and a charity registered in Scotland (SC 038302).

Reply via email to