Nick said:
I meant faster as in executing I guess.
Look up "premature optimization is the root of all evil".
When you pick a language that's repulsively hard to program, just because a
newsgroup said it's faster in general, that's an example why premature
optimization is the root of all evil. You will program slower, hence you
will have less time in your schedule to profile and determine the real slow
spots. Programmers should write clear code (in a clear language) and never
try to guess what will be slow. It's easier to make clear code fast than
make fast code clear.
If you see I just posted a
question relating to a 2D MMORPG game / maker. I'd like the game to be
fast and not necessarily faster coding wise. Thanks for the feedback.
Games have two layers. The lower layer, the graphics rendering engine,
should be written in a C language, and it should directly access hardware.
The upper layer should be in a soft language, for scripting the game events.
You probably want to write the upper layer and reuse one of the existing
lower layers, such as SDL (IIRC) or OpenGL. So use Ruby for the upper layer,
because it makes scripting tasks very easy. Much of Ruby development
consists of building and using "Domain Specific Languages" that are easy to
read and write. Your top layer could be as clear as "orc.attack(hobbit)".
Because only one line of upper layer code needs to run for every ten
thousand lines of lower layer code, the performance of the upper layer is
less important. If you have any further constraints, such as a small
footprint, or a very big upper layer, you could split the difference and use
Lua. It's harder to program than Ruby but much easier than Java, and its
speed can compete with C.