Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!vax1.esprit.southampton.ac.uk!IAN From: IAN@vax1.esprit.southampton.ac.uk Newsgroups: comp.sys.transputer Subject: Re: why Occam Message-ID: <8904101237.AA06165@uk.ac.ox.prg> Date: 10 Apr 89 13:36:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 71 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 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