If most of the code does GC is down to the programmer. Like I said, it's trivial to ensure that each class you create has a factory method basically executing 'return new (GC) Whatever()'.
If GC is inherently incompatible with C++ then someone wants to tell the C++ standards board before they add one for 2009.
Debugging is almost non-existent if you follow a test first methodology, same in all languages. Can't remember the last time I had any difficulty with debugging whether it is Python or C. It can't completely eliminate the debugger but it does eliminate 99% of it. Also a nice side effect is that your code ends up lightly coupled.
I agree with the fact that 80% of the game will be 20% of the code. That's why I suggested the game engine be written in C++. The rest of the game will be a huge selection of scripts and data that apply on top of the engine.
Out of interest, what do you suggest as a more productive language? Usually I find productivity is effected far more by things other than which language you are using, a good programmer will do more in ASM than an average one will in Lisp. First class functions and the other functional stuff does not generally see a lot of use in games programming. Fiddly pointer arithmetic is far more useful in this domain than things like closures and lambda's. Performance dominates.
Last edited by G_Morgan; 10-25-2007 at 03:09 PM.
|