Re: Complexity of new hardware

>
> 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++.

I don't think that's being argued. C/C++ seem the only viable option  
right now. What at least I am interested in is how we can improve upon  
C/C++. Especially in light of the fact that C++ seems to be heading in  
the wrong direction - adding every possible idea under the sun to the  
language, at the cost of making it more and more complex. (And I'm not  
worried about complexities for the programmers - what bothers me is  
complexity that makes development of new tools much harder)


>  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",

Can't speak for others. What I'm saying is that C/C++ introduces a lot  
of unnecessary pain in the development process. (Mostly, long build  
times and insufficient tools). Hence we should be looking how we can  
improve.

I'm not suggesting we write our next game in Haskell. I'm suggesting  
we learn from Haskell and start thinking about what is necessary for  
game development

> 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.

Hence the need to experiment with new languages. We'll never gain  
experience as long as we say "Oh, C++ is perfectly fine, and I'll wait  
till I see some practical experience before I consider anything else".  
Since this is research, and there's not much CS research that directly  
focuses on game development, it means we need to do it ourselves.

> 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 think that's one of the issues with GC - it conflates ownership and  
lifetime. Deterministic finalization can certainly be working  
independently from actual GC. (Which would mean you only worry about  
lifetime, or ownership, when necessary. As opposed to always - the  
default C++ model - or never - the default GC model.

>  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 anything, it's a trade-off. If I can get a game to market months  
faster (with the same quality level), I don't care about inferior  
design. (OK, I'll still complain and moan, but my rational side can  
see the benefits ;)

> 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.

At which point it would be helpful to mention which problems you  
solve ;)

Rachel

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensign option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list