I was recently made aware of the Intel C++ STM Compiler. They're doing some fairly interesting work...but the sample code is really unbelievably hideous and offensive. As a research project it's great, but I can't see it actually catching on, not in that form. The point of STM was to make coding easier.

The Next Big Language -- What About Cross-Compilers?

When it comes to the matter of what will be the next big language in game development, there's one really nasty issue that continues to pop up. Any new language simply doesn't have the platform support it needs. It can't have the platform support it needs, as a simple result of being a new language which nobody is yet interested in. Once in a while you find someone dumb enough to think that adding support to GCC magically solves the platform support issue (hello D supporters), but it doesn't. We do need to be able to code for consoles, after all. That's why we're locked to C++ for probably close to another decade at the least. Sony, MS, Nintendo, and their supporting vendors aren't going to come up with new compiler suites overnight just to satisfy a few developers here or there.

The important observation is that the landscape was not really all that different for C++. You could create a new language and write a compiler for a platform, but the massive platform forking meant a new language simply could not make it big. The reason C++ managed to survive was because it didn't originate with its own compiler; it was simply cross compiled into C code. Thus once you had the C++ cross compiler (called Cfront) ported over, it was a simple matter of running your C++ through it and then invoking the platform's C compiler on the result. All the benefits of the work on C compilation and optimization was retained, but with a much more capable language on top. C's a particularly nice choice due to the sheer simplicity of the language; it isn't really much more than a portable assembly language with some extra syntactic sugar thrown in.

One option, then, is to design a new language that can be cross compiled to C++ or plain C. That way, platform support is guaranteed, optimization and all, for quite a lot of years to come. Mixing old code with new can be made fairly straightforward, and interop with middleware like Havok is not a problem either. It's even conceivable that, just like C provides asm { } blocks, the new language could provide native { } blocks that would contain C code. (This would be similar to C# unsafe, most likely.) This type of language compilation is not unheard of; there are plenty of research languages (Dyna comes to mind) that operate like this.

Of course, there are problems with this approach. Take C++, for example. Cfront no longer actually works, because the language is too complex to cross-compile that way. The language needs to be something that can be re-expressed in C without turning into such a total mess that the compiler isn't able to handle it properly and generate efficient code. There's also the question of scripting. How is this any different? The compilation/execution model changes from what a scripting engine would use -- but that's actually a step backwards. The game code would now be divided into three levels -- low level native code, mid level implementation code, and high level scripting code. Defining a clear separation in what goes where will be problematic, and mixing across layers is inevitable, along with all the problems that result from that sort of mixing.

I have no idea if a cross compiled third language is what we need in the mix. The sheer thought of having to design such a language makes me feel kind of sick. We can all see how well it worked out with C++, after all. Sure the original goals were met and the language took off, but we paid a price for that evolution in the form of all sorts of legacy cruft. It's just interesting to loop at options that are less extreme than completely walking away from the structure and toolchains that have been at the core of game development for years. A cross compiled language may not be the most comfortable option for ease of use, but I tend to think that it's better to move to that than to attempt to move to C#, fail, and end up stuck in C++.