February 05, 2006
Tim Sweeney gives a presentation at POPL 2006
Last month, Tim Sweeney of Epic Games (developers of the Unreal engine) gave a presentation titled, "The Next Mainstream Programming Language: A Game Developer's Perspective". Although I did not attend the POPL 2006 conference, I found reading the slides interesting. They can be opened with Open Office if you don't have Microsoft Powerpoint.
On the opening slide, he argues that the programming languages we use for game development today fail us in two ways.
"Where are today's languages failing?
- Concurrency
- Reliability"
Next generation consoles such as Xbox 360 and Playstation 3 have multiple parallel processors and the languages we typically use (mostly C++) offer almost no help in utilizing them beyond some libraries with low-level thread synchronization primitives like semaphores and mutexes. As for reliability, we all know how easy it is in C++ to dereference a null or dangling pointer, deallocate a reachable object or index off the end of an array.
I fully agree that these two areas need to be addressed in future programming languages for game development. Further, I think there is something even more important: productivity.
Although better reliability and language support for concurrency can certainly improve productivity, if only as a secondary effect, it should be addressed directly. For example, a C++ program with 100,000s of lines of code can take several minutes to build, even for relatively small changes (for example to a header file). This can certainly be improved by careful management of physical dependencies between source files and use of programming practices like the pimpl idiom.
But compare this to a similarly sized program written in Java, which can be rebuilt from scratch in seconds and where the build times for incremental changes are imperceptibly quick. The Java IDE that I have been using recently (Eclipse) builds every time I save a source file so the project is always up-to-date and ready to run immediately.
I was a little disappointed that he only briefly mentioned the subject of tools. By tools I mean, for example, the software that we use to make game content and the software that runs behind the scenes building all the game assets and gluing them together. This becomes more important every year as we squeeze more and more content into games.
Here as well, productivity is key. Not just the productivity of individual programmers but the productivity of the whole team. A new programming language can only be a small piece of that puzzle. But there are certain language features that can make a difference. Reflection is number one on my list. Reflection can be used to automate many software problems involving interoperation between tools and game code, such as automatic GUI generation, versioning, distributed builds, etc.
As with productivity, I would rate reflection (or some similar language feature) above language support for concurrency. At least for next generation consoles. Maybe not next-next-generation!
From his slides:
"Solved problems:
Random memory overwrites
Memory leaks
Solvable:
Accessing arrays out-of-bounds
Dereferencing null pointers
Integer overflow
Accessing uninitialized variables
50% of the bugs in Unreal can be traced to these problems!"
I'm not sure why "accessing uninitialized variables" is listed as only solvable. It is solved! With the exception of C++, no mainstream language I know of allows the programmer to access an uninitialized variable. That is entirely a C++ problem and can be avoided by using a language like Java or Lua for example.
In most languages, the other three "solvable" problems result in runtime exceptions. Even integer overflow can be checked at runtime by some languages such as C#. Sweeney argues that we would be better off if these problems were caught at compile time. In a sense I agree because when I introduce a bug into a program, I want to know as soon as possible. I would rather have the compiler tell me immediately (or in 10 minutes if I am using C++!) than get a report from QA several months later and spend hours tracking down the problem.
But I don't think compile time checks are the best solution. More than likely they will complicate the language. The examples of programs annotated with compile time checks from his slides certainly look more complicated than they would be without. Also, I am sure there will be cases where the compiler will not be smart enough and either miss a problem or be too conservative and raise an error when there is no problem.
It seems to me that unit testing is a better solution. If one uses TDD to ensure that every line of code is thoroughly covered by unit tests then the introduction of such a bug will result in a unit test failure in the majority of cases. And if unit tests are run after every compile, then the offending bug will be identified immediately at compile time, without any changes to the programming language.
Something I have been thinking about is how one might better design a language to support TDD. But that will have to be the subject of a future post.
On the opening slide, he argues that the programming languages we use for game development today fail us in two ways.
"Where are today's languages failing?
- Concurrency
- Reliability"
Next generation consoles such as Xbox 360 and Playstation 3 have multiple parallel processors and the languages we typically use (mostly C++) offer almost no help in utilizing them beyond some libraries with low-level thread synchronization primitives like semaphores and mutexes. As for reliability, we all know how easy it is in C++ to dereference a null or dangling pointer, deallocate a reachable object or index off the end of an array.
I fully agree that these two areas need to be addressed in future programming languages for game development. Further, I think there is something even more important: productivity.
Although better reliability and language support for concurrency can certainly improve productivity, if only as a secondary effect, it should be addressed directly. For example, a C++ program with 100,000s of lines of code can take several minutes to build, even for relatively small changes (for example to a header file). This can certainly be improved by careful management of physical dependencies between source files and use of programming practices like the pimpl idiom.
But compare this to a similarly sized program written in Java, which can be rebuilt from scratch in seconds and where the build times for incremental changes are imperceptibly quick. The Java IDE that I have been using recently (Eclipse) builds every time I save a source file so the project is always up-to-date and ready to run immediately.
I was a little disappointed that he only briefly mentioned the subject of tools. By tools I mean, for example, the software that we use to make game content and the software that runs behind the scenes building all the game assets and gluing them together. This becomes more important every year as we squeeze more and more content into games.
Here as well, productivity is key. Not just the productivity of individual programmers but the productivity of the whole team. A new programming language can only be a small piece of that puzzle. But there are certain language features that can make a difference. Reflection is number one on my list. Reflection can be used to automate many software problems involving interoperation between tools and game code, such as automatic GUI generation, versioning, distributed builds, etc.
As with productivity, I would rate reflection (or some similar language feature) above language support for concurrency. At least for next generation consoles. Maybe not next-next-generation!
From his slides:
"Solved problems:
Random memory overwrites
Memory leaks
Solvable:
Accessing arrays out-of-bounds
Dereferencing null pointers
Integer overflow
Accessing uninitialized variables
50% of the bugs in Unreal can be traced to these problems!"
I'm not sure why "accessing uninitialized variables" is listed as only solvable. It is solved! With the exception of C++, no mainstream language I know of allows the programmer to access an uninitialized variable. That is entirely a C++ problem and can be avoided by using a language like Java or Lua for example.
In most languages, the other three "solvable" problems result in runtime exceptions. Even integer overflow can be checked at runtime by some languages such as C#. Sweeney argues that we would be better off if these problems were caught at compile time. In a sense I agree because when I introduce a bug into a program, I want to know as soon as possible. I would rather have the compiler tell me immediately (or in 10 minutes if I am using C++!) than get a report from QA several months later and spend hours tracking down the problem.
But I don't think compile time checks are the best solution. More than likely they will complicate the language. The examples of programs annotated with compile time checks from his slides certainly look more complicated than they would be without. Also, I am sure there will be cases where the compiler will not be smart enough and either miss a problem or be too conservative and raise an error when there is no problem.
It seems to me that unit testing is a better solution. If one uses TDD to ensure that every line of code is thoroughly covered by unit tests then the introduction of such a bug will result in a unit test failure in the majority of cases. And if unit tests are run after every compile, then the offending bug will be identified immediately at compile time, without any changes to the programming language.
Something I have been thinking about is how one might better design a language to support TDD. But that will have to be the subject of a future post.
# posted by Alastair Patrick : 1:18 PM
Comments:
<< Home
> Something I have been thinking about is how one
> might better design a language to support TDD. But
> that will have to be the subject of a future post.
I'd love to hear your thoughts on that, so don't leave us hanging.
I've been wondering about that myself for a while, and most of the ideas I end up with closely resemble Smalltalk/Ruby/Python. Funny that :-)
> might better design a language to support TDD. But
> that will have to be the subject of a future post.
I'd love to hear your thoughts on that, so don't leave us hanging.
I've been wondering about that myself for a while, and most of the ideas I end up with closely resemble Smalltalk/Ruby/Python. Funny that :-)
Most of the runtime features you talk about being in C# like NULL pointer assignment checking, and runtime checks etc are available in a C++/CLR app. I found it useful for debug builds in the past to turn on the app to use C++/CLR since it gives a lot more warnings. Also in Visual Studio 2005, i found that the compiler has a mode to check for common errors such as accessing a NULL pointer etc.
# posted by 
: 6:44 PM
: 6:44 PM
The main problem I think that we have now in programming is that all the developers think in a very Von-Neuman way of developing code. It's going to take a much more drastic turn to really become efficient multi-threaded programmers with a new language. Just changing a few of the things that he mentioned I don't believe can be enough to increase productivity to the point that we need. He's predicting 20+ cores by 2009. But not everyone will have that many so now we have to create threads that can dynamically scale to these large enviorments safely and efficently. Pretty hard stuff with the languages we have now or the programming styles.
I think you're right though on the points you brought up but doesn't seem like enough yet.
I think you're right though on the points you brought up but doesn't seem like enough yet.
That is why I am coming back to C++ after trying to be free using Delphi. Delphi has incredible easy-to-use components as GLScene but seems that I am in a "jungle of paradigms". As more you believe in magic more dummy you are, tough.
You could look at D which is insanely fast! http://www.digitalmars.com/d/dcompiler.html
It's backwards compatible with C.
It's backwards compatible with C.
Lol. Good luck trying to write a game in Java or (wow) Lua. C++ is currently used for game development because it along with C are the only languages which are efficient enough to deliver the kind of performance a game requires. So keep on plugging away with Eclipse, it's useful for a lot of things but game development isn't one of them.
# posted by : 8:35 AM
: 8:35 AM
ccache (ccache.samba.org) can take a lot of the sting out of "make clean; make"
# posted by : 6:35 AM
: 6:35 AM
I think managed frameworks have spoiled programmers.
Perhaps I haven't worked on a huge game or piece of code, but I believe careful planning can do the trick.
I understand the goal of managed memory and OOP is to cut down on development time.
Maybe I'm just old fashioned.
Java has been pretty successful in the mobile market, probably due to its tight implementation.
I've written a few small game demos for Java MIDP and it wasn't too bad. Memory and speed were the bottleneck of course.
Perhaps I haven't worked on a huge game or piece of code, but I believe careful planning can do the trick.
I understand the goal of managed memory and OOP is to cut down on development time.
Maybe I'm just old fashioned.
Java has been pretty successful in the mobile market, probably due to its tight implementation.
I've written a few small game demos for Java MIDP and it wasn't too bad. Memory and speed were the bottleneck of course.
Hey man,
great blog some really useful information in it, im going to bookmark this blog and check up on it a lot more.
I used to be a software developer myself i know how restrictive it can be too meet and attract women. I run pua classes in london where i teach guys like ourselves how to be able to meet any women and attract her and form any kind of relationship you so wish. This is based on hardcore trial and error and this stuff really works, check out my reviews and the link for more information.
rob
great blog some really useful information in it, im going to bookmark this blog and check up on it a lot more.
I used to be a software developer myself i know how restrictive it can be too meet and attract women. I run pua classes in london where i teach guys like ourselves how to be able to meet any women and attract her and form any kind of relationship you so wish. This is based on hardcore trial and error and this stuff really works, check out my reviews and the link for more information.
rob
# posted by : 2:00 PM
: 2:00 PM
Nice work which is informative at the same time. Would you please provide some Java game programming information to Java Developers?
If you're interested in learning to program, then this site's a great place to start:
www.learn-programming-quickly.com
Post a Comment
www.learn-programming-quickly.com
# posted by : 1:08 PM
: 1:08 PM<< Home
