Andrzej Lewandowski wrote:
I'm finding it hard to answer this thread - there are so many conflicting ideas and requirements as Andrzej's note shows. His comment reminds me of the old adage "A people who forget their history are doomed to relive it". There are indeed in occam and the transputer many ideas that are just as relevant to today's world as ever. For some details see my conference paper "//Legacy/ of the /transputer"/. /However, there is a perception problem: that because (for mostly commercial reasons) the transputer processor itself "failed"**, that occam and the transputer were necessarily a Bad Thing and to be condemned en-masse. This is unfortunate.Interesting. But... Occam, transputer, Kroc, all ARE THINGS OF THE PAST. Why you are playing with dead bodies instead of using your talent and knowledge to address problems that are current?
I can see that the current demand for multi-core systems is a great opportunity for CSP patterns to be used, and agree that without significant penetration into the mindset that will be lost. Perhaps this is an area that WoTUG can spend some money - out and out advertising and sponsorship? Anyway, the other side of the coin is that people are wedded to their existing ideas and systems, sometimes by commercial necessity.
The main barrier I have at my own workplace is that pretty much all of the >1 million line core codebase of the software is written in plain old C - and mostly to C89 standards - and there is a significant portability requirement. Some, in outlying areas, is in C++ or Java. New languages like C# and Ruby and Python are nowhere in sight.
The consequence is that from a work viewpoint I'm very interested in where a self-contained C-language CSP threads library might go, but bring C++ in and I lose interest again.
If we could come up with a serious competitor to the pthreads library, written in portable C, that would be wonderful. If it had versions in Embedded-C++ and C# that would be even better. I'm not convinced that Java is a platform that needs CSP in the same way, but I guess others are, so add in Java if you wish.
Regards, RuthP.S. I am (slowly) writing a new book describing occam-pi; at present it's about 100 pages of an early draft of the core language. I'm interested in feedback - if you would like to see it please write and ask.
**there are still transputers buried inside an awful lot of the set-top boxes of the world.
-----Original Message----- From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Adam Sampson Sent: Tuesday, February 24, 2009 12:50 PM To: occam-com@xxxxxxxxxx Subject: Re: JCSP, CSP Networking, and other some other points Bob Gustafson <bobgus@xxxxxxx> writes:I rather enjoyed reading Geraint Jones's two books on Occam. The latest, with Michael Goldsmith - "Programming In Occam 2 (2nd Edition) (Paperback)" is available on Amazon.Geraint Jones has made an updated version available for free online: http://www.comlab.ox.ac.uk/people/geraint.jones/publications/book/Pio2/ The KRoC and Transterpreter implementations of occam-pi are open-source and available for a variety of operating systems. KRoC is included with some Linux distributions, but it's under active development, so you're probably better off downloading the latest version from us: http://projects.cs.kent.ac.uk/projects/kroc/ The examples from the book will work directly in KRoC provided you wrap them in an appropriate top-level process (e.g. "PROC main (CHAN BYTE out)") -- but the extra facilities available in occam-pi over occam 2 can be used to simplify a lot of the code.