Re: A path for CSP-based

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

Marcel and all,

The key point I was trying to make was not "enemy action" stuff, but
information problems due to conflicting definitions.

>From: M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>
>Date: Tue, 17 Oct 2000 13:49:10 +0200
>Message-Id: <200010171149.NAA28198@tigran>
>To: java-threads@xxxxxxxxx, tjoccam@xxxxxxxxxxxxx
>Subject: Re: A path for CSP-based
>
>A while back, Larry wrote:
>
>> This exchange is great... but don't give up too quickly, Marcel, you can
>> only expect to START change in a moment, not complete it.
>
>Cheers.
>
>This WORRIES me:
>
>> My contention is that we can punch through the fog with this one simple
>> fact: rigorous channel based CSP (occam) programming creates software
>> components that behave logically identically to hardware components.
>>
>> I know we have to fight against the fact that "component" has already
>                    ^^^^^!!!!
>
>> been appropriated by the OO crowd, but their component requires giant
>> ...

The kind of component I have in mind, unlike the OO component, is:

(a) self-sufficient;

(b) interchangeable.

(a) means it can run independently when hooked up properly (like
filters in DOS or Unix, alternators in or out of cars, etc).

(b) means it can be exchanged with any other "black box", software or
hardware, that imitates its simple state machine behavior. No object
structure knowledge is needed. This is like an old-fashioned printer.

This requires a very simple, dumb, DOS-like system to permit
reconfiguration at load time, analogous to a kid working on a car. The
possibilities for programming this way are breathtaking - if one can
communicate the concept to people "snowed" with the OO jargon that
in reality means stiff complexity.

>> > ...WEB...
>> In other words, at any moment, it is practically CSP.
>
>I would advice NOT to FIGHT, but to EXPLOIT.  These people are heading
>in the right direction, and we should PULL them further towards CSP
>heaven.

Perhaps we could encapsulate OO components in CSP components? Then
you just get data streams ("serialization" or whatever) and the
object definitions are their problem.

>> Software components that are logically IDENTICAL to hardware
>> plug-ins.
>
>Indeed, and we are NOT the only people knowing that.  People having
>Components in mind, think the same.  However, their implementation
>introduces lots of problems in many cases.

Refer to points (a) and (b). Your point about OO not being able to
handle single-machine complexity is apposite here. For CSP components
single machine multitasking is logically EQUIVALENT to distributed
operation. And things get even better when both work together:
software components managing hardware components naturally, like
drivers that don't have to be relinked.

The point is that program complexity can be shoved all the way to
the "load" stage using scripts. I demonstrated this crudely in my paper.

>> But if we can convince them that programming a specific project is
>> much quicker and cheaper using our techniques, then problem
>> avoidance IS (budget) problem solving.
>
>True... however it is difficult to make a case to Project Leaders that
>have to make profit `yesterday'.
>
>Cheers,
> Marcel

I think you pick a complex that you know from the beginning will have
to be repeatedly reconfigured... and pitch it to someone who has been
burned before by oversold OO concepts leading to a programming bog.

Good luck!

Larry