I just came across a fascinating presentation called The Next Mainstream
Programming Language (see links at the bottom).

It was made by Tim Sweeney, the founder of Epic, a video game company that
created Unreal.

The title of the presentation is actually misleading, because the topics
addressed by Sweeney in his presentation are not exactly about the next
programming language but more a reflection on the programming requirements of
the video game industry with hard number and real code.  What makes this
presentation much more special than other typical talks trying to explain that
“performance is really important and you need to squeeze as much power as
possible in your code” is that Sweeney has obviously thought a lot about the
bigger picture behind these problems, and as a consequence, he offers some
startlingly insightful suggestions to address these problems, mostly coming from… 
Haskell.

That’s right, Haskell.

Now, Haskell is not exactly known for its speed, but the concepts that it
allows to express turn out to be a very fitting match for the challenges of
video game programming.

He breaks down game development in three distinct kinds of code, in
increasing order of FPU usage:

  • Gameplay simulation:  can run with lower animation speed and
    typically involves C++ and a scripting language (0.5 GFLOPS).
  • Numeric computation:  low-level, high performance code, almost
    exclusively C++ with a strong functional slant (5 GFLOPS).
  • Shading:  generates pixels and vertex attributes, runs on the GPU,
    "embarrassingly parallel" and done in a homegrown scripting language called
    HLSL (500 GFLOPS).

They use no assembly language.  Ever.

Here are some of the other points found in this presentation:

  • No languages today capture integers correctly.  What he means is
    that languages do have integers, of course, but most of the time, users
    really want a very distinct subset of integers (iterating over a loop,
    bounding an array, verifying certain conditions) and that if these
    constraints were enforced by the language, a lot of bugs could be avoided.
     
  • There is a wonderful correspondence between features that aid
    reliability and features that enable concurrency.
     
  • Lenient evaluation is the right default.
     
  • Purely Functional is the right default.
     
  • The Java/C#