The Next Mainstream Programming Language: A Game Developer?s Perspective

[kris]

John Demme wrote:
> Marcio wrote:
> 
> 
>>http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
> 
> 
> This was a very, very interesting presentation.  Tim makes a lot of very
> good points, and a very large portion of it applies far past game
> development.  To that end, there are a lot of items in there which I hope
> will be features for D 2.0.
> 
> In particular, I'm hoping that Walter's got some ideas concerning
> parallelism.  I don't think there's any doubt that a language which excels
> at allowing programmers to massively parallel code easily would be
> absolutely invaluable.  Although I think that a lot of parallel-assist
> mechanisms should and can be implemented in a library, but some compiler
> assisted stuff would be great.
> 
> Some for instances:
> -object versioning could help a library to implement non-locking
> transactional writes (does this terminology make any sense?).
> -If the compiler could somehow tell a library whether or not two functions
> ever write to the same memory, the library could schedule one to run after
> the other or in parallel. 
> -What if the compiler could tell a library that a certain function call
> never writes to and/or reads from existing heap space?
> -Race condition checking and possible dead-lock checking are also obvious
> assists.
> -Some interface for a library to manage the code execution would also be
> cool:
> manager(ParallelComputation) {
>         float foo() {
>                 float pi = calcPiLotsofAccuracy();
>                 long rects = getRectangleCount();
>                 return pi * rects;
>         }
> }
> If the compiler can tell "ParallelComputation" manager that
> calcPiLostofAccuracy() and getRectangleCount never write to the heap, it
> will execute them in parallel.  Clearly, we could just introduce a keyword
> to tell the compiler to do this, but allowing some interface for some other
> component of the program to manage execution would allow for great
> flexibilty, like functionally-specific thread-pools, or various
> prioritization algorithms.
> 
> Here's another thought:
> D's in and out function blocks are great, but could we get some
> automagically generated stuff?  For instance,
> void foo(notnull Object o){}
> would automatically put an assert(o) in the in block.  Better yet, what
> about some way to genericize that, so we could have something like in block
> mixins?
> template LessThan(A,B) {
>         in {
>                 assert(A < B);
>         }
> }
> template NotNull(O) {
>         in {
>                 assert(O);
>         }
> }
> void var(Object o, int i, int j) LessThan!(i,j), NotNull!(o) {
>         //o won't be null, and i is less than j!
> }
> 
> 
> I dunno if any of these are decent ideas, but the above slides sparked some
> ideas and real thought about some cool features, and I figured I might as
> well throw some of them out there as food for thought....
> 
> Real point of the post, I guess:
> 
> Clearly some (err.. all) of these thoughts are quarter-baked, extreme ideas,
> so I what I'm saying is that I'd like to get D 1.0 out there so we can move
> on to some really innovative and extreme features....  D's pretty great as
> is, but it's not the quantum leap forward needed to really assist
> programmers with new challenges; it's got some really great potential to
> get there, though.
> 


CSP has been around for 30 years to address much of these concerns. 
Amusingly, certain somewhat prominent figures are 'rediscovering' CSP 
and calling it their own. You might be interested in reading up on Tony 
Hoare's CSP, and a principal implementation, occam ?