Re: son of occam (was: Re: JCSP, CSP Networking, and other some other points)

[Bob Gustafson <bobgus@xxxxxxx>]

For the last few years I have been writing code in Ruby
(http://www.ruby-lang.org/)  (Full OO)

There are a lot of good books on Ruby, particularly from Pragmatic
Programmers (http://www.pragprog.com/) who have a 'Beta' book scheme -
download a preliminary pdf now, with periodic updates - then get the
paper book when it is eventually published. This squeezes the time delay
out of the 'knowledge - book publishing - knowledge acquisition'
waterfall.

A very reasonable programming IDE platform is Eclipse
(http://www.eclipse.org/) which supports a variety of languages (not
Occam or CSP as yet though..) It natively supports Java.

>From Aptana (http://www.aptana.com/) you can download a plugin - Aptana
Studio - which runs on top of Eclipse.

Aptana Studio includes RadRails, which is quite a good IDE for
developing web browser/database programs using the Ruby on Rails idiom.
(straight Ruby as well). All of the above (not books of course) are
freely downloadable.

Every programmer has his own langue de l'instant. Ruby happens to be
mine, just as Occam was a few decades ago.

The point however:

There are enough tools and IDE platforms out in the open source world to
mix and match to create powerful tools for concurrent programming.

The web browser/database environment is pretty easy these days. It can
also be leveraged to provide massive development and debugging support
for all kinds of programs - not specifically those used for web site
support.

Folks with PhD candidates-in-waiting take notice.

Bob Gustafson

On Sun, 2009-08-02 at 07:52 -0700, Larry Dickson wrote:
> Hi all,
> 
> I'm going to trail off this thread and change its name because I'm  
> changing the subject a bit. Everybody seems to agree that occam is  
> "dead" but is still the best way to do things, which is of course  
> ironic. I have long wanted to move it in a more practical direction  
> while keeping its cleanness and simplicity (NO OO), and now may have a  
> business route to that (more on that later). I want to get some  
> opinions from the list.
> 
> (1) What should it look like - traditional occam (Python, etc) with  
> indents and significant line-feeds, or C (java, etc) with semicolons?
> 
> (2) What should an associated scripting language look like? I want to  
> control everything from soup to nuts ultimately, which means bootup too.
> 
> (3) What should get first attention as the analogue of the hardware  
> link? USB? TCP/IP?
> 
> (4) Is anyone doing a flavor of Transterpreter or similar project but  
> retaining the full-interrupt Priority 0 of the Transputer?
> 
> Larry Dickson
> 
> 
> On May 18, 2009, at 6:11 AM, Eric Verhulst wrote:
> 
> >
> > Dear Chris,
> >
> > Occam might be dead as an industrial language but its legacy lives on.
> >
> > In attachment a screen dump from OpenVE, the GUI front-end for  
> > OpenComRTOS.
> > We call this a pragmatic superset of CSP but the programming style is
> > similar. The current version is in C but C++ wrappers should not be a
> > problem.
> >
> > The problem shown on the screen dump is a parallel matrix  
> > multiplication
> > even if OpenComRTOS was more designed for embedded applications (incl.
> > heterogeneous targets). You can see this in the topology diagram (our
> > standard demo mixes a Win32, a linux, a Leon 3 and a MicroBlaze). The
> > current implementation limit is 64K nodes, but granted, one would  
> > need to
> > have a dedicated tool for handling such large networks. Given that all
> > meta-data is in XML format, it doen't need to have a GUI. For  
> > performance
> > reasons, a better hardware would help as well, but if that' s  
> > available,
> > it's a matter of porting a linkdriver.
> >
> > You can try out the WIN32 (and soon Linux) version for free by  
> > downloading
> > it for free from our website. This version also emulates multi-node  
> > targets.
> >
> > Best regards,
> >
> > Eric Verhulst
> >
> > ----------------------  FROM : --------------------------
> >   Eric.Verhulst@xxxxxxxxxxxxx
> >   Skype me at: ericverhulstskype
> >   Mob. +32 477 608339
> >   "Push the button High Reliability"
> >   http://www.altreonic.com
> > -----------------------------------------------------------
> > "From Deep Space to Deep Sea"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of  
> > P.H.Welch
> > Sent: donderdag 14 mei 2009 5:10
> > To: Ruth.Ivimey-Cook@xxxxxxxxxx; tjoccam@xxxxxxxxxxx
> > Cc: A.T.Sampson@xxxxxxxxxx; java-threads@xxxxxxxxxx; lewando@xxxxxxxxxxxxx 
> > ;
> > occam-com@xxxxxxxxxx
> > Subject: Re: JCSP, CSP Networking, and other some other points
> >
> >
> > Hi,
> >
> > Just forwarding a posting from Chris Jones on the above ...
> >
> > Peter.
> >
> > ---------------------------------------------------------------------------
> > From: "Jones, Chris C (UK Warton)" <Chris.C.Jones@xxxxxxxxxxxxxx>
> > Sent: 08 May 2009 13:46
> > To: 'Larry Dickson'
> > Subject: RE: JCSP, CSP Networking, and other some other points
> >
> >
> > Larry,
> >
> > Sorry I do not know how to send this directly to the mailing thingy.
> >
> > You interest me greatly on the demise or potential future for occam.
> >
> > We would still be using occam if we could.  Many years ago, we  
> > rewrote a
> > large code for simulating electromagneitc effects on aircraft -  
> > particularly
> > lightning - into occam (it is about 140,000 lines now and was  
> > proably about
> > 100,000 then).  We first analysed the main core of the algorithm in  
> > CSP.  Of
> > course, we had transputers and the wonderful TDS.
> > It worked, was easy to maintain and continue to develop and we had  
> > more
> > fundamental proof of the correctness of the implementation than we  
> > can now
> > dream of.  Sadly, our T9000 machine never actually happened and we  
> > accepted
> > parallel PowerPC processors with transputers handling the comms  
> > instead.
> > Even more sadly, we had to rewrite our code back into the original  
> > Fortran,
> > though by having gone through occam, it was much easier and bug free  
> > than
> > the original had been.  That code would still be occam if we had not  
> > been
> > forced to reveert to Fortran for lack of occam implementations on  
> > other
> > commodity processors.
> >
> > Even now, we would write some applications in occam were there a  
> > reasonable
> > way of programming a large parallel computer - we currently run 128  
> > quad
> > cores with a Quadrics switch.  There are some issues
> > though:
> >
> > 1.  Lack of occam knowledge - actually this is far worse than it  
> > sounds.
> > We lack parallel computing knowledge at a fundamental level.  Making  
> > cals to
> > MPI libraries is not the same thing.
> >
> > 2.  Personnally, I'd like to see a development systems akin to the  
> > old TDS -
> > I am so old I actually do not like the modern programme writing  
> > pardigm with
> > thousnads of interlinked filelets requiring a compendium of flow  
> > charts and
> > dependency diagrams and spreadsheets to track effects.
> > I am actually in a day-mare trying to sort out such a problem at the  
> > moment.
> >
> > 3.  Access to standard libraries like LINPACK and NAG.  This may be  
> > a solved
> > problem, I haven't looked recently.
> >
> > 4.  We would have to be able to identify an organisation that would  
> > take
> > responsibility for supporting the compilers.
> >
> > The lack of knowledge of occam is an interesting one in its own  
> > right since
> > we are moving towards this same situation on Fortran.  My daughter  
> > has been
> > searching for a job in or around Edinburgh having completed her  
> > physics
> > degree.  She found plenty of jobs requiring Fortran knowledge but  
> > none for
> > Java.  Unfortunately the only programming language the university  
> > would
> > teach was Java.  I had a scan across a range on UK universities and  
> > found
> > the same was generally true - even including the Opne University.  I  
> > draw
> > the concluding that Sun is trying to do with Java what it did  
> > decades ago
> > for the early Sun workstations.
> > Edinburgh's stated justificaion was transportability, and then gave  
> > out
> > homework involving proprietary and University only libraries!
> >
> > As a matter of interest, we have the following numbers of people  
> > profient in
> > respective languages:
> >
> > Fortran   3
> > C         5
> > C++       1
> > Matlab    2
> > Tcl       3
> > PERL      1
> > Python    1
> > Pascal    2
> > Occam     1
> >
> > Java isn't even on the list and is not going to be for the forseealbe
> > future.  Even the new codes we are looking to develop over the next  
> > 5 years
> > will all be largely Fortran.
> >
> > I would love to have transputers available again.  The pain of  
> > making codes
> > run let alone well on Intel or AMD multi-core processors is not  
> > pleasant.
> > Occam would be used here if we could obtain from its use it's primary
> > benefit of programming large multi processor machines.  I might even  
> > realise
> > my dream of hybrid data and functional parallelism.  But this will not
> > happen till we have a reasonable way of launching code on multiple
> > processors from a perameterised architecture description - as we  
> > could from
> > the old TDS.
> >
> >
> > Regards,
> > Chris.
> >
> >
> >
> > Dr Christopher C R Jones C.Eng. FIET
> > Technologist Consultant
> > BAE SYSTEMS (Military Air Solutions)
> > Warton Aerodrome
> > Preston
> > Lancashire PR4 1AX
> > * tel: 01772 854625
> > * fax: 01772 855262
> > * e-mail: chris.c.jones@xxxxxxxxxxxxxx
> > BAE Systems (Operations) Limited
> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace  
> > Centre,
> > Farnborough, Hants, GU14 6YU, UK Registered in England & Wales
> > No: 1996687 Exported from the United Kingdom under the terms of the UK
> > Export Control Act 2002 (DEAL No ####)
> > <OpenComRTOS Matrix multiplication.pdf>
> 
>