AW: The world needs process-orientation

["Koehne Kai" <Kai.Koehne@xxxxxxxxxxxxxxxxxxxxxxxxxx>]

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

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! 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. Further problems are the incompatible type systems (reference types vs value types), the handling of exceptions etc.

I think it comes down to: Do you just want to be able to run occam on the top of the .NET runtime environment, or do you want to integrate an occam-like language nicely with these? The first is viable (I already did that), but the second is still an open question. If you prefer the first one, I am wondering why you want to target .NET at all? Would not a port of kroc to Windows be more appropriate?

Regards,

Kai Koehne

(*): 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.

PS: I do not know why Andrew proposed .NET as the target platform of choice, but since I already provided occam-like languages for both Java and .NET, it might be interesting for you if I briefly compare the two:

- The intermediate language for .NET was designed to support different languages right from the start. In contrast, the Java runtime has only to support the Java language, which results in several limitations: No unsigned data types (byte = -128..127), no overflow checking, no ROUND or TRUNC mode ... This has all to be emulated by the compiler.

- Java is of course much more portable. The only "complete" versions of .NET provided by Microsoft are Windows only. Mono tries to support .NET on popular UNIXes, with varying success.