Re: New Book: CONCURRENCY

[tjoccam@xxxxxxxxxxxxx (Lawrence Dickson)]

>Subject: Re: New Book: CONCURRENCY
>Date: Tue, 20 Apr 99 12:35:53 +0000
>From: p0072370 <ireast@xxxxxxxxxxxxx>
>To: "Rick Beton" <rdb@xxxxxxxxxx>, "java-threads" <java-threads@xxxxxxxxx>,
>        "occam-com" <occam-com@xxxxxxxxx>
>
>>Inheritance is still the subject of debate for its merits in code re-use. C++
>>has, however, clouded the issue by its highly impure implementation.
>>Certainly
>>within Siemens, code re-use by means of inheritance has been found seriously
>>wanting. One way in which inheritance seems to be clearly beneficial is when
>>an abstract class is given concrete implementations to meet particular
>>requirements. This is typical of much of the Java standard APIs.
>I agree completely that inheritance as refinement (loosely), used for
>interface spec is valuable, though incomplete. We need better ways of
>specifying interfaces.

In my opinion we need to develop techniques independently of the
inheritance paradigm, which leads to unwieldy depth of hidden knowledge
(and thus, inevitably, to ignoring what you do not want to deal with).
What are PRACTICAL documentation techniques used in large occam programs
of the past?

>
>>Perhaps it's fair to say, inheritance seems to be more useful the fewer
>>layers of inheritance are applied.
>Again, I agree. It would be interesting to know just what the statistics
>are.

My personal experience (and what I have seen) is that using OO techniques
(including OO case tools and inheritance) triples the effort, when it does
not crash the project entirely. This is particularly true of heterogeneous
distributed applications - the knowledge structures overarch all the
different components and mostly are a forced fit.

>
>Would we want inheritance as part of any successor to occam?

We need to be leaders not followers! We must deal with the purpose
inheritance was supposed to SERVE, but surely we can do better.

My own favorite occam+ feature would be load-time reconfiguration. This
allows a simple operating system construct, missing in standard occam,
which is plenty good enough for embedded apps (sensor arrays, robotics
etc). It frees software modules to be independent programs -
interchangeable with hardware, and really implementing the functional
live objects Peter Welch has in his lecture notes - while at the same
time absolutely preserving the mathematical robustness of occam, since
it is static at any given time between loads/unloads. There is no
performance penalty for heavy processes.

Once you have small live modules, documentation of interfaces becomes
easy.

>
>Ian
>
>
>Dr. Ian Robert East
>01865 483635
>Room T408, Tongue Building
>School of Computing and Mathematical Sciences
>Oxford Brookes University

Larry Dickson