Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!shadooby!accuvax.nwu.edu!tank!ncar!unmvax!pprg.unm.edu!hc!lll-winken!uunet!mcvax!ukc!icdoc!doc.ic.ac.uk!phjk
From: phjk@doc.ic.ac.uk (Paul H J Kelly)
Newsgroups: comp.sys.transputer
Subject: Re: why occam (in reply to Ian Glendinning's article)
Message-ID: <754@gould.doc.ic.ac.uk>
Date: 5 Apr 89 19:49:17 GMT
Sender: news@doc.ic.ac.uk
Reply-To: phjk@doc.ic.ac.uk (Paul H J Kelly)
Organization: Dept. of Computing, Imperial College, London, UK.
Lines: 60

In reply to Ian Glendinning's article asking for comments on Occam, its
success and its future.  Sorry it's a bit long:
----
I enjoyed your article, and found it thought provoking.  I certainly
share your interest in formal program manipulation, but I have nonetheless
found Occam desperately wanting in practical application.  

1) Occam is an interesting language, and is certainly a nice way to think
   about concurrent systems.  There is an underlying model of what a 
   VLSI multiprocessor can do which closely corresponds to what Occam 
   provides, so it is a good model both for semantics purposes, and
   performance purposes.  It is from just such a coincidence that we 
   can expect great things to emerge.  
     I suspect that by this means, Occam sells transputers without having
   to be actually used as a programming language.

2) Occam's lack of data structures was the biggest single problem for us,
   and completely outweighed any possible advantage.  It reduced us to 
   the kind of disciplines (with no compiler support) I thought I had given
   up with assembler programming.  In this respect C (with lint)
   is a far far more secure programming environment in terms of compile-
   time checking.

3) It was especially galling to have to acquire special hardware in
   order to experiment with Occam.  It completely conceals the language's
   merits.  The TDS was quite an obstacle too: it would have been nice to
   have had the stand-alone compiler right at the beginning, for the
   reason that we soon felt the need to integrate Occam programs with
   preprocessors, revision control systems etc.  I guess at the root is
   the 'closedness' of the TDS compared with the open toolbox approach
   made so easy by an environment like Unix.

4) The failure of Occam to take over the world cannot be separated from its 
   chronic incompleteness.  If the current release of Occam 2 had been 
   available from day 1, its superiority over say Fortran would have been 
   more obvious.  Instead we found a rugged path of incompatible language
   upgrades, linked with buggy and incomplete compilers.  Thus, my and 
   many others' experience is very much coloured by earlier disillusionments
   rather than Occam's current state.

5) Occam's commitment to purity for formal manipulation's sake is very exciting.
   The restrictions it imposes are real and sometimes very serious (notably
   side-effect freeness of functions).  I predict that if Occam succeeds
   as a programming language alone it will be at the expense of such features.

   The slide backwards *can* be averted, by making machine-assisted/verified
   program manipulation available as a low-cost product.  I hope this is in
   the pipeline (it could justify TDS).  I hope it will be cheap or
   free, on top of Occam itself, and I hope it will be portable so we
   can teach classes of students with it.  

   To reiterate, clean semantics are of very little use without machine support.   The *human* programmer will always be straining at the leash for powerful
   features, which are in the general case hard to incorporate into
   the language's theory, but in particular instances often justified by 
   higher clarity.

Yours,
	Paul Kelly, Dept of Computing, Imperial College, 180 Queen's Gate,
		    London SW7 2BZ
		    +44 1 589 5111 x.4993