Re: [Algorithms] Complexity of new hardware

[Gribb, G. <gg...@ra...>]

>As I mentioned, C++ was not designed for making games, it's very
suitable systems language, and for many systems in game development, I
do find it enjoyable, however it starts to break down while combining
systems into a large application, and additionally leads to a lot of
repeated and glue code, which is often ad-hoc and bug-ridden. That
combined with the very poor toolset makes it less then ideal to write
entire games in.


Seem like the death of C/C++ has been proclaimed for at least 20 years. As game developers, for say at least the last 12 years or so, we have done lots of work with scripting languages of all sorts. Outside of the game proper, we use all tools available including really high level stuff like commercial databases. So it isn't like game developer are just oblivious to language technology.
 
But if we are talking about big-budget commercial games, and we are talking about the runtime code, the stuff that actually executes on the 360 or PS3, then the death of C++ is greatly exadgerated. Game developers find sucess with C/C++.
 
The proposed benefits of highler level languages strike me as nieve and theoretical. In practice those benefits don't materialize, in my experience anyway. It isn't clear to me if those lobbying for change are saying "we had a really tough time with C++ on our last game, so we are going to try something different next time", or "we switched to language X for our development last game and saw real benefits".  It would be nice to hear more about practical experience, rather than dubious theory.
 
Let me just pick on one thing today: Garbage collection. Having made big-budget commercial games both with and without garbage collection, in my experience, these are myths:
 
Myth: C++ does not "support" garbage collection.
Myth: Garbage collection saves development time. 
Myth: Garbage collection reduces bugs.
 
To me, "ownership and lifetime" is an important concept in software engineering.  When is something created, when is it destroyed and what higher level object is accountable for it? Garbage collection offers ONE answer to the question of ownership and lifetime: Everyone referencing something share ownership and the lifetime lasts until it can't be referred to anymore.
 
I feel that having only one answer to the ownership and lifetime question is very limiting on expressive power. In many cases, a different approach to ownership and lifetime will give you a superior design. We sure don't want to live with inferior designs because the language has a dogmatic and limiting view of ownership and lifetime.
 
As far as development time and bugs, well in my experience a garbage collection system just gives you different sorts of bugs. With garbage collection, you will spend your debugging time trying to understand what link in super complex dependency chain is problematic, and even when it is identified you are left with only hacky approaches to breaking the undesirable links. Realize that with a console game, an object that does not get destroyed soon enough is just as fatal as an object that gets destroyed too soon, except the former is much harder to track down and fix.
 
In the end using garbage collection isn't a huge problem; I'm satisfied with the products I've made that use GC. But I will say that whoever thinks garbage collection offer significant benefits to game development doesn't seem to be facing or solving the same problems that I confront.
 
-Gil