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.

>>1
I use java, which has its own virtual machine, so it doesn't need any hardware to support it anyway.

when is Rage going to be released? Im a fan of Bethseda, Im curious what the game will be like

>>42
it will be oblivion with guns.

>>43
it will be oblivion with guns.
which means it will be Fallout 3

>>44
which means it will be crap

>>45
I wont, Carmack will add ambushes were demon-mutants spawn behind, when player takes shotgun shells.

>>46
It wont
self fix

>>47
not fixed, antijew guy

If you want try PVS-Studio static code analysis: http://www.viva64.com/en/pvs-studio/

If you want free license PVS-Studio static code analysis: http://www.viva64.com/en/b/0092/

>>49
Typical of C/C++ retards: instead of writing working code and unit-testing it, retards worship to useless static toys.

>>50
Ch. 9 from PCL

valgrind laughing at all these static tools of >>49. And of  unit tests of >>50 too. Valgrind is fun guy to be around only if kinda slow

>>52
Yo'ure a idiot, valgrind solve's an completely differently problem.

the idea that scripting is for non-programmer game designers is the problem, not the scripting languages.

The real problem is that C++ programmers are fucking retarded at writing scripts. They have no idea what they're doing. I've read a lot of game code in scripting languages that is just C++ with a different syntax -- and that's exactly what they think the game designers like about it. They actually think that designers don't like writing C/C++ because of the syntax, which is just not the case.

The way you're SUPPOSED to reduce bugs in a high level language is by writing LESS code! But C++ programmers don't do that. They write the same amount of code in the same style and then whine and complain that they don't have type safety. Hint: if you write it right and actually learn the language you're using beyond simple syntax, you won't miss type safety. When you can reduce 400 lines of code with 12 different classes to 30 lines of code, it's just a non-issue.

I have met maybe 2 low level programmers who understood lexical closures, for instance. It's like voodoo to them. They also assume anything that they don't understand is "unmaintainable" "unreadable" and "unsafe"

>>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.

>>54
I have met maybe 2 low level programmers who understood lexical closures, for instance. It's like voodoo to them. They also assume anything that they don't understand is "unmaintainable" "unreadable" and "unsafe"
They're just bad. Up until recently my only experience with programming languages was with C and I understood lexical closures in less than a hour simply by reading the Wikipedia article.

>>55
If you have any reference output, you can check against it.

>>1
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 no different from designing an "architecture." Fully half of what is done in C++ and Java is implementing a better language on top of it, usually with syntax made of XML.

it's bad

>>56
Do you realize that lexical closures mean you never have to write something called a "manager"? Do you realize that it means that there are as many layers of "staticness" as you want? Do you realize it allows for a simple way to have private shared resources? Do you realize that it means that you can realistically assert correctness (via obviousness) of complex algorithms utilizing shared information without having to worry about type safety, memory management, or pre-planning bullshit? Do you realize that it gets you much of what traditional object systems get you?

Have you achieved lexical closure satori?

>>55
the parts of games that can't be unit tested also can't be statically asserted. Seriously, show me a physics engine that uses C++'s idiotic type system to assert that all collisions occur as intended.

seriously, fuck off.

arguing for/against C++/Java's retarded type system
arguing for/against static typing

these are not the same.

http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
Looks like dynamic languages work just fine for video games. Sony wins again!

>>59
Do you realize that lexical closures mean you never have to write something called a "manager"?
I don't know what is a ``manager''.
Do you realize that it means that there are as many layers of "staticness" as you want? Do you realize it allows for a simple way to have private shared resources? Do you realize that it means that you can realistically assert correctness (via obviousness) of complex algorithms utilizing shared information without having to worry about type safety, memory management, or pre-planning bullshit? Do you realize that it gets you much of what traditional object systems get you?
Yes.

>>60
I was expecting you to reply with such nonsense.

Guess what? The parts of the game that can't be unit tested CAN be statically analyzed. It's just that static analysis tools only get you so far, it can't check for the same set of constraints that you could were you able to unit-test the code.

This is where dynamic typing just fails.

Static analysis in the absence of unit-testing is better than no static analysis at all.

And before you say it's a worthless endeavor, it does catch common, but non-obvious bugs and hard to diagnose problems that can save many hours and weeks of programmer time. Is that so worthless?

>>64
>
And before you say it's a worthless endeavor, it does catch common, but non-obvious bugs and hard to diagnose problems that can save many hours and weeks of programmer time. Is that so worthless?

Yes. The thing is, as soon as you start writing in a dynamic language, you STOP MAKING THOSE SIMPLE ERRORS. It's like fucking magic. My journey has been C/C++ -> dynamic language -> learn to not make stupid mistakes -> go back to C/C++ -> realize how shitty and useless its type system is.

C++'s type system can't assert anything non-trivial. There do exist nice, turing-equivalent (or near enough) type systems out there that let you formally prove actually interesting things about your code. C++ and Java both fail at this miserably. Anything they can do you can just as easily do in your head just as soon as the crutch is removed.

>>64
It's astonishing at how much this ability changes your coding style - you gravitate to a much more iterative development process, and write small bits of code that evolve the codebase while the game is running.  It's obviously also much better for robustness and reliability, because you're testing out each little piece of code as it gets added (as opposed to writing a whole mess of code and trying to get it compiled and debuggged).  As for bugs, often you can fix them while the game is running and test out your changes instantly - this makes bugfix verification much easier.
http://web.archive.org/web/20060823020559/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003798.html

>>65
For small, single-man projects sure. But on larger projects with multiple developers, and in the absence of a unit-test suite, static typing is better, even if the type system is archaic like with C/C++. At least then the compiler can give you a heads up to a possible common mistake before you hand it off to a tester (who may not have programming experience) who then spends the next 3 hours play testing only to end up hitting a crash-inducing bug that doens't allow the tester to continue due to the wrong variable of a different type being passed to a function. That's 3 hours of wasted time, plus the time wasted discussing the problem between the tester and programmer, plus the time wasted by the programmer trying to track down the bug through millions of lines of code that could have been avoided if only static typing was used.

Plus you've completely ignored the performance problems of dynamic typing that were brought up in previous posts (lol cache misses anyone?)

>>66
That opinion piece drew premature conclusions. It's actually far more difficult to debug large code bases of dynamically typed scripts. It's partly why game development studios are turning away from scripting, as the OP pointed out.

http://www.gamedev.net/blog/883/entry-2249305-scripting-languages-are-overrated/

>>67
They didn't use a scripting language, they used a Lisp dialect for everything. And the games had like 1 million LoC so they were pretty big and it seemed like it worked out fine for them.

>>68
Naughty Dog Studio's Uncharted series, right?

They didn't use a Lisp dialect for everything. If you consult the book "Game Engine Programming" by Naughty Dog's Jason Gregory, you realize they only used their Lisp-like DSL (actually based off of PLT Scheme), which generated C++, code for declaring data types; shader, material, and other graphics resources; and gluing together modules written in C++.

>>69
I'm talking about Jak & Daxter, the PS2 series where they did use Lisp for everything.

In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony.  I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase.
http://web.archive.org/web/20060822182455/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html

Looks like they'd still be using it if they could.

>>70
then realized that there was no way anyone else would be able to use any of our codebase.

There you have it folks, a case study of point #5 from the OP's post.

>>71
You're ignoring the fact that they made 4 games with it (8 if you count the Crash Bandicoot games but those didn't use Lisp for everything). It worked fine for them which goes against your ``dynamic languages suck for game development!'' argument. The fact that Sony wanted them to use C++ like their other studios doesn't invalidate the fact that they used Lisp and that it worked great.

>>71
#5 is an unpoint.

>>67
implying a dynamic language would be not way less code

the single best way to reduce defects is to write less code. High level languages let you do this easily. C++ lets you do this by inventing your own high level language and calling it an "architecture" or "framework."

I can literally get things done in a high level language in a tenth of the code it would take to write it in C++. That's a tenth the bugs, a tenth the tests, and a tenth the maintenance.

As a /prog/ thread grows longer, the probability of an argument involving garbage collection or dynamic typing approaches 1 (100%).
Law of Anus.

Both garbage collection and dynamic typing should be the rule, not the exception. This is coming from someone who absolutely loves assembly and C.

>>76
Garbage collection causes brain damage that people can't recover from. Take someone who has only known developing under a GC and put them in an environment where they have to manage their own memory and suddenly they're no better than amateur 14 year old who hasn't been programming for more than a week.

>>77
the reverse is also true.

>>69
you realize they only used their Lisp-like DSL (actually based off of PLT Scheme), which generated C++

that's basically what Chicken Scheme does, but with C. Your argument is invalid.

The point is not to use a high level language for everything but to not use a low level language for everything.

http://www.youtube.com/watch?v=00Q9-ftiPVQ&t=15m30s
He doesn't like dynamic languages :(