Re: a few questions

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

Gerald,

> When and why did SGS-Thomson buy INMOS and when and why did SGS-Thomson
> decide to put the transputer on hold?

I think it was around 1989 - but there are others who can answer for sure.
As to what they did with the transputer ... I don't think there's a simple
answer :-(

> Is the occam compiler already made public?

Yes.  Download the KRoC Linux/PC release from:

  http://www.cs.ukc.ac.uk/projects/ofa/kroc/

You get the full compiler sources (plus all our stuff) under GPL and L-GPL
for all the supporting libraries.  We've fixed a few bugs since SGS-T last
touched it ;-) ...

> My statement is that CSP is new technology ...

That's the right message!  It's about 10 years newer than OO and 5 years
newer than monitors.  Most people never consider how old are the software
ideas that are in their flash new (but buggy) gadgets.  CSP's time has yet
to come.  

> Do you know examples of ... based on the principles of CSP?  I am thinking
> examples in object-orientation ...

I'm not yet sold on marrying CSP with OO.  JCSP and CTJ do a fine job and,
so long as the world remains sold on OO, that's definitely a good line
to peddle (I'm afraid it's the only line to peddle).  But deep down,
I'm not happy with OO :-(

The discussion you started on UML has been very interesting.  As someone
said, UML class diagrams try to show the complex ways classes are related
to each other - not objects.  Stuff like Sequence Diagrams try to show
some semantics - through execution traces of a thread as it leaps from
object to object (nasty - see below).

In designing large occam/JCSP/CCSP systems, I've never used UML.  Never
missed it.  Always been completely happy with data-flow diagrams (where
"data-flow" is liberally interpreted to mean any form of well-defined and
scalable synchronisation).  My students - like Dyke's - also seem to get
along building highly concurrent systems without using UML.  We get them
up to 20-30 processes in about 4-5 weeks and they do an open-ended project
after 15 weeks.  The best of those come up with systems around the 60
process figure Dyke quoted - and these are irregular networks in several
layers with around 20 different process types.  We also study various
simulation examples that use tens of thousands of processes ... and they
also get Rick Beton's one million process shout-down-the-pipe demo!

A Communicating Sequential Process is a *component* - it's complete and
has no complex dependencies on other components.  It doesn't matter whether
we're talking about the template of a process (e.g. the PROC declaration or
"class") or instances of a process ("active objects").

The definition comprises syntactic and semantic information of how the process
interacts with its environment.  This is entirely through a defined interface
- its abstraction - consisting of various synchronisation primitives (e.g.
channels, buckets, barriers, ...).  The semantics of this abstraction can be
expressed formally in CSP, or informally, just in terms of this interface.
No description of any *other* process comes into this.

An implementation of this abstraction may *have* lots of sub-components.
What they are, how many and how they are connected up is represented by
its data-flow network.  There are *no* interactions with other processes
(a "uses" relationship).  There are only interactions relative to the defined
interface (represented in the data-flow diagram as connections to the external
sync primitives).

So, I think those primary UML forms of diagram expose flaws in the concepts
of OO.  OO systems are networks of global interactions - anything can
interact with anything they can see and, usually, that's a lot more than
the documentation tells us.  We have to stare at the source code to really
find out.  OO "abstractions" hide these extended interactions - and that's
definitely not the kind of information that needs to be hidden from the 
system builder trying to use the object.

So, I don't want the Sequence diagrams to help me trace the run-time
interactions between objects.  I want to understand an object in isolation
and I can't.

I have some sympathy for the "is a kind of" relationship.  We need some way
of describing a family of processes.  But classical OO inheritance introduces
so many unseen dependencies as to make it too difficult to use beyond rather
simple scenarios.  And we must be able to describe relationships that diverge
and come back together - e.g.

                  P + widget-A
                 /            \
                /              \
               P                P + widget-A + widget-B
                \              /
                 \            /
                  P + widget-B

which single-inheritance OO does not describe (but network diagrams can).

I don't want class diagrams telling me about "has" and "uses" relationships!
The former tells us nothing about the ways the objects we "have" fit together
... and the latter (which refer to external objects) shouldn't be there in
the first place!  OO languages (like Java) give us no distinction anyway
between these forms of relationship.

Which leaves us in a bit of a mess ... unless we develop and stick to some
fierce design patterns.  CSP is such a design pattern - but I'd rather
(much rather!) have that burnt into the tools I'm using.  Or, if you don't
like CSP, then some other scheme (so long as it offers the same kind of
security and design flexibilty - components that compose would be nice!).

So, I don't see the argument in favour of OO as we know it today.  It's too
over-the-top for simple systems and too dangerous for large scale complex
sytems.  Somwehere in the middle, I guess, there may be a niche where it's
not too bad ...

Is this heretical enough?  ;-)

Peter.