The future of concurrent programming

[Daniel Keep]

Henrik wrote:
> Todays rant on Slashdot is about parallel programming and why the support for multiple cores in programs is only rarely seen. There are a lot of different opinions on why we haven�t seen a veritable rush to adopt parallelized programming strategies, some which include:
> 
> * 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 know concurrent programming has been a frequent topic in the D community forums, so I would be interested to hear the community�s opinions on this. What will the future of parallel programming look like? 
> Are new concepts and tools that support parallel programming needed, or just a new way of thinking? Will the �old school� programming languages fade away, as some seem to suggest, to be replaced by HOFL:s (Highly Optimized Functional Languages)? Where will/should D be in all this? Is it a doomed language if it does incorporate an efficient way of dealing with this (natively)?
> 
> 
> Link to TFA: http://developers.slashdot.org/developers/07/05/29/0058246.shtml
> 
> 
> /// Henrik

I think it's a combination of a lot of things.  Firstly, our languages
suck.  I know about Erlang, but Erlang is an alien language to all the
C, C++, C#, Java, etc. programmers out there; not only does it have a
weird syntax, but it's "functional", too.  Tim Sweeny once remarked that
Haskell would be a god-send for game programming if only they got rid of
the weird syntax[1].

Secondly, people think very linearly.  Some people break the mould and
seem to do well thinking in parallel, but it's damned hard.  The fact
that, up until now, most of us were working with single core CPUs that
meant there was little point in using parallelism for performance
reasons, also isn't helping things.

Let's not forget that our tools suck, too.  I've tried to debug
misbehaving multithreaded code before; I now avoid writing MT code where
at all possible.

I think the comment about programmers being stupid is just wrong.
People only learn what they're taught (either by someone else or by
themselves).  If they're never taught how to write good parallel code,
you can't suddenly expect them to turn around and start doing so.  Hell,
after four and half years of university, I've never needed to write a
single line of MT code for a subject.  Does that mean I'm stupid?

Before programmers can really start to get into parallel code, I think
several things have to happen.  First, we need some new concepts for
talking about parallel code.  Hell, maybe they already exist; but until
they're widely used by programmers, the may as well not.  Second, we
need a good, efficient C-style language to implement them and
demonstrate how to use them and why they're useful.  It being C-style is
absolutely critical; look how many people *haven't* switched over to
"superior" languages like Erlang and Haskell.  My money is on "it is
different and scary" being the primary reason.  We also need better
tools for things like debugging.

So yeah; I think concurrent/parallel programming *is* too hard.
Programmers aren't omniscient; just because you throw more cores at us
doesn't mean we automatically know how to use them :P

</$0.02>

	-- Daniel

[1] And change it so that it wasn't lazily evaluated, at least by default.

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/