Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!umbc3!motteler
From: motteler@umbc3.UMBC.EDU (Howard E. Motteler)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Summary: it depends on what you want to do
Message-ID: <2226@umbc3.UMBC.EDU>
Date: 7 Aug 89 06:44:09 GMT
References: <276@oscsuna.osc.edu> <5752@pt.cs.cmu.edu>
Reply-To: motteler@umbc3.umbc.edu (Howard E. Motteler)
Organization: University of Maryland, Baltimore County
Lines: 52

In article <5752@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes:

>Perhaps in a language debate like this we should talk about
>the applications involed.

A good point.  I claim that occam is the ideal language for *teaching*
concurrency, which is not to rule out other applications.  Elegance,
consistency, and solid foundations all count for for a lot in this
context.  We teach an undergrad class here, "Parallel Programming in
occam," and especially the second time around, got quite a few
impressive projects; students were allowed to suggest their own
final project as an alternative to a default assignment.

Some general observations: First, occam is terribly easy to learn;
students can start writing concurrent code in the first week or so.
There are several good texts available.  The new generation of PC
hackers take quickly to the the TDS environment; I guess to them it
just seems like a fancy variation on Turbo Pascal.  The strong usage
checking helps a lot.  The two most common errors are trying to
commuincate via a shared variable, and having more than one process
sending or receiving on a given channel; both of these give compile
time errors.  (Unless the students swith off usage checking!)

Most importantly, occam/CSP is the right way to think about
concurrency.  The "atomic" action is a process; concurrency can be as
fine or as coarse grained as we like, etc.  I like to teach a little
bit about dataflow right at the beginning, relating dataflow edges to
occam channels, and nodes to processes.  Program design is then often
a two part process: first, finding a dataflow graph, and second coming
up with a way to number channels and processes as components of one or
more replicated PARs, so that channels corresponding to edges, and
processes to nodes.

The visual approach, thinking about concurrency as a dataflow graph,
tends to keep students away from the black hole of trying to analyze
all possible cases in a concurrent proram.  (I had one *determined*
state space analyzer, who inserted parameterized delays in every
process, and tweaked the delays until processes interleaved in the
order he expected.  Probably the longest piece of code that
occasionally managed to play "life" as has ever been written.)  It may
seem like I'm arguing for teaching dataflow as opposed to occam/CSP,
but what I'm getting as is that dataflow programs map *into* occam in
a very direct and natural way; occam in some sense is more general.

Using occam, concepts of concurrency are no harder for students to
learn than, say, recursion.  Of course there are always a few students
that have trouble with recursion too... at least you don't have to
worry about that in an occam class!

-- 
Howard E. Motteler       |  Dept. of Computer Science
motteler@umbc3.umbc.edu  |  UMBC, Catonsville, MD 21228