<snip> ... until: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: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.
* 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