The future of concurrent programming

[Thomas de Grivel]

freeagle Wrote:

> Why do people think there is a need for another language/paradigm to 
> solve concurrent problem? OSes deal with parallelism for decades, 
> without special purpose languages. Just plain C, C++. Just check Task 
> manager in windows and you'll notice there's about 100+ threads running.
> If microsoft can manage it with current languages, why we cant?

Maybe because we may want to parallelize arbitrary bits of code,
much like URBI does by introducing other statements combinators than ';'.
They introduce syntax like

> whenever (ball.visible) {
>   head.rotX += ball.alpha   &   head.rotY += ball.tetha;
> }

Notice how the two statements are combined with '&' and not ';' which
means that they are to run *simultaneously*. URBI is event driven : the
'whenever' keyword indicates the block is to be executed every time the
statement is true. There are other combinators to force a task to start
before another, express mutual exclusion, etc

This is so easy to understand and use that kids can play with it already.
URBI was designed to control robots and this all implies an event-driven
paradigm but to me it shows that powerful parallelization primitives can
be expressed using very simple syntax.

I believe much parallel-computing research is still ongoing but now more
toward implementations than its theory as it was already done few decades
ago. Parallel computing primitives are well known by researchers but is
just not taught at all since it was only available to big corporations/universities
and large computing clusters. Now every new CPU has multiple cores and
we have to introduce PP concepts into "everyday programming" but I'm sure
there's a clever and simple way to achieve it, in the style of garbage collection
vs manual memory handling. These are like parallelisation *very* complex tools
to design and to understand fully, but they are made really easy to use by the
approach D has taken.

-- 
  Thomas de Grivel
  Epita 2009