Re: son of occam

[Lawrence Dickson <tjoccam@xxxxxxxxxxx>]

Hi Ruth and all,

Thanks for the response. I'm on vacation trying to use my sister's
dial-up modem, so I hope this comes through. I'm noting your points
and have some responses below...

On 8/2/09, Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:
> 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.

That does not answer my question. The "occam style" (thanks to Python)
and the "C style" are both things that people don't have to relearn,
but the question is whether you think one or the other has a clear
advantage, and why.

>
>> (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.

I guess I'm thinking bash which by your definition would be a bootup
language. The same with DOS batch files. But bash at least is highly
parallelizable (if you think of the "&" at the end as parallelism,
which I do), and I long ago devised a way to make DOS batch files
parallelizable. Making complex thoughts as simple as possible is nice,
but definitely a secondary goal. Making parallel, occam-like harness
construction as simple as possible is crucial.

>
> 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.

No, of course not. But writing drivers takes effort.

>
> 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.

Is there any hope that the Transterpreter will ever do this? The
omission of Priority 0 is crippling. I just had a discussion with an
independent, non-occam embedded software writer of long experience,
and he came up with the term BOTH FAST AND SLOW because he wants to
drive stepper motors with perfect timing... thus confirming that
Priority 0 is a huge part of the utility of the "Transputer" which was
also my experience on all the real projects I worked on.

Larry

>
> Hope this helps,
>
> Ruth
>
>