Re: son of occam

[Lawrence Dickson <tjoccam@xxxxxxxxxxx>]

Hi all,

I did not get the note from Ian East which Ruth is replying to here.
More below...

On 8/2/09, Ruth Ivimey-Cook <ruth@xxxxxxxxxx> wrote:
> Ian East wrote:
>> Second, I don't see why OO has to be unclean or 'un-simple'.  Surely, it's
>> the interpretation of OO, in Java and C++, that's the problem.  However, I
>> would certainly agree that inheritance is also a problem, as it lacks a
>> simple and coherent semantics.
>> IMHO, we need /both/ process and object abstraction.  They can
>> co-exist within a simple model, where every object has a single owner
>> at any time.  Object and value can pass between processes.  (Besides,
>> do you really want to live without defining lists, stacks, queues,
>> trees /etc./?)

According to the simple model I am working from, all these things need
to live in a black box whose internals I ignore completely. I guess
you can say I am on the harness on the outside. Dealing with the
insane-making side effects that are the inevitable consequence of the
ill-defined nature of objects is somebody else's job. All I ask is
that the resulting process (e.g. a Python process passing data between
Bluetooth hardware and a socket, in Linux) live or crash within a
fixed resource budget imposed by the harness.

>
> I fully agree. While processes are a powerful structuring concept, I
> don't believe they are the only valid one.
>
> Compare with sequential languages: would C be better off without struct?

You can have struct without OO, as C and (I believe) occam 2.5 prove.
Expanding on the concepts of abbreviations and channels are all that
is needed and should be allowed - concrete programming only. No hidden
resource allocation. This is critical to the design. Even global
variables are suspect. I think the model to remember is "separately
compiled" occam.

> would lisp be better off without lambda-functions? Of course not.
>
> I know some people equate "OO" with self-determining objects, but in C#
> for example there is a language distinction between reference-objects
> and value-objects; the latter are implementations of new value-types,

which would be OK as long as operations on them are absolute analogues
of old, with no side effects,

> which occam has long needed (DATA TYPE is a very poor relation) and the
> former are intended to be long-lived "objects" that maintain state and
> "do stuff".
>
> While I do agree that much of the C# reference-object usage can be
> implemented using processes, I also think that if you are hoping the
> language will be widely taken up, then you will implement reference
> objects (nicely) too: it will be easier for people to migrate to a new
> language if the learning curve is not too high.

It'll start out, at least, as a harness language, and therefore does
not have to do everything, in particular GUIs. It is critical to the
business model that it can do "system" calls that invoke processes in
other languages like C and Python, making them black boxes that emit
and receive data and control signals.

In the long run, we can challenge the standard OO model of a GUI,
which is always a nightmare to implement in real projects (as my
co-workers are once again experiencing). The new, clean approach
(which modern hardware is fast and big enough to handle) is the
totally intuitively obvious one - every selectable entity a process.
The more "eigenartig" are the duties of an interface, so the standard
alphabet soup hurts you instead of helping, the more comparatively
attractive this obvious model becomes.

Larry

>
>
>>
>> The longer I have tinkered with Honeysuckle
>> <http://www.honeysucklePL.info>, the more I am convinced that service
>> protocol is the right way to raise the level of abstraction from a
>> simple channel.  It is natural and intuitive, and is applicable to
>> everything from flip-flop and gate to distributed (client-server)
>> computing.  It also extends the formal foundation, bringing guaranteed
>> /a priori/ deadlock freedom (via static verification which can built
>> into the compiler – no need to hire mathematicians to prove anything).
>>
>> A compiler is under development (progressing well) that targets CSP
>> initially.
>>
>> Ian
>>
>>
>> Dr. Ian East
>> 57, Kidlington Road, Islip, Oxfordshire OX5 2SS
>> ian.east@xxxxxxxxxxxx <mailto:ian.east@xxxxxxxxxxxx>
>> (+44) 0 1865 373268
>>
>>
>>
>>
>
>