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

Re: Occam-Tau - the natural successor to Occam-Pi - or is there one already?

On 1 Oct 2012, at 09:58, Tony wrote:

I came to Occam from programming real time systems in assembler on 2-4k ROM memory systems. What I liked about the simplicity of Occam was that with PAR and PRI I was easily able to describe the things that I had had to write management routines to do previously – the typical car engine controller has foreground tasks driven by the engine turning and background tasks, such as engine temperature, throttle setting.
I too used to program naturally highly concurrent and prioritised reactive systems on very limited platforms.  Multicore meant adding more 8-bit micros, whereupon we quickly learned (and resolved) the problems.  We did everything on (prioritised) interrupt, and counted cycles to verify it.

When someone suggested we should be using C++, we took a look and just assumed that either there was something mystical we did not know or that they were the ones who were in ignorance, of what we were doing.

occam was of course like a breath of fresh air.  Suddenly, here was something that did reflect what we did.  However, I never bought the PRI constructs, especially given two of them.  What I wanted was :

  event a then
event b then

in prioritised order of pre-emption, not PRI ALT or PRI PAR (and certainly not both).  But how do P and Q safely communicate?
(I need to formalise this construct, I know.)

If we want a parallel programming language for kids to learn with, in my view it should be simple and have the basic concepts – ideally we would have a language with two variants – a subset for learning and an enhanced version for serious programming.
I don't agree.  First, kids are smart, often too smart.  They'll happily accept something ridiculous.  What they don't do is reflect, especially when they're smart.  Give them C or (worse) Java and you'll never get it away from them again.

If it's simple enough for kids to learn, even when they're not smart, it'll then be safe in the hands of engineers.  If it challenges even the most able engineers, as concurrency does when attempted with C++. C# etc. then I for one will not board that aeroplane.  (It's rather like energy.  If it works in the 3rd world then it's probably sustainable, and thus what we should use too.)

I believe transparency is king.

The answer to building on what pros need is surely to add layers of abstraction, not to clutter up even the most simple programs with crap.  (I well recall how someone thankfully kept Java out of Year 1 by pointing just what you had to do just to define a constant.)


Ian East
Open Channel Publishing Ltd.
(Reg. in England, Company Number 6818450)