The future of concurrent programming

[BCS]

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
> 

My issue with functional languages is that, in the end, what the CPU 
does will be imperative. Why then wright stuff in a functional language? 
If it is a concession to our ability to understand stuff, why functional 
as the abstraction? I find it harder to think in a functional manner 
than in an imperative manner. If we need an abstraction between us and 
the CPU, I would rather make it an "operative" or "relational" 
abstraction (something like UML only higher level). This would provide 
the abstractions need for things other than just concurrence, like 
memory management (no deletes like GC'ed languages but all of the 
"manual" memory management is handled by the compiler) or data access, 
(pure getter functions would disappear and "wormhole" functions would 
appear for common complex access chains). I guess what I'm saying is 
that I see functional languages are in between the level that the 
computer needs to work at and the level that the programmer actually 
thinks at. There two hight level to allow the programmer to 
"bit-twiddle" but not high enough that the programmer to abstract to the 
level that would really let the compiler take over the boring but 
critical stuff.

But I rant :)