The future of concurrent programming

[Mikola Lysenko]

Henrik Wrote:

> * Multiple cores haven't been available/affordable all that long, programmers just need some time to catch up.
> * Parallel programming is hard to do (as we lack the proper programming tools for it). We need new concepts, new tools, or simply a new generation of programming languages created to handle parallelization from start.
> * Parallel programming is hard to do (as we tend to think in straight lines, lacking the proper cognitive faculties to parallelize problem solving). We must accept that this is an inherently difficult thing for us, and that there never will be an easy solution.
> * We have both the programming tools needed and the cognitive capacity to deal with them, only the stupidity of the current crop of programmers or their inability to adapt stand in the way. Wait a generation and the situation will have sorted itself out.
> 

I'm going to go out on a limb and suggest a 5th possibility:

* Parallel programming is easy for today's programmers.

Writing code to do two things at once is not at all challenging.  Just fork two threads, and let them do their thing, collect the result whenever.  Of course, I don't mean to trivialize threads code - it is certainly a task that requires enormous skill.

The difficulty is not within parallel execution, but instead within the communication.  Therefore, a better statement would be:

* Concurrent programming is hard for today's programmers.

In the Communicating Sequential Processes (CSP) sense of the word, concurrent programs are made out of two basic elements; processes and connections.  From a formal perspective, this is just a generalization of the idea of a call stack - programs can now split into multiple stacks and communicate between themselves.  Instead of a call hierarchy, we have a graph of interconnected processes.

>From this definition, it should be obvious that concurrency is not just an issue for threads code, but rather it is relevant to ordinary stuff like GUIs, videogames and operating systems.  Concurrency is an everyday phenomenon, that we have all dealt with in some way or another - its just that few programmers bother to put a name on it.  This is a damn shame, since there is so much we can gain from understanding programs in these terms.  Some powerful examples are given in Rob Pike's NewSqueak presentation:

http://video.google.com/videoplay?docid=810232012617965344&q=rob+pike+newsqueak+google


-Mikola Lysenko