Will multithreading make python less popular?

[andrew cooke]

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" <aahz at py....aft.com> wrote:
>
>
>> In article <mailman.52.1234797812.11746.python-list at 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
>
>