Hi all,My occam-com email got lost for a couple of months, so I've just been looking over the threads, and this thread is interesting. I think Ruth is exactly right in claiming that the "deadness" of occam and the Transputer are due to commercial events, and therefore the conclusion is illogical. That does not show a way out, but it does imply that if a way out is found, it has to be a cottage industry for a while - like Linux started as a cottage industry when Wintel domination was total.
Therefore I think two approaches from opposite sides will converge to the center that is now so dominated by "request-response" programming with its inherent centralization. (1) Do data flow designs on any project in any language. By this I mean design around the data transmission pipes, instead of around the actions (programs) or around the data units (objects). Work inward, toward the center, first by offering scripting, then by offering interpreted languages that quarantine the programs and objects between the pipes. (2) In the world of embedded programming, use only a subset of C (basically without the malloc and limiting calling sequence to compile-time known size) and thus make heap and stack unnecessary. Then work inward with an occam-like language that looks any way you like. The hardest part will be to replace or absorb the glibc-type libraries; it would be nice if we could figure out a way to use them.
Both these approaches allow us to ignore OO. Larry Dickson On Feb 24, 2009, at 4:05 PM, Ruth Ivimey-Cook wrote:
Andrzej Lewandowski wrote:Interesting. But... Occam, transputer, Kroc, all ARE THINGS OF THE PAST. Why you are playing with dead bodies instead of using your talent and knowledgeI'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.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 SampsonSent: 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. Thelatest, 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'reprobably 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 wrapthem 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.