
2011: Current And Future Programming Languages For Videogames - hanifvirani
http://c0de517e.blogspot.com/2011/04/2011-current-and-future-programming.html
======
megaman821
The more I see of Rust the more I like it. Sometimes C is just too low level
and C++ has gotten unwieldy. C++'s stranglehold on systems programming needs
to end.

------
davidsiems
I've actually done a fair amount of thinking (and even a little
implementation) on this topic so I'll share my thoughts.

I've come to the conclusion that my ideal 'game programming' language would
actually be 3 different languages that are tightly coupled. It would consist
of the following:

\- A low level language, similar to c/c++/d

\- A scripting language that is tightly coupled with the low level language.

\- A scripting preprocessor that's run as a preprocessor for the low level
language (effectively replacing templates and the C preprocessor)

Low Level Language:

Games need to be fast, that's why they're written in C or C++. At the end of
the day, when you're trying to squeeze those extra cycles out of your console,
you need to be able to have precise control over how your data structures are
arranged in memory, how things get copied around, what data is preloaded into
the cache, etc.

It's okay for this language to be garbage collected, but the programmer needs
to have full control over the garbage collector, ideally the garbage collector
is of a variety that doesn't require stop-the-world collection. You'd probably
also want manual memory management to be an option.

Scripting Language:

In game development, having a low-cost for iteration is also extremely
important. If it takes your game designers 20 minutes to tweak something
simple, the end product is likely not going to be very good. This is where
scripting languages come in, you load all your resources (textures, models,
etc) and then you iterate on the game logic without having to load everything
from scratch. Loading can actually eat a very large portion of your
development time if you don't have hot-reload or your game logic doesn't exist
in script.

By tightly integrated I mean make the two languages intimately aware of each
other's details. They each need to know how the other is storing data, it
needs to be _simple_ (as in just a keyword simple) to call into and out of one
from the other. This way the way they communicate can be fast, and a lot of
the process can be automated by the compiler so you don't have to do it by
hand.

A cool thing here would be having the ability to compile the scripting
language to assembly or the low level language when it's time to lock things
down for ship.

Scripting Preprocessor:

Embedding scripting languages into lower level languages can be a bit of a
pain. In C++, you have a code generator do it, you use templates, or you do it
by hand.

Templates are way too complicated for what they accomplish (code gen), the
preprocessor is usually used in the same way (code gen). If you're not using
these two methods to generate code you've probably written a code generator in
an external scripting language that's parsing your C/C++ (yuck) and spitting
out C/C++.

What we need is a preprocessor that is actually a scripting language in its
own right. The scripting preprocessor gets run before the low level compiler,
and just spits out code in the low level language. You have to jump through
hoops to 'loop' or 'if' with templates, it's about time we gave ourselves a
fully featured language to do our meta-programming in.

~~~
swaits
I've had my eye on D for a few years. But, I never manage to work it into the
grand plan. For scripting, I have a slimmer of hope for Rite, from Matz (of
Ruby).

Strangely, IMO, I find most of my fellow gamedevs are not PLgeeks.

~~~
copper
In the off-chance that you've not seen this talk by Tim Sweeney:
<http://lambda-the-ultimate.org/node/1277>

~~~
swaits
Yep, have definitely seen it. Thanks!

------
iwjames
Although I've just started learning it, Haskell seems to be a worthy language
for games (even has PPC support?). Even as a low-level "scripting" language of
sorts, using FFI...although I'm not sure how easy it is to bind with C++ at
the moment.

------
xsmasher
I was surprised to see CLI listed as the current champ for games instead of
c++. Is it really widely used on other consoles, or for non-windows games?

Is Unity and XNA enough to crown CLI as king?

~~~
hammerdr
Even more odd is that he crowns the CLI as king over Java because it "does not
have any technological advantage over [CLI]." The he turns around and lists
Mono as a C# advantage over the JVM.

I have zero love for the Java programming language but the JVM is the platform
at this point. Everything from Java, to Clojure, to Ruby run on the JVM. You
also get the wealth of the Java libraries (though, admittedly, are
enterprise-y). There is also the culture around these two platforms that makes
me scared of the CLI as a 'best of breed' platform.

------
scythe
Vala could be a contender on the "system languages" list -- it's runtime is
just GLib, which has already been ported to all sorts of platforms and
optimized quite well, and Vala is quite a nice language in and of itself.

<http://live.gnome.org/Vala>

Also, I don't think he gives the game-oriented scripting languages quite
enough credit. They're not as mature as Lua, but almost all of them seem like
more likely competitors with Lua than Stackless Python or Io, much less Tcl or
Javascript (all of which except V8 are _slower_ than Lua, and when Lua's
performance is already an issue that's not encouraging) -- most of the game-
oriented languages solve one of the biggest Lua gripes quite handily, which is
that Lua's exclusive use of floating-point arithmetic makes it a pain (okay
this is hearsay) on ARM-based platforms without floating point units (which is
most of them). The good news is that LuaJIT now has a port to powerpc along
with the mainstream i386 and amd64 ports, and to my knowledge an arm port of
the interpreter is in the works as well.

------
mkramlich
I'm thinking about mailing a dead fish to Microsoft HQ for every time I see
the term CLI used on a web page and it's the .NET thing and not the should-
have-been-well-known--to-them-already abbreviation for _command line
interface._ And don't get me started on the names .NET or C# either (sharp?
really? when serious programmers/sysadmins already would have expected hash or
pound? really?!).

Other than that, good article. Nice little survey and perspective.

~~~
contextfree
Pretty silly to expect exclusivity on three-letter acronyms. There are only so
many of them to go around.

(If "serious programmers/sysadmins" are such dull people as to be taken aback
by cultural references to anything outside their jobs, so much the worse for
them!)

