🚀 go-pugleaf

The following is a copy of a message I received from Paul Kelly, in response
to my recent "what makes occam so good?".  I am sending it out, as I think
it makes interesting reading - hope you don't mind Paul!
-----------------------------------------------------------------------------
>From: Paul Kelly <phjk@uk.ac.ic.doc>
Date: Mon, 3 Apr 89 13:54:23 BST
Message-Id: <226.8904031254@noddy.doc.ic.ac.uk>
To: ian@uk.ac.soton.esp.v1
Subject: Re: why Occam

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

2) 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 be so nice if it were
   optional, with a stand-alone compiler as a fall back, 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.

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

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

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.

Thanks for your patience in reading this; feel free to copy it to the net 
in any summary of responses if you think it's worthwhile.

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