Recently,
Joe wrote in his blog:
As I see it there are three kinds of languages in this world:
- Hard to write, but blazingly fast: C and C++, or even assembly if you’re really hard-core
- Easy to write, but so slow that you have to use them sparingly: PHP, Lua, Python, Perl
- Flash
Java fits into an awkward niche between 1 and 2. It’s easier to develop in than C++, but not enough to keep up with the scripting languages, and yet it’s far too slow to write the whole game in. Add to that the incredible pain of forcing your users to install the Java VM, and you get a non-starter of a language.
This seems to be the common perception of high level languages lately – languages like
Python* are considered “scripting” languages: they’re not compiled like Java or C#, and they have a “simpler” syntax. I’ll use Python for terms of discussion because of my familiarity with it, but I’m sure the same is true for languages like
Perl and
Ruby.
Implementation
All too often, on the
GameDev forums, I read people’s posts claiming that an interpreted language could never be as fast as a language that compiled to a native binary format like C#. So that we’re all on the same page, let’s get this out of the way at the beginning: “managed code”, “language runtime”, and “virtual machine” are all concepts on par with “interpreted language.” Sure, the first three imply a level of “smartness” by the interpreter – compilation of the language into some interpretable bytecode, and perhaps a JIT compiler – but any modern interpreted language should be doing these things. We’ve come a long way from the days of parsing text and executing it.
The fact that Java and C# need a compilation phase is merely an interpretation difference. I like being able to change code on the fly and have the interpreter recompile it into bytecode for me. Other people like having the extra type-safety and syntax checking pass of a compile step. Personally, though, I think these class of bugs get much less frequent with a language like Python.
Runtime Speeds
The
Computer Language Shootout does consistently list Java and C# (albeit, on
Mono) as faster than Python. In Python’s defense, the benchmarks never have
Psyco – the Python JIT compiler – enabled. Running a few of these tests myself using Psyco, I saw a speedup of at least 4x running with the most basic braindead use of Psyco. This still puts Python slightly behind Java and C# for speed, but not by much. Of course, many of these tasks are heavily numeric – something I would hope you’d implement in C and wrap for use in Python if speed were a concern.
Development Speeds
I find myself able to develop applications much faster in Python than in C++, due to the nature of the syntax. (As I over-excitedly told Joe over lunch one day, “orders of magnitude faster!!”) I’ve heard many other developers tell me that it’s impossible to manage anything more than a large project in a high-level language, or that once it comes down to writing production quality code the speed gain is lost.
I’ll step away from the “Python as an example of high-level languages” here for a moment, and talk about Python specifically. A lot of claims against Python’s ability to deal with large projects comes from its dynamic typing. I think a lot of misconceptions come from this – it’s important not to confuse dynamic typing with weak typing. Python is a dynamically- and strongly-typed: references (variables are all references) can point to any type, but data keeps its type and will not be automatically cast to fit the current expression.**
As far as development speeds on production-quality code and suitability for large projects, I’ve found both of these statements to be completely untrue in practice. At a previous job, I worked on large python applications. In several cases, we decided to re-write some of the server-side code in C++ to gain some speed. (Audio processing and mixing on a server processing audio for many clients in any number of audio conferences, for example.) These pieces would take several times longer to write than the original Python modules.
I think a lot of the misconception about production-quality code being slower comes from people who have experiences with Java or C#. In these C-like languages, developers still need to jump through a lot of the syntactic hoops that C++ developers do, but still have the cost of needing a language runtime. The difference from C++ ends up being that you can use a few neat language tricks to hack together code quickly, that’s not “production quality.”
Development Environments
One place Python and other high-level languages fall down compared to Java and C# are in the development tools. Developers who are used to Visual Studio like that you can seamlessly step from C++ to C# code in the debugger. Java users have Eclipse. (Yes, Python users have Eclipse too, through the
PyDev plugin, which is quite nice.) There is no well-integrated tool for Python debugging across language boundaries. On Linux, you could set up GDB to recognize Python code, but that’s a huge hassle – and Linux specific.
I don’t think the types of errors you need a strong debugger for come up quite as much in a high-level language. Pointers don’t suddenly go NULL. You can’t mysteriously clobber your vtable. But that’s not to say that a debugger isn’t an invaluable tool.
WinPDB is a great tool, but especially in game development, there
are going to be times when you need to step into the C++ source for a module you wrote.
Conclusion
As Joe mentions in his article, I think most developers are stuck in their own little bubbles. I certainly have been surprised lately to find out that Java has become much faster and can now be used for non-ugly GUI applications with SWT. Hopefully, I’ve encouraged you to at least look in the direction of high-level languages if you never have. Every tool has its uses, and I think you’ll find that high-level languages are better for a lot more than text processing these days. And C or C++ probably isn’t the best choice for everything that it used to be. But if you’re still writing that text-processing tool in C, you might need to expand your bubble.
* Yes, I’m biased towards Python, I know. I love Python. Whenever anyone in the office mentions anything about languages other than C++, all heads turn to me, expecting my Pytho-vangelism. But there is a reason I love Python; there are several, in fact. I’ll go into them in a later post to keep this footnote short.
** I say ‘usually’ because Python is about as strongly-typed as C when it comes to primitive types. Different numeric formats will usually be automatically casted to the appropriate type for an expression. The expression “x = 5.5 + 10” is valid, “x = 5 + ‘32’” is not.
