Because the calling overhead is too fucking slow. Never mind what happens if the library allocates memory and you're expected to free it in another module. This is bad practice, but it happens.

If the library uses weird pointer tricks like "since every data item is 4-byte aligned, we can use the low two bits of the pointer for flags", you'l break the garbage collector. Again, not great practice, but it happens.

I love dynamic languages. Every so often I try to write a game in Lisp, but productivity is about Language + Runtime. You can only justify fixing broken GL wrappers for so long, before you realize you've wasted time that you didn't have to waste.

My current fav mix is C++ without aggressively using all the bells and whistles, so it's easy to wrap for dyn languages, and Python.

I think that best thing to do is look at 1) the libraries you'll be using, 2) what your team is proficient at, 3) what's worked for other groups, 4) optimization potential.

If you think that Ruby/Lisp is your answer to the above points, go for it. But I have the feeling that it won't be for many people.

I didn't say I wanted to use Ruby or Lisp--I was simply denying the parent's point that one would have to "write the graphics libraries from scratch."

Besides, isn't the advice for optimizing every other kind of project:

1. Start in a high-level language

2. Port any bits that profile as slow to a low-level language, and then interface them into your HLL code

Why, all of the sudden, when you're coding a game, is it a better idea to start in the low-level language? Because your team "knows it?" by that argument, all games would still be being developed in assembler, because the most senior members of the team would have more experience with that than any new-fangled language like C++.

That advice never works. The problem is data structures. If your high-level prototype uses complex data structures of e.g. Python, you will not be able to access them from C++. You will need to rewrite the whole thing anyway.

The only way you might get away with this approach is if your application is essentially a number of separate scripts that communicate through files. Then you can rewrite the key scripts in C++. But that is never the case for games.

While rather similar to Python, Lua has a simple stack-based C API that makes this far less of a problem. OTOH, Lua was designed for embedded use from the start, and its stand-alone interpreter comes second.

Part of Civ IV (mostly gui stuff) is in python. They seem to be able to communicate with the C++ core fine.

But I assume they did not write the game in Python and the optimize parts in C++. Quite the opposite - they wrote it in C++ and then found that some part (e.g. GUI) is growing in complexity while not being crucial for performance, at which point it is a good decision to use a scripting language for it.

That is a pretty common approach, but what was suggested above (writing first in HLL and then rewriting parts in C++) is, to my knowledge, never done in practice.

Wait, according to http://news.ycombinator.com/item?id=888748:

"There is not a simple set of “hotspots” to optimize!" and also "Will gladly sacrifice 10% of our performance for 10% higher productivity [...] We never use assembly language."

Last time I heard, assembly wasn't considered out of bounds for high performance game programming by any means.

Last you heard must have been a while ago. Even the engines aren't being written in assembly. Writing in x86 yields slower and less optimized code than letting gcc -o3 etc compile your C code in x86. It simply gets too complex to manage in assembly.

offtopic: gcc -Os is probably even faster than -O3.

That's not true in the case of C – just reported in the case of Ruby. And only in some cases.

Now, although C++ is a perfectly fine "HLL" language, I'll grant you that other languages are easier to program in. But patchwork programming can be bad advice some of or maybe most of the time.

Besides the issues of programming in a language different from what your libraries were written in (and more importantly, designed for), there are serious issues with the patchwork-performance code philosophy. The biggest is that the "routines" that you need to make fast often operate on data. You'll have a container of some sort in your "slow" language, and you'll want to do something with that container in the "fast" language. Do you expose the container's memory to the fast language (hard!)? Do you copy (slow!)? Do you use the more efficient containers in your fast language and expose them to the slow language (insane!)? When exposing complex objects between languages, you'll have similar considerations to make.

You can't look at C++/Python or C++/Ruby programming and assume that you'll simply have to make the same sort of engineering considerations as you would for C/Assembly. It's an entirely different kettle of worms.

Assembly is concerned with telling a computer directly how to handle memory addresses. C, for all intents and purposes, is just a simple abstraction for doing that. On the other hand, higher level languages present a lot of abstractions for doing a lot of things. And mixing those abstractions leads to serious complexity.

There's a role for lisp (and prolog) in gaming, but not on the outside.

As an embedded core to sort out a bunch of logic they definitely have their place.