Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!ukc!axion!galadriel!pcf
From: pcf@galadriel.bt.co.uk (Pete French)
Newsgroups: comp.sys.transputer
Subject: Re: choosing parallel languages
Message-ID: <304@galadriel.bt.co.uk>
Date: 3 Aug 89 08:05:28 GMT
References: <5726@pt.cs.cmu.edu>
Organization: RT6115, BTRL, Martlesham Heath, England
Lines: 26

> 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.

The "C-weenies" of this world are quite capable of understanding its beauty
within the conbtext of the transputer. Certainly I would not want to try and
write highly parallel code for a transputer network using a serial language.

Thhe point you are missing is this - a language is not intrinsicly "good" or
"bad" you can only use these terms relative to the situation in which you
are using it. Try writing some UNIX systems programs in OCCAM and I'm sure that
you'll be back to /bin/cc very quickly.

Lack off dynamic memory allocation is a problem within Occam - its silly to
say that it isnt. It prevents code being written to use varying amounts of
memory on a system. The lack of structures is not a real problem since a
structure doesnt really exist - it is compiled to be just a manipulation of
bytes and words so why not program it thus ?

For waht I am doing I find that Occam is a very good language, I am not sure
that trying to start an argument over which parallel language is best is a
good idea since it could easily turn into "You can do such-and-such in langauge
X" to which a language X supporter can turn round and say "Why should I want
to ?". 

-Pete French.