Re: Musings on occam and Java

[Richard Beton <rdb@xxxxxxxxxx>]

phw wrote:

> //{{{  language constructs
> 
> ...
> 
> To me, what it needs most is a library (or `package') mechanism burnt into
> the language ... that would make life easier for every application area.

The package syntax of Ada is certainly a major advantage of Ada over occam
(I should add that my current project is all Ada).


> For non-embedded application (e.g. for compilers, operating systems, ...),
> recursion and dynamic workspace allocation *may* be helpful.  Throughout
> the 1980s however, most people worked with the occam compiler written in
> occam and an integrated development environment (the TDS) also written in
> occam ... in fact, I still use those tools.  The first occam system I used
> (back in 1984) was on a Sage/Stride system, for which the TDS provided the
> entire operating system (controlling all discs and peripherals).  The code
> for this compiler/TDS was a collection of communicating processes and very
> elegant.  We need to get back to this one day ...

But I think not soon!   :-)



> //{{{  object-oriented versus object-based
> 
> Peter Wegner's classification of object-based/class-based/object-oriented
> are, of course, quite arbitrary ... but I guess that classification is
> what the `object-oriented' community uses so we ought to stick with it.
> 
> But it remains slightly annoying that a system, that (to me) is implemented
> with algorithms that are decidedly not oriented to the objects being
> manipulated, gets classified `object-oriented' simply because it is written
> entirely with objects, classes and inheritance!  I must write a note about
> such examples soon ...

For the theorists out there, there may be scope for a completely new
language paradigm which combines the advantages of object-oriented programming
(mainly advantages of source code structuring using horizontal layering)
with those of occam-like object-based programming (with advantages of
concurrency, testability, and divide-and-conquer analysis - vertical
partitioning if you like). Anyone looking for a PhD topic? :-)



> I think the jury is still out as to whether `inheritance' really does
> contribute to good program organisation, reuse, extensibility etc.  These
> are certainly apsects that we emphasise (and demonstrate) when we teach
> occam (and where there is no *explicit* inheritance mechanism).

I'd like to hear more from you on this, Peter. Many colleagues accept
as an axiom the many benefits of inheritance, without being able to
name them in terms I can understand. I've often questioned this, but
as usual I'm a prophet in the wilderness!


> //{{{  output guards in ALTs
> 
> Your sread/swrite polling methods are interesting.  They raise the prospect
> of output guards in the method of implementing ALTs described in your paper.

'On Guards' (Geraint Jones, OUG-7 Parallel Programming of Transputer Based Machines,
IOS Press, September 1987) is specifically about the difficulties of output
guards.



> //{{{  my problem with IllegalThreadStateException
> 
> This hasn't gone away ... but I've find another way to solve the problem
> for which IllegalThreadStateException might have been a solution.  That
> problem was making multiple readers/writers of channels/buffers secure.
> I'll post this new solution shortly ... sadly, it's a slow one (8.8 ms
> per ComsTime loop compared with 5.5 ms for my previous BUFFER_OF_INT
> compared with 1.5 ms for your Channel(n) compared with 0.6 ms for your
> Channel()) ... but we may have to pay this price for security in Java?
> 
> Of course, the occam3 equivalent would be simpler, as secure and about
> 1000 time faster ... (:-) ... now, where is that occam3 ?!!

Performance will be an interesting thread for discussion at the Java 
workshop: like-for-like comparisons between different concurrency
systems carried out to date put occam well ahead of eg Ada. Java will be 
much more interesting if it could come up alongside occam in concurrency
performance terms. And maybe we'd get efficient Java shared call channels
too?

Regards,
Rick

-- 
              Richard Beton BSc MInstP CPhys
      Roke Manor Research, Romsey, Hampshire SO51 0ZN
-------  Standard disclaimer about my own views etc  -------
           See http://www1.roke.co.uk/WHR/WHR.html