What the adherents generally get right though is that for some things and some games handcrafted C or assembly is necessary. The existence of this is used to claim that certain games are "not possible" in higher level languages. I agree with this claim in general, with some objections. I think a Lisp programmer can create as-performant or more-performant code than a C programmer with less dollar cost for an employer. I also remind all that languages suitable for game programming are Turing-complete, and what one can do so can another, but this is ignoring other constraints such as economics. If it takes you a decade to write or run a program in one language, but only a month for a second language, the program in the first language is by most intents "not possible" even if it exists.
What I want to flip around on the adherents is that there are some things and some games that are "not possible" in C or C++.
Run-time level inspection and interactivity are very powerful features and the way C and C++ programmers ignore them is depressing. Strong data guarantees the likes of which Haskell and ML and several lisps (like Clojure) allow for certain optimizations the compiler can make that a human programmer wouldn't even think of making and which are incapable of being made by a C or C++ compiler due to lack of guarantees. There's a reason FORTRAN is still being used in number-crunching applications: programs written in it provide guarantees the compiler can exploit for superior performance than a clever C program would get.
Syntax expressiveness is another very powerful thing which Lisp dominates at, and it goes along with ease of programming, ease of modifying, and ease of debugging. All of these contribute to economic constraints of a game and by extension the goodness of a game. Suppose we have two companies. The first delivers a 120fps (capped to the refresh rate of monitors, 60fps) game in 12 months with Z features and Y employees. The second delivers a 60fps game in 6 months with the same Z features but Y/2 employees. The first used C/C++, the second used little-optimized Lisp. (They could get to 120fps if they wanted to, but why?) Suppose the second company spends an extra 3 months on the game, now they might have more than Z (desirable) features, more polish, smoother gameplay, less bugs, and now in addition to being sooner-to-market they're also getting superior reviews.
There are even more. I'll close with the fact there are general or abstract language features in higher level languages (like Lisp macros, laziness (which you can fake in C with Duff's Device), continuations...) that to duplicate in C/C++ would (for some of the ones mentioned) require writing a compiler of a higher-level syntax. These features allow the expression of ideas that are "not possible" in C/C++. They allow the expression of algorithms that are the same. There are places in computer science that are "not possible" to visit in C/C++ due to all the constraints of the real world, and games that make use of these places have the potential for incredible benefits.
Crash Bandicoot was written in a lisp. Well, the gameplay was, the graphics were done in assembly. (And 2, and 3, each released in one-year time frames.) Could they have done it without Lisp? Maybe. In Jak & Daxter (read one of the comments), it was entirely Lisp, with Lisp outputting assembly instructions. The JPL did the same thing for early Mars rovers.
Posted on 2012-08-29 by Jach