Agreed. A lot of the techniques mentioned in the article are effectively impossible on consoles, which makes turnaround times even worse. (disclaimer: I haven't

Agreed. A lot of the techniques mentioned in the article are effectively impossible on consoles, which makes turnaround times even worse. (disclaimer: I haven't worked with all major consoles, so maybe some have decent compiler/debugger pairings) Lisp (or ANY dynamic language) could make a big difference. Some places reportedly have gone down that route. It'd be interesting to gather some data for game completion & schedule slip times and amount of high-level code used. I suspect there to be a strong inverse correlation. However, the attitude I encountered in the games industry (okay, my sample size is relatively small and geographically constrained) is that many people, particularly in the more senior positions are VERY resistant to learning anything new and only do so if they absolutely have to. You'd be surprised how many people still code in plain C even in situations where using some C++ features would save a load of time and even prevent bugs. A lot of build scripts and such were batch (!) files which contained horrendous hacks to get around the lack of proper flow control and scoping, and thus were effectively unmaintainable. We had a Lua interface, but that was mostly used for level-specific functionality, used by level designers, not programmers. Part of the reason for this was that the interface was so half-heartedly implemented - no debugging, no dynamic changes to the code. We had a full-on reflection system in C++, but for some reason there was no Lua interface for it. The other reason was that most programmers just weren't interested. And yes, I did volunteer for improving the situation (as I did in many cases) but that was shot down. Maybe that was just the particularly short-sighted approach taken at the studio I worked at.