why do you think that current work is ignorant of occam? occam itself was based on hoare's "communicating sequential processes" which is a classic of the field. the ideas behind occam are not unknown and it hasn't been forgotten (there are many libraries based on synchronous message passing; one for java called jcsp for example - http://www.cs.kent.ac.uk/projects/ofa/jcsp/ ; the "rendezvous model" (receiving tasks wait for messages) is used in ada).
but really it did very little to hide the complexities of parallel computing - it's famous because it (and the transputer platform) was one of the first languages to take parallelism "seriously", not because it presented any kind of silver bullet (more generally, it was a pretty crude language, more suited to small embedded applications than large projects - it didn't even have dynamically sized arrays) there's a comment here http://lambda-the-ultimate.org/node/2437 that shows the limitations of occam: "I used Occam (the transputer implementation of CSP) very heavily in the 1980s and early 1990s, and eventually started referring to channels as "the return of the GOTO", since in any moderately complex application, you spent a lot of time wondering, "If I put bytes in *here*, who will they go to?" Addressable actors and/or tuple spaces both felt much more scalable (in the coding sense)." (disclaimer - i haven't used it personally. once i was asked to maintain an occam system, but somehow managed to dodge the responsibility) if you look at erlang, which is one of the more successful parallel languages at the moment, you'll see some similarity to occam (message passing is explicit), but shifting to asynchronous messages helps give a more robust system. andrew Hendrik van Rooyen wrote: > "Aahz" <a...@py....aft.com> wrote: > > >> In article <mailman.52.1234797812.11746.python-l...@python.org>, >> Hendrik van Rooyen <ma....orp.co.za> wrote: >> > >> >Occam was the language that should have won the marketing prize, but >> >didn't. >> >> It wasn't simple enough. > > I thought (at the time) that it was quite good at hiding some > horrible complexities of communication between different > processes on the same, and different processors. > > All done by the compiler, automagically. > > I think now that a hard look at the underlying techniques > used then could add something to the debate referred to > earlier - but there may be a barrier because the dataflow > or systolic array type programming model is not one > that is currently fashionable. > > - Hendrik > > > -- > http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
