Some exciting new trends in concurrency and software design

[jonathan <johnscpg@googlemail.com>]

I've pasted below a few interesting passages from an
interview with Joe Duffy. Joe Duffy is lead architect on an
OS incubation project at Microsoft, where he is responsible
for its developer platform, programming language, and
concurrency programming model.

Despite the snarky title to this thread, I was seriously
pleased to see someone in that position of influence speak
well of a concurrency model I like, (and to speak with
some honesty about its history).

http://www.infoq.com/articles/Interview-Joe-Duffy#view_69430

The interviewer begins with:

   The reason we wanted to talk to you
   is that research into concurrency and
   parallelism appears to have taken a turn.

Joe Duffy:

   ...according to the past several decades
   of research, no, this isn't a major
   shift to how parallel programs are architected.
   The Actor model, introduced nearly 40
   years ago, was truly revolutionary,
   and made 1st class the notion that agents
   would concurrently orchestrate some
   larger interesting task through message
   passing. This general idea has surfaced
   again and again over the years, accumulating
   useful extensions and variants over
   time. Hoare CSP's, Liskov's Argus, Occam,
   Ada, MPI, Erlang, and more recently,
   languages like Scala, Clojure, and Go.

On the other hand:

   ... yes, this is a major shift for most
   of the development community, because
   mainstream programming environments
   are now adopting the ideas that we've
   seen in research and experimental languages
   over the years.

In 5 years:

   I fully expect that C#, C++, and Java,
   for example, will have Actor-based offerings
   within the next 5 years. In the meantime,
   developers on such platforms will experiment
   with new languages, and continue to
   increasingly build architectures in
   this style without first class support
   in their primary environment....
   In fact, a very specialized class of
   programmers on this planet -- technical
   computing developers in HPC, science, and
   on Wall Street -- are already accustomed to
   doing this with specialized toolkits, like MPI.

Which reminds me - one of the reasons I was more than
happy to see MPI become entrenched in these communities
is that it gives people like Mr. Duffy something to point to
in defence of this programming style.
When I use MPI, it feels just like Ada '83 tasking,
partly because (like all the other MPI'ers I've talked
to) by default I use blocking message passing (rather than
asynchronous non-blocking options, which tend to scale badly):

https://computing.llnl.gov/tutorials/mpi_performance/#Rendezvous

Like I keep saying, it's just a remote rendezvous as far as I
am concerned, and I have much good to say about it. I find it
promotes good program structure, and makes reasoning about
concurrency straightforward.

Regarding more advanced methods for eliminating race-conditions,
etc:

   We write C# and Java code without needing
   to worry about type-system holes. An
   entire class of program errors is eliminated
   by-construction; it is beautiful. The
   same needs to happen for concurrency-safety.
   But it sure won't be easy retrofitting
   these concepts into existing languages
   like C#, C++, and Java.

The defense of strong static typing is much appreciated.
(But still ... it's the 21st century.  I wish universities
had made this advocacy unnecessary.)

   OOP developers are accustomed to partitioning
   their program into classes and objects;
   now they will need to become accustomed to
   partitioning their program into asynchronous
   Actors that can run concurrently.

Mr. Duffy likes the asynchronous, but I note that after
years of development, the Go concurrency model seems to
have become less asynchronous and more Ada-like (iiuc):

http://groups.google.com/group/golang-nuts/browse_thread/thread/b877e34723b543a7

As of February this year,

   Non-blocking channel operations have been
   removed from the language.

   The equivalent
   operations have always been possible using a
   select statement with a default clause. If a
   default clause is present in a select, that
   clause will execute (only) if no other is ready,
   which allows one to avoid blocking on a communication.


In a similar vein, here's another very interesting story -
Carnegie Mellon University (CMU) is removing OO from
its introductory courses. What's interesting is
the reason they're doing it.

http://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

Robert Harper (Prof. of Computer Science at CMU):

   Object-oriented programming is eliminated
   entirely from the introductory curriculum,
   because it is both anti-modular and anti-
   parallel by its very nature, and hence
   unsuitable for a modern CS curriculum...

Some more detail on this revolutionary idea:

https://existentialtype.wordpress.com/2011/04/16/modules-matter-most/

Robert Harper:

   Modules Matter Most

   When it comes to controlling the complexity
   of developing and, more importantly,
   maintaining a large system, the only
   game in town is modularity.  And as
   even the strongest proponents of unityped
   languages have come to accept, modularity
   is all about types (static types, of
   course, there being no other kind).
   ...
   We have for decades struggled with using
   object-oriented languages, such as Java
   or C++, to explain these simple ideas,
   and have consistently failed.  And I
   can tell those of you who are not plugged
   into academics at the moment, many of
   my colleagues world-wide are in the
   same situation, and are desperate to
   find a way out.

Professor Harper favors functional languages, SML in particular,
but at least he's on the right track;-)

J.