Re: The world needs process-orientation

[Lawrence Dickson <tjoccam@xxxxxxxxxxx>]

This note relates also to my thread "Re: Is OO a deliberate fraud?"

Andrew Delin <Andrew.Delin@xxxxxxxxxxxxx> wrote:
> I would be interested to collaborate in creating a small, experimental,
> Occam for .Net -- if anyone would like to collaborate, please get in
> touch.

I have no knowledge of the details of ".net", but wholeheartedly agree
with your project idea. Could you put me on any mailing list that shows
the technical details as they develop? In return I could contribute my
white paper on "resource-oriented programming".

If Allan McInnes, Torben Hoffmann or any of the Erlang people are
listening, I admit this means I'm committing the sin I accused you of
(relating to COP): "resource-oriented" is "process-oriented" from the
angle of transparent, controlled resource usage. My white paper comes
from an anti-metaphor angle, not specifically from CSP/occam; if you are
interested in seeing if it applies to Erlang, I could send you a copy
too. Anyone interested please let me know.

By the way, "resource-oriented" does have some implications: where occam
disagrees with CSP, it sides decisively with occam. (Riddle: Where's
that? I bet you didn't even know there was such a place.)

Now, everyone, PLEASE LOOK HOW RIGHT I WAS in my earlier thread, where I
accused OO of being the CSP-killer. Koehne Kai stomped on Andrew's idea
as soon as it appeared...

Koehne Kai wrote:
> <SNIP>
> However, there are a few obstacles that you have too keep in mind. First,
> the language constructs of occam are difficult to map efficiently to
> constructs of the Java or .NET intermediate language. Second the creation
> of concurrency (threads) is in both platforms pretty expensive (at
> least in
> comparison to KRoC). Finally, if you really want to use occam as a kind of
> coordination language, you have to find a convenient method to deal with
> things like object creation within occam.
>
> The bottom line is maybe that an optimal POP language for these platforms
> would take the process model from occam, and integrate it somehow with the
> world of object orientation ...

No. The whole point would be to ditch the world of object-orientation,
which ruins concurrency and resource tracking wherever it appears,
because its metaphorical (i.e. counterfactual) constructs prevent
design. My white paper --- which was written before all these threads
started --- explains this in detail. What you need to do is "hog-tie"
object orientation, i.e. use specific objects once to make the occam
constructs possible, and then never mention them again. Once the occam
and related OS-type constructs have take COMPLETE CONTROL of the harness
controlling multiprocessing, multitasking, and communication, modules in
other paradigms (i.e. OO) can be permitted to operate as black boxes,
just as used to be possible in the Inmos toolset.

Thread expense doesn't matter; we're proving a concept and doing a demo
here.

> oh, and to be acceptable for the masses,
> the syntax should resemble C ;-)

That part is OK, though an occam syntax of equivalent functionality
should be developed in parallel. The occam codebase is extremely
valuable, if only for test, and a lot of excellent parallel programmers
know occam.

Larry Dickson