Re: son of occam

[Ruth Ivimey-Cook <ruth@xxxxxxxxxx>]

Larry Dickson wrote:
> Hi all,
>
> I'm going to trail off this thread and change its name because I'm
> changing the subject a bit. Everybody seems to agree that occam is
> "dead" but is still the best way to do things, which is of course
> ironic. I have long wanted to move it in a more practical direction
> while keeping its cleanness and simplicity (NO OO), and now may have a
> business route to that (more on that later). I want to get some
> opinions from the list.
>
> (1) What should it look like - traditional occam (Python, etc) with
> indents and significant line-feeds, or C (java, etc) with semicolons?
Stick to something simple that people don't need to relearn. Don't mix
up stuff unless it has a clear benefit - you'll just confuse users.

> (2) What should an associated scripting language look like? I want to
> control everything from soup to nuts ultimately, which means bootup too.
The lesson for a "bootup" language is that it should be easily mappable
onto hardware; no assumptions of "infinite" resources, etc, and a
language runtime that can cope with many different environments, as
system designers often want to change things in the search for
advantage. For a parallel language this is particularly difficult.

The lesson for a "scripted" language is that it should express even
complex thoughts as simply as possible, with a minimum of fuss and
little or no explicit resource management - implying lots of runtime code.

I have yet to see a single language that serves both needs well, and
doubt that it's possible.

For reasons of practicality, a better path would be to aim at serving an
existing niche - as C# did for C++

> (3) What should get first attention as the analogue of the hardware
> link? USB? TCP/IP?
If the language definition needs to know this, you're lost.

For implementation purposes, you're likely to be running on a desktop
OS, so TCP is the obvious answer for an initial implementation. However,
any general purpose process language needs to be able to cope with truly
application-defined link interfaces - be it RS232, InfiniBand or the one
the project cooked up last week - and so I'd suggest the initial
implementation included at least one other link type as different as
possible in nature from the first. For example TCP and shared memory,
and I2C.

What follows from the above is the implication that the language must be
powerful enough to express high-quality device drivers itself, and that
a process/process tree can have control over how it is distributed (in
this case, to require local access to hardware). Finally, that standard
hardware events (primarily interrupts but also system traps) can be used
without undue overhead.

Hope this helps,

Ruth