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

[John Demme]

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.

-- 
~John Demme
me at teqdruid.com
http://www.teqdruid.com/