March 24, 2006

A programming language for 2010

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# “exceptions everywhere” model should be wholly abandoned.  All dereference and array accesses must be statically verifiable, rather than causing sequenced exceptions
     
  • By 2009, game developers will face CPU’s with 20+ cores, 80+ hardware threads, 1 TFLOP of computing power and GPU’s with general computing capabilities.

Some of these assertions are quite bold and usually heard from hardcore language zealots without any justification, but Sweeney has plenty of hard data and convincing examples to make you think really hard about the implications of these ideas.  Besides, he can hardly be called a Haskell zealot: not only does he say "Haskell family:  [syntax] quite scary :-)", he also has a slide explaining why Haskell is not his favorite language.  But he knows to see beyond the surface and pick up the concepts that matter to make his job easier.

I have always argued that a lot of advances in user interfaces and programming paradigms have been driven by video games and game developers.  This presentation is making my point better than I ever could.

Note that you don't need to know anything about advanced graphic concepts to find this presentation interesting.

Links:  pdf, PowerPoint.

Posted by cedric at March 24, 2006 04:44 PM
Comments

Very interesting stuff, makes a lot of sense.

The idea that the compiler catches null pointers, array index out of bounds, etc is in start contrast to the rise in popularity of more dynamic languages such as Ruby and Python. In such languages the compiler does far less checking, and almost all statements are potentially unsafe at runtime.

Java-heads may be interested in "Nice". It runs on the JVM and incorporates some of the ideas from this presentation. Indeed, my favourite feature of Nice is that it eliminates NullPointerException :-). Unfortunately, the lack of docs and tools made it pretty hard for me to use it in my day job. http://nice.sourceforge.net/.

Posted by: Lachlan at March 25, 2006 06:01 AM

I agree with Lachlan. Nice is a safe and powerful language. I always ask myself why Java did not include similar features ?

Posted by: Laurent Simon at March 25, 2006 09:07 AM

There are a couple of IDE excensions for static nullability checking in the Java space:
http://www.jetbrains.com/idea/documentation/howto.html

There's similar work being done for Eclipse.

Posted by: Taras Tielkes at March 25, 2006 10:52 AM

Over here (since I am in Saarbrücken), Rustan Leino did a talk on Microsoft's work on Spec#, which looked like the way in which the Java language should be moving in the future:

* Nullable Types
* Pre/PostConditions
* Static Verification to enforce the contracts
* Out-of-band specifications
* Ways to go from C# to Spec# and back
* Integration with IDEs

It's a bit like a working combination of JML, nice, and ESC/Java work. Very exciting stuff.

See http://research.microsoft.com/~leino/papers/SpecSharp-MPI-SS.ppt for the slides.

cheers,
dalibor topic

Posted by: Dalibor Topic at March 25, 2006 12:49 PM

Over here (since I am in Saarbrücken), Rustan Leino did a talk on Microsoft's work on Spec#, which looked like the way in which the Java language should be moving in the future:

* Nullable Types
* Pre/PostConditions
* Static Verification to enforce the contracts
* Out-of-band specifications
* Ways to go from C# to Spec# and back
* Integration with IDEs

It's a bit like a working combination of JML, nice, and ESC/Java work. Very exciting stuff.

See http://research.microsoft.com/~leino/papers/SpecSharp-MPI-SS.ppt for the slides.

cheers,
dalibor topic

Posted by: Dalibor Topic at March 25, 2006 12:49 PM

Hi Cedric and all,

I've still got letters from Tim Sweeney dating back to the early days of Epic Megagames (when Jack Jazzrabbit was in development, way before the first line of code of the first Unreal had been written and even before everybody had Internet access).

:)

One of my "all-time Tim favorites" is a paper on how the game state replication was done in Unreal, written in 1999 by Tim Sweeney. It is still good today and was just plain visionary back in the days.

You didn't emphasize on something very important he's saying now: we're moving to more complex systems and... Type inference doesn't scale.

Funny how everybody who responded so far talked about Nice, JML, Jetbrains's annotations.jar (@NotNull/@Nullable), etc. There are obviously people who want "more control". And I'm one of these people (I do use IDEA 5.x/JDK 1.5 and @NotNull is a real time-saver): the stricter the limit you put on your abstract data types, the easier you make it for the compiler to "proove" that the various components will act as their contract say they will, the sooner you catch bugs, etc.

You didn't mention it directly but he also talks about the benefits of referential transparency ... (one obvious advantage being to allow the use of memoization [yup, without an 'r'], one other advantage being to help the compiler "proove" the correctness of some part of the program).

I side with everybody who recommends functional programming (and Joshua Bloch hints that it is possible to program in Java in a more functional way that what is usually seen, Effective Java item 13).

And I side with everybody who's horrified by the horrible abuse of exceptions (the glorified goto's) in Java and C#.

It is really good to see his hard data backing his statements on all the defects Java has and... terminating the presentation with a full page devoted to one of Haskell's main flaw: type inference doesn't scale.

I hope that the "next mainstream programming language" will ressemble the best of several worlds (I've got my idea as to how it should look like... And I'm more than convinced it is *very* similar to Tim Sweeney's view).

Really a good read, thanks for that nice blog entry,

(I'll go check those Spec# slides now...)

Posted by: nono at March 25, 2006 03:06 PM

Check out Scala:

http://scala.epfl.ch

It's got a lot of things inspired by Haskell, with a nicer looking syntax and stronger typing than Java, although it does provide for type inference... I'm not sure how type inference works in Haskell, but in Scala it's done by the compiler, so I'm not sure how that is supposed to break at runtime...

It looks like an interesting combination of OO and functional programming so far... and it runs on the JVM or the .NET CLR.

Posted by: Jason Carreira at March 26, 2006 12:23 AM

The most exciting thing for me about spec# was that the underlying theorem prover, the intermediate language and all the pretty nice machinery to prove the properties worked transparently, on the fly, without the IDE user noticing (or having to know) anything about the underlying ATP, it's syntax, logic, proving programs correct, etc.

It was a bit like DHH's ROR demo: call a method from the standard class libraries, finish typing, a red squigly line would appear almost insabtly and a pop up box would tell you that you may end up violating a specific contract (for example your array index going out of bounds for a substring method), type some more, another squigly line ... until your specifications and your code matched. Proving program properties beats unit testing, in my opinion. In particular having the fun part (actual proofs) being done automatically and quickly in the background.

cheers,
dalibor topic

Posted by: Dalibor Topic at March 26, 2006 03:27 AM

Wanted to read the Spec# slides but I wasn't able to. Some people still think PPT is a universal exchange format :-(

Posted by: Stephan Schmidt at March 26, 2006 12:10 PM

Definitely nice reading.

However the example on circularity (page 36) is really not convincing. He should have put some real world example.

An argument I don't get is that he goes from execption everywhere to exception nowhere (except where explictly asked for). There are some cases where this can't be avoided: what about data read from a file a user can change (.ini comes to mind)?

I also don't agree with slide 61, The Coming Crisis in Computing:

- I don't think we will get 20 cores each with 4 way hw threads by '09; look at AMD and Intel roadmaps... Anyway multi threading will expand, though probably not as symetrically.

- hardware is already reaching 1 TFlops (see PS3 Cell)

- GPU's already have general computing capabilities though it's not that easy to get it (see http://www.gpgpu.org/ or recent announcements by NVIDIA and Havok).

A side note is that PS3 hardware is probably a hint at what the future looks like, much more than XBox 360. I really think the direction is heterogeneous computing.

BTW HLSL is not a scripting language, it is DX9 shading language (more or less the same as NVIDIA's cg).

Posted by: Laurent at March 27, 2006 06:36 AM

除尘器

Posted by: 除尘器 at March 31, 2006 12:30 AM

I find it strange that much of the language features he calls have been available to those programming in Ada since the early 80's yet there is no mention of Ada. Ada has high-level concurrency support (rendezvous, protected objects, suspension objects), strong typing, real arrays, support for object oriented programming etc.

For example the Transform method on page 31 of the PDF would be straightforward to express in Ada such that all the requirements were satisfied.

What Ada is missing though is lazy evaluation (although the compiler will warn about uses of uninitialized values) and C-like syntax (Ada is a far descendant of Algol family, thus to most people it looks like Pascal). The verbose syntax, however is justified since the user-defined types define contracts, and is therefore not really a burden.

Posted by: -L at April 7, 2006 01:06 AM

Isn't this "homegrown" HLSL language made by a small garage company called Microsoft?

Posted by: lol at April 7, 2006 03:59 AM

Isn't this "homegrown" HLSL language made by a small garage company called Microsoft?

Posted by: lol at April 7, 2006 04:00 AM

I have a question to the people posting on this thread, if someone can kindly answer, what does it take to have a job in the game programming industry or even programming, I would just like to understand what qualifications did you get, what did you have to learn to know the stuff you know?

Posted by: Bobby Fellon at May 22, 2006 12:47 AM

They use C++ with SIMD intrinsics. This is basically inline assembly.

Cheers.

Posted by: Rene Dudfield at May 30, 2006 05:33 PM

If anyone is looking for a language that offers most of what is asked for here and doesn't suffer from the original sin that will end up strangling some of the suggested JVM/CLR variants, take a look at Erlang.

_Strong_ concurrency support, almost purely functional (you can create side-effects by using what is known as the process dictionary, but this is discouraged), very nice fault-tolerance and reliability features, hot-swappable code, and lazy evaluation. It even offers a shell-like interface so you can play around with bits on the fly.

As far as which language will end up being "hot" in five years due to the requirements stated in the original article, I am betting on either Erlang, OCaml, or Haskell. While I personally favor Erlang I think that OCaml is probably the leading candidate in this group at the moment...

Posted by: Jim McCoy at May 30, 2006 10:27 PM

To me this sounds pretty similar to what the guys are Intentional Software are saying.

http://www.intentsoft.com/

I've also read a few Martin Fowler articles that express similar ideas. And before that, it's hit me as well independently: we don't need more run-time dynamicity, we-need compile time dynamicity. The ability to extend your language without losing early checking. Design contracts, not just on method entry and exit points, but on any language element (from expressions to classes to packages) is what we need.

Posted by: Wouter Lievens at June 7, 2006 07:13 AM

"No languages today capture integers correctly". Err...Delphi/pascal has integer subranges and can enforce range checking.

var i : 1..3 ;

is a valid declaration.

Posted by: justasecond at June 21, 2006 11:54 AM

Haskell is fast enough: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Posted by: Stefan Scholl at June 22, 2006 11:15 AM

Qi [http://www.lambdassociates.org/] would be another interesting alternative with it's Turing-equivalent type notation.

For example, interval arithmetic in Qi:
http://www.lambdassociates.org/studies/study01.htm

Posted by: simon at June 23, 2006 01:35 AM

Qi (http://www.lambdassociates.org/) would be another interesting alternative with it's Turing-equivalent type notation.

For example, interval arithmetic in Qi:
http://www.lambdassociates.org/studies/study01.htm

Posted by: simon at June 23, 2006 01:37 AM

I'm sure as hell glad Tim Sweeney's ideas of language design have changed since ZZT-OOP. :) :)

Posted by: Frater Plotter at July 2, 2006 12:21 PM

yea! fascinating presentation thanks for link!

Posted by: Praca at October 8, 2006 12:27 AM

Heh, yeah, ZZT-OOP sucked! But it was a lot better than hardcoding the behaviour of one-of-a-kind things in the engine.

Posted by: Sam Bronson at October 23, 2006 02:53 PM

This presentation is professional and to the point.

Posted by: BUses at December 4, 2006 06:16 PM

"All dereference and array accesses must be statically verifiable, rather than causing sequenced exceptions"

Heh. Call me when you solve that and the Halting Problem, which are equivalent.

Posted by: Futureboy at December 15, 2006 02:16 AM

Sweeny doesn't like the Agol/Pascal/Modula/Ada family which is why there was no mention of Ada, which has nearly all the features Sweeny was talking about.

Posted by: Former Game Programmer at January 21, 2007 11:13 PM

Sweeny doesn't like the Agol/Pascal/Modula/Ada family which is why there was no mention of Ada, which has nearly all the features Sweeny was talking about.

Posted by: Former Game Programmer at January 21, 2007 11:13 PM

Sweeny doesn't like the Agol/Pascal/Modula/Ada family which is why there was no mention of Ada, which has nearly all the features Sweeny was talking about.

Posted by: Former Game Programmer at January 21, 2007 11:15 PM

Yeah, Futureboy, to take an arbitrary program in a non-safe language and analyze whether its dereferences/array accesses are safe is equivalent to the Halting Problem. But that's not what Tim is proposing. He's proposing the use of a safe language, in which, in order to make a dereference/array access, the programmer has to supply enough information to the compiler to prove the safety of that access (with an elegantly designed system, in many real-world cases, the compiler will have enough information to deduce the safety on its own, without extra information from the programmer beyond the same sort of code as he would typically write today. In such cases as that this will not be enough, the programmer will have to modify his code and/or provide some extra information for the safety proof, perhaps (in the easiest but least satisfying way) through wrapping the access in a run-time safety check).

So Tim's goals aren't incompatible with the undecidability of the Halting Problem; he doesn't want to take existing, potentially unsafe code and algorithmically analyze it for safety. He wants to ask programmers (who presumably have an idea in their head of why their code is safe) to code in a manner which makes this safety clear.

Or, to just make it clear that Tim's goals are entirely possible: algorithmically determining whether a C program has no null pointer dereferences is of course impossible, for Halting Problem reasons. But nonetheless, many serious general-purpose languages exist in which null pointer dereferences simply cannot happen in code which successfully compiles (e.g., in Standard ML).

Posted by: Sridhar at March 26, 2007 02:47 AM

"By 2009, game developers will face…
§ CPU’s with:
– 20+ cores"
Hmmm...Game developers wants to launch a game for 20 cores in 2009 or they want to start thinking about it?

Posted by: Leba at May 29, 2007 11:45 AM

20+ cores... damn! I`m a game addict and i can`t wait !

Posted by: sprezarki at October 15, 2007 01:43 AM

The examples "type inference doesn't scale" I feel are misleading. Actually the problem is Haskell's implementation. He talks about wanting contract enforcement without exceptions, typing is one of the means to that end. Because Haskell doesn't autoconvert a string to an int in a "duck" type way, doesn't mean that it doesn't scale. The type-classing in Haskell would be a better example. That stuff is really useful, but when one needs it downstream in the process, it was probably not done upstream. Then the ouch sets in.

Posted by: shawn at October 22, 2007 01:21 PM

20+ cores - great result

Posted by: Ryanair at October 30, 2007 06:36 AM

Ok we have almost 2008, the newest CPUs have 4 Cores, could be 8 by 2009. Dont think it will be 20+.. btw. the Unreal 3 engine is overhyped, it doesnt look sooo good everybody says. The New Unreal Tournament screens arent that impressive from my point of view, what u guys say about that?

Posted by: Zutestrane at November 11, 2007 03:28 PM

Ok we have almost 2008, the newest CPUs have 4 Cores, could be 8 by 2009. Dont think it will be 20+.. btw. the Unreal 3 engine is overhyped, it doesnt look sooo good everybody says. The New Unreal Tournament screens arent that impressive from my point of view, what u guys say about that?

Posted by: Zutestrane at November 11, 2007 03:28 PM

How does Haskell aid in multiprocessing?

Any comparison with Erlang, which extends to multiprocessing systems with no additional programming required?

Posted by: narus at December 19, 2007 10:04 AM

thnaks for the archives

Posted by: barbie oyunları at January 19, 2008 10:19 AM

I hope that in 2010, my computer can have amy core. Currently, i am still using old pentium 4 computer and it can't multi task. Hopefully by then, we are able to do many mutli task!

Posted by: Blog Directory at January 20, 2008 07:04 PM

I have just bought a quad core 6600 2.4ghz, it really is fast compare to me old pc. I can't imagine having 10 or 20 core!!

Posted by: James burt at February 27, 2008 11:21 PM

you said:
By 2009, game developers will face CPU’s with 20+ cores, 80+ hardware threads, 1 TFLOP of computing power and GPU’s with general computing capabilities.

I say: Ha ha!

Posted by: mike at March 17, 2008 08:26 AM

08, the newest CPUs have 4 Cores, could be 8 by 2009. Dont think it will be 20+.. btw. the Unreal 3 engine is overhyped, it doesnt look sooo good everybody says. The New Unreal Tournament screens arent that impressive from my point of view, what u guys say about that?

Posted by: rabbit vibrator at March 25, 2008 07:07 AM

I guess the next mainstream programming language is going to be Ruby! It definitely rules, check it out!

Posted by: Webdesigner at May 8, 2008 07:43 AM

Great and excellent article it’s realy helpful. Thanks again.

Posted by: bilard at May 24, 2008 02:38 AM

his example in the slide "type-inference doesnt scale" seems plain misguided to me.

of course string is not an integer, you have to "process" the string to make it an int, even in c ...

and if he is talking about an scripting lang. built on top of the statically typed core lang (ie. haskell), it's the scripting lang's task to know the right types and automatically cast the values so the programmmer doesn't have to.

would sb. enlighten me WTF was he trying to say/ how should i translate so it would make some sense ?

Posted by: ankh47 at September 4, 2008 12:13 PM

exactly

Posted by: voyance at October 3, 2008 01:33 PM

Incredible efforts and work is put into creating a video game. Never acknowledged this until I saw the Powerpoint presentation

Posted by: Ali at October 20, 2008 12:44 AM

i'am agree with you

Posted by: Voyance at October 31, 2008 04:41 AM

Lots students transpire the duty to qualified resume writers because they miss the ability to write a respectable resume so the cause why you
need to resume writer, but such customers like composer don't do that. Thanks a lot for the topic. Very good topic about A programming language for 2010.

Posted by: alex at September 9, 2009 12:36 AM
Post a comment






Remember personal info?