The Next Mainstream Programming Language: A Game Developer'sPerspective :: Redux

[Pragma]

BCS wrote:
> Reply to Sean,
> 
>> Well, there are a lot of ways to make it easier than explicit
>> manipulation of mutexes and such--some of the involved research dates
>> back to the early 60s--but even with these alternate methods,
>> concurrency isn't easy.
>>
> 
> 
> Murphy's Law #NaN: Concurrent programming is hard.
> 
> Might it be the case that there is something fundamental about 
> concurrent programming that makes it difficult for most, if not all, 
> people to work with? Might it be that the normal[*] human brain just 
> can't think that way?
 >
> [*] think Rain Man <g>

There are moments where I wish I could think *like* Rain Man, especially when it comes to concurrency.

At a minimum, science fiction is right on target with your comment.  In the Ghost in The Shell (Standalone Series), 
there is the occasional reference to an "Autistic Mode" that some cyber-brains have.  So throughout the story, you have 
some of these cyborgs flipping that switch whenever they need some Rain Man style insight to a given situation - like 
searching the internet as one would drink from a firehose, or performing wide-area surveillance via 100+ cameras at 
once.  If nothing else, it illustrates that there's something extraordinary about such abilities that may be permanently 
out-of-reach for normal people, despite the fact that some people are just born that way.

Given that cybernetic brain augmentation is a long way off, I think we're stuck trying to develop a better way to 
express the concurrent world in the common tongue of us "flat-landers".

$0.02:
But if you ask me what's needed, I think it comes down to the fact that concurrency is between the code and data, not 
just in the code.  So either the developer needs to balance those two, or the compiler needs to know more about your 
data in order to parallelize things.  Algol family languages (C, D, Java, etc.) are all in the first category, hence the 
  nature of this thread.  Erlang is an example of the latter, and benefits mostly from being a functional language (and 
from being purpose-built for parallelization).

I really think that we have the tools we need If we were to teach the compiler how to perform some calculus on data 
structures when their handled in iteration, it's reasonable to assume that it can take steps to parallelize things for 
us - this would get us about half-way to the kind of stuff functional languages can pull off.  The D2.0 additions for 
invariance and const-ness will probably help here.

-- 
- EricAnderton at yahoo