Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!oscsuna.osc.edu!pixelpump.osc.edu!stein
From: stein@pixelpump.osc.edu (Rick 'Transputer' Stein)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Message-ID: <275@oscsuna.osc.edu>
Date: 2 Aug 89 13:48:55 GMT
References: <8908011650.AA12679@kanga.cs.umass.edu.edu> <5726@pt.cs.cmu.edu>
Sender: news@oscsuna.osc.edu
Reply-To: stein@pixelpump.UUCP (Rick 'Transputer' Stein)
Organization: Ohio Supercomputer Center
Lines: 55

In article <5726@pt.cs.cmu.edu> jps@cat.cmu.edu (James Salsman) writes:
>In article <8908011650.AA12679@kanga.cs.umass.edu.edu> oskard%kanga@cs.umass.edu (DAVID OSKARD) writes:
>> 	If you had the chance to do it all over again, would you buy
>> Occam or one of the third party compilers for the Transputer?
>
>Occam is far superior for multiprocessing than any serial
>language (such as C) and it's model is much more safe and
>effective than Ada's.  The problem is that the C-weenies
>of the world have not yet aquired the brain capacity to
>understand the beauty and functionality of Occam -- yet.

I have to take exception to this statement.  I might write my
concurrent programs in C, but that doesn't mean that I'm a "weenie."
I have found C to be far more capable for creating data abstractions
than occam.  For my money, any form of computer simulation is dependent
on 2 things: 1) Abstraction of the problem specification into structures
which mimic their "real-world" behavior, and 2) The creation of operators
for these strucutures.  This programming style is more easily
achieved with C, C++, or Ada, than with occam.

Occam is indeed a highly secure language.  As far as C goes, I would 
suggest that you not carry a gun unless you can shoot straight.
I've blown several holes in feet during the creation of multicomputer
software in C, but you overcome these "programming errors" by relying
on module testing and the employment of a software engineering design 
methodology for multicomputers.

I'm not sure I understand what is meant by your statement, "Occam...is more
effective than Ada."  I suppose in certain respects, like rendezvous,
or concurrency control in tasking, yes I agree.  But in other ways, 
like abstraction, data typing, data hiding, etc. occam don't quite cut 
the mustard.
>
>The only thing I would change is to allow value functions
>to be recursive and specify that tail recursion is properly
>dealt with (as in Scheme.)
I agree with this.  Recursion is a very useful thing, and I'm not
the type to manage my own stacks of stuff (I'm generally too lazy or
stupid for this).  Unfortunately, inserting recursion into the occam
langauge would require the incorporation of dynamic memory allocation.
You need it to build call stack frames and the like.
>
>The macho way to do [dynamic memory allocation] is to create a 
>tagged protocol channel coprocess that allocates memory and 
>handles access and (de)allocation functions.  Then, you can place the
>process on whatever processor has the RAM (or the disk) for
>the data that you're storing.  This is a cool programming
>technique, as well as a neat abstraction.
Whatever turns you on.  I just use malloc.
>:James
-=-
Richard M. Stein (aka Rick 'Transputer' Stein)
Concurrent Software Specialist @ The Ohio Supercomputer Center
Trollius: The Official Multicomputer OS of the 1992 Olympic Games
Internet: stein@pixelpump.osc.edu, Ma Bell Net: 614-292-4122