phjk@doc.ic.ac.uk (Paul H J Kelly) (04/06/89)
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.4993les@unicads.UUCP (Les Milash) (04/08/89)
In article <754@gould.doc.ic.ac.uk> phjk@doc.ic.ac.uk (Paul H J Kelly) writes
lots of good stuff about Occam's continued nonwidespreadedness.
One other thing that would have helped, i think, is to have made it easier for
folks to roll their own occam systems. occam was exactly i needed for
a project a while back (i think; i didn't try it so i might still be wrong)
namely programming a pile of parallel dsp's in a hi-level language.
i was trying to make a compiler for a 16-bit integer-only subset of occam.
"OCCAM" it wouldn't have been exactly, in the sense that your occam programs
wouldn't run on it, but in most respects the same. and the dsp world
very much needs this right now, IMHO.
i never could even seem to find a complete definition of the language (till
after the project was cancelled) and so all during the period i was trying
to build a parser for it i kept finding new code fragments (examples in
newer inmos books) that i hadn't anticipated, like IF expressions for example.
(I would have called it SPOcc (Signal Processing Occam) cute, huh?)
so if I had some new language that i wanted you to use, (i'd make it good
etc. of course... i'd give it records/structures like Mr. Kelly mentioned,
i'd MAKE IT RECURSIVE like God intended) and==>i'd give you a FREE C
implementation of it or at least of a compiler front-end<==that's what'd do it.
i know there was a "portakit" but it was unavailable when i needed it.
that's what Xwindows is doing, and maybe why it's more widespread;
the X consortium created a public domain implementation (i think).
despite its problems, i'm still kind of infatuated with occam.
the trick of proving that the T800 FPA was equivalent to the (IEEE
compliant) T414 FP library is very slick. the TN on "compiling
occaminto silicon" is provocative in my opinion.IAN@vax1.esprit.southampton.ac.uk (04/10/89)
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