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

[Sean Kelly]

Pragma wrote:
> 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.

Interesting.  In Vernor Vinge's "Fire in the Deep" (if I remember 
correctly), there are people who take drugs for basically the same 
purpose.  They're ship operators and such--jobs that require inhuman 
focus to perform optimally.

> 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.

Hm...  I guess the purpose would be some sort of optimal COW mechanism 
for shared data, or is there another use as well?  It's an intriguing 
idea, though I wonder if such a scheme would make the performance of 
code difficult to analyze.


Sean