Re: AW: The world needs process-orientation

[tjoccam@xxxxxxxxxxx]

This is a rational response, Koehne, in a debate that is quite important.
Therefore I will answer several of your points in detail. The general
principle, however, is as the poet says:

  Your duck will not be able to swim
  If you attach an anchor to him

To demand that the large and moving target of OO be supported (especially
when it violates basic design principles) is to prevent success.

[> I wrote:]
>> 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.
>> [...]
Koehne Kai writes:
>
> I have of course to comment on that ;-) Although I do find your "OO
killed
> CSP" argument a bit exaggerated, I agree that the OO hype of the last
decade(s) has obstructed the development and use of more appropriate
programming models, especially regarding the use of concurrency.
However,
> in his original posting, Andrew proposed the use of occam for .NET as a
kind of coordination language:
>
>>The idea is that we can achieve a separation of concerns and Occam-style
code can deal with the parallel aspects. We might achieve some mindshare
if the language interoperates with convention blobs of code.
>
> As the .NET platform is based heavily on OO (*), and the most popular
languages for it are based on it too (C# and VB.NET), the "blobs of
code"
> are OO classes, and you have to somehow integrate this stuff with occam!

Fair enough, but the way I suggested is the clean way: use fixed class
usages, never mentioned thereafter, to put together what's necessary
between the metal and the occam harness; and then, if desired, allow
non-occam separately compiled programs (or modules) to be run, after being
mounted on the occam harness, similarly to the Inmos toolset's offering
for integrating old C, Pascal and Fortran code on multiprocessors. For the
first, see "Transputer Instruction Set, a Compiler Writer's Guide",
Prentice Hall, 1988 (use it in reverse to emulate the instructions'
behavior and construct the occam primitives). For the second, see "Using
the D705B occam toolset with non-occam applications" in "The Transputer
Development and iq systems Databook", Inmos, 1989.

> My current attempt to this problem is pretty minimal: Let the occam
program call static class methods within occam via externally defined
procedures. But this would propably not satisfy most programmers, as
there
> is no way to create objects and call object methods within the language.
<SNIP>
> (*): just to clarify: the .NET intermediate language is general enough
to
> provide support for most, if not all kinds of programming paradigms.
However, when people talk about .NET, they also mean the extensive class
libraries that are part of it.

That's the zinger: people who want "class libraries" to do concurrent and
communicating stuff, while preserving a paradigm ("call[ing] object
methods") that is intrinsically unable to model concurrent and
communicating stuff properly. This creates an infinite regress of
non-functionality, leading to ever-increasing bloat. We have to teach
people how easy and understandable it is to use proper tools for
concurrency and communication --- starting with TRANSPARENCY, not hiding
--- and confine the OO tools to what they are good for. It's like pulling
loose from the mud and flying, once you learn how.

Larry Dickson