subbukk <subbukk at gmail.com> writes:
> On the contrary, it is much simpler to write and reason about programs if 
> multiprocessing capability is given.   Dijkstra's do-od structure was 
> inherently multi. But building machines to 'execute' such programs was hard, 
> so system designers invented languages that forced programmers to code for 
> efficiency rather than simplicity. This trend was beautifully captured by 
> Gerald Weinberg in his story of Levine the Genius Tailor:
> 
>   http://www.zafar.se/bkz/Articles/GeniusLanguageDesigner

That's a cool story.  It sounds just like language design!


I am not so sure, however, that we have found even great ways to
*think* about parallel programs.  Dijkstra's discussion of do-od is
really cool.  However, here are two challenges it does not address:


1. Even when you are thinking about formal proof, like Dijkstra was,
   parallelism in large OO programs means you have to reason about
   aliasing, i.e. you have to do data flow analysis.  This is hard,
   probably too hard if the language is unconstrained.


2. Most programs are not formally proven.  Instead, their correctness
   relies on careful reasoning, on good processes, and on testing.
   Parallelism undermines the testing part.


The jury is out.  One promissing avenue, though, is the message
passing used in E and in Actors-based systems.  You can try this style
in Squeak by using SynchronizedQueue's.  Instead of having locks to
protect shared data structures, you eliminate sharing and instead
assign each structure to a single thread.  Any other thread that wants
to access the structure, must do it by sending a message to the
appropriate thread.  In Squeak, you can implement the message sending
using SynhcronizedQueue's.


Lex