Quake Con

John Carmack says embedded scripting languages with dynamic typing and hand-holding are bad for game development:

http://www.youtube.com/watch?v=4zgYG-_ha28&t=67m35s

Points to take away:

1) People who aren't really programmers shouldn't be able to make changes anyway, it just creates more problems than it solves, so need to cater to them.
2) Embedded language runtimes with GC, reflection, and dynamic typing aren't as scalable as C/C++ and have poor performance on modern cache coherent multi-core hardware.
3) Most existing scripting languages don't have designs that interface well with the fine-grained, high-performance task schedulers on modern multi-threaded game engines.
4) It's more difficult to perform large-scale static analysis on the code base to ensure a specific level of code quality using static analysis tools.
5) Functional languages aren't inherently bad, but it's difficult for large teams to adopt as most programming talent is more familiar with imperative/object-oriented/procedural programming. John Carmack says he's using Haskell and Ocaml in some of his own toy projects, but wouldn't even attempt to force the rest of the developers on an actual team project to adopt such a paradigm.
6) If no existing scripting language/runtime is viable, you have to create your own, but it takes a lot of man hours to build your own scripting language that meets all of your constraints and requirements, it's outside of the scope of most game development projects, so it's often just more productive to move most of your game code too the native low-level language that you're already using.

This is the real reason why many developers are dropping the ability to ship mods, because supporting mods means having a game that performs poorly and can't meet the designers and modelers visions.

>>50
Typical butthurt dynamic-typist response.

You can't unit-test everything. Games aren't all that conducive to unit-testing. Yes, some parts of game engines are testable and game developers do use unit and automated regression testing for those parts.

But, it's currently implausible to unit-test things like 3D real-time graphics or real-time in-game audio, etc., especially across wide ranges of hardware and software configurations. It's not that hard to automate user inputs so it just plays back input events, but analyzing every frame of rendered output to check for validity within a given set of constraints and allowed amount of variation is something that only humans can currently do. You would need human-level or better artificial intelligence to automate the process. And by that point, you would have AI capable of writing software, so you would just ask your personal AI agent to do it for you--that is if humans are still relevant then, which they probably won't be.