Lamport and toy languages

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

Folks,
   This is my belated 2 cents worth on the occam "toy" flurry of the
last few weeks, which I am very glad to see has reinvigorated occam-com.
   The "toy" terminology seems to refer to non-use in real world
problems. The best answer I know of is that Daimler-Benz project that
had a self-piloting car programmed in occam and running on the
autobahn. The fact that projects of such complexity more or less
arrange themselves in occam, while running against a low practical
complexity ceiling in non-"live object" languages, is in itself an
answer to Lamport's argument (as quoted).
   I contend that the advance of technology itself is being held back
by this complexity ceiling. The "object oriented" model is terrible for
anything except (to borrow a word) toys!
   Peter Welch wrote:
>We have been teaching UML to our first-year students as part of their
>first course on OO and Java. ...
>
>Neither of these diagrams give me what I want.  The `structure'
>diagrams are marginally useful -- but not half as useful as the
>network diagrams we draw for occam (and, now, JavaPP) that show the
>relationships not between classes but between the actual (live)
>objects. ...
>
>The `sequence' diagrams are positively harmful.  They show the dynamic
>calling patterns between objects.  I don't want to know that.  I just
>want to know the dynamic behaviour of each (active) object on its own
>-- how it interacts with its environment (via a channel and/or event
>and/or bucket interface).  If I need to draw the combined execution
>behaviour of multiple objects, I get a combinatorial explosion.
>
>This gets back to the "composition" argument.  With a
>channel/event/bucket interface, we get excellent de-coupling between
>processes (live objects).
   I remember a young French lady who was presenting a system for
connecting a few sensors on a bridge, and OO had it already sunk under
layer after layer of complexity, while with the occam model it was
trivial. And occam's lead increases as the problems get worse. Think of
a description of how an automobile works (I mean the physical parts,
not the recently introduced computerized stuff). A challenge to
Lamport: I contend there is simply no way that a non-compositional
approach could be used to demonstrate that the entire assembly of (say)
a 1961 Plymouth will work, but with an occam-like approach it is pretty
easy.
   Here are some practical notions:
   Has anyone out there started building occam compilers that work on
standard commercial real-time kernels? These have a defined interface
that may be a SUPERSET of what is needed to emulate the multitasking
and multiprocessing primitives (i.e. in Inmos' old Compiler Writers
Guide), they run on lots of different processors, and they claim to be
snappy fast. I saw on http://www.windriver.com that there are third
party Ada compilers and whenever I see Ada I ask, "Why not occam?"
   WindRiver (VxWorks) may offer the quickest way to Mars, but to be
fair here are two competitors: http://www.isi.com (pSOS) and
http://www.atinucleus.com (Nucleus). They come up because all have been
qualified to run on some third party disk driving software I am working
on; so maybe these are the most willing to work with third parties like
occam language developers, just in case something is needed (i.e. an
ALT construct foundation?).
   It would be quite a triumph to burst forth with a full occam
compiler that would follow one of these RTOS's wherever it goes (and
they have terrific real-time development tools too). According to my
own experience doing something similar for the 8086, it would not be
too great an effort---you guys have the compiler writing expertise, and
the kernel interface is a small matter compared with that.
   Also, these RTOS people are wandering in the fever swamps of POSIX
and the like, with their superfluity of dangerous primitives. People
like Peter Welch could contribute some clean, mathematical occam
thinking and maybe raise their capabilities to new heights of
predictability.
   Second notion: occam by itself is too static. People want to run
within an OS, which is dynamic in nature. Pardon the ad, but I showed a
few years ago how you could have both worlds under not very onerous
restrictions, and still rigorously control your resources. It was
really pretty trivial, and I'm out of touch: but possibly this message
needs to be got to people like Lamport?
   Third notion: occam-EQUIVALENT designs, where the behavior of some
simple hardware constructs (like FIFO memory reads/writes) can be
proved equivalent to an occam program, are incredibly useful and could
perhaps be to some degree automated?
                               Larry Dickson