[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re. Lamport / Composition

Paul Walker wrote:
<snip> ... until:

 there is a compiler of occam written in occam;
 and it farms itself out over a reasonable number of processors;
 and gives genuine speed-up from so doing;

     it is too easy to rubbish occam as a toy.

What makes the difference between a toy language and a real language to me, as a consumer of such things, is how well they can support serious engineering tasks. Although a parallel occam compiler written in occam is interesting, it might as well remain an interesting possibility if I still can't do things I might need in a large project:

* good modularisation - only in occam3 (not occam2)

* well thought out, portable and widely available library support

* tools in addition to a compiler

* interworking with other technologies.

A classic example of the latter might be a CORBA binding, since CORBA has at it heart the desire to support any language. That's putting aside performance and architectural issues. Although you can write distributed systems in occam, you probably don't have time to rewrite existing subsystems in occam just for the sake of some warm feeling about an overall architecture. One of occam's acceptance problems is that it tends not to be 'just another language' with some neat features. Rather
it makes claims over the entire system architecture if its approach is meaningful. This is such a contrast to C++ which is so lax it can be whatever it's needed to be (not that that's necessarily a good thing).

Now that we have a reasonably widespread selection of compilers (admittedly only for occam2), is there scope for a follow-on project on tools, libraries and further occam language developments?
Richard Beton B.Sc. C.Phys. M.Inst.P.
Roke Manor Research Limited
--------- Standard Disclaimer about my own views etc etc --------
---------  My mail client accepts rich text (HTML) mail  --------
Welsh Highland Railway: http://www.whr.co.uk/WHR/WHR.html