Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!ukc!etive!lfcs!nick From: nick@lfcs.ed.ac.uk (Nick Rothwell) Newsgroups: comp.sys.transputer Subject: Re: what makes occam so good? Message-ID: <1756@etive.ed.ac.uk> Date: 13 Apr 89 10:11:34 GMT References: <8904101227.AA05713@uk.ac.ox.prg> Sender: news@etive.ed.ac.uk Reply-To: nick@lfcs.ed.ac.uk (Nick Rothwell) Organization: LFCS Enya Admiration Society Lines: 39 In article <8904101227.AA05713@uk.ac.ox.prg> IAN@vax1.esprit.southampton.ac.uk writes: >No doubt Milner's CCS is indeed a more general tool to describe a wide >variety of models of concurrent behaviour, but that is not the intention >of occam. It is intended to be a programming language. Fair enough. I was probably getting a little wound up by the way that OCCAM keeps getting referred to as a "calculus", as if there is something magically formal about it that sets it completely apart from other languages. It *does* have some nice (and important) semantic properties, but I certainly would not call it a formal language; it is a programming language, like you say, nothing more, nothing less. Actually, I quite like OCCAM. It provides a good way of building frameworks and mechanisms to handle the concurrent part(s) of an application. However, it totally fails to provide some of the important aspects of a software system: recursion, abstraction, data structuring, etc. In a recent project we tied 20000 lines of C (a compiler for an abstract language, abstract code generator, interpreter, and so on) with some OCCAM to provide a communications base. Writing the compiler in OCCAM would have been a virtual non-starter. Writing it in C was bad enough, given that the prototype was in ML. The main reason for OCCAM's failure, I think, is the closed world philosophy that went along with it. INMOS wanted everybody to program entirely in OCCAM under the TDS on their Sage computers. Everything else was "alien" - even files. We threw the OCCAM out of our project and used C instead, because OCCAM's little world was so completely nonstandard and different to everything else. Using C and the 3L tools, we can drive the development process from a Sun. Had INMOS brought out a "batch" OCCAM compiler, and believed in conventional machines and file systems, things might have been different. What do other people feel? >| Ian Glendinning Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk !mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ...while the builders of the cages sleep with bullets, bars and stone, they do not see your road to freedom that you build with flesh and bone.