Name: Anonymous 2011-08-06 5:13
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.
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.