I'm James Hague, a recovering programmer who has been designing video games since the 1980s. This is Why You Spent All that Time Learning to Program and The Pure Tech Side is the Dark Side are good places to start.
Where are the comments?
Timidity Does Not Convince
The only arguments that hold water, in terms of programming language suitability, are bold, finished projects. Not a mini-Emacs written in Haskell. Not a Sudoku solver in Prolog. Not a rewrite of some 1970s video game using Functional Reactive Programming. They need to be large and daring projects, where the finished product is impressive in its own right, and then when you discover it was written in language X, there's a wave of disbelief and then a new reverence for a toolset you had previously dismissed.
And now, two of my favorite bold projects:
Wings started as an attempt to clone Nendo, a 3D modeller designed around simplicity and ease of use. Nendo development and support had dried-up, and enthusiasm for Nendo fueled Wings 3D development. So now there's a full-featured, mature 3D modeller, with a great focus on usability, and it's written entirely in Erlang. Without a doubt it's the antithesis of what Erlang was designed for, with the entire program running as a single process and intensive use of floating point math. But it clearly works, and shows that there are benefits to using Erlang even outside of its niche of concurrency-oriented programming.
SunDog: Frozen Legacy
SunDog was an elaborate game for the Apple II. A 1MHz 6502 and 48K of memory look more like a platform for simple arcade games, not the space trading and exploration extravaganza that was SunDog. And though assembly language was the norm for circa-1984 commercial games, the authors--Bruce Webster and Wayne Holder--chose to implement the majority of the game in p-code interpreted Pascal. I found a justification in an old email from Bruce:
Wayne and I had some long discussions about what to use to write SunDog (which actually started out being another game). We considered assembly, FORTH, and Pascal; BASIC was far too slow and clumsy for what we wanted to do. We ended up ruling out FORTH for issues of maintenance (ours and lack of a commercial vendor).
I pushed for--and we decided on--Apple Pascal for a few different reasons, including the language itself; the compactness of the p-code; and the automatic (but configurable) memory management of the p-System, which could swap "units" (read: modules) in and out. Pascal made the large project easier, not harder, though it was a struggle to keep the game within 48KB.
And that's how it should be: choose the language that lets you implement your vision.