Re: [Algorithms] Complexity of new hardware

[Gregory J. <gj...@da...>]

> We need improvement in the languages we use, compilers, and
> IDE/Editors; It's absurd that I am using tools/languages that have
> been only incrementally improved in the last 10 or so years, and have
> evolved naught with considerations from the problems we face in game
> development.

NaughtyDog tried -- you have to admit that Lisp *in theory* should be
perfectly suited to game development: it's core design intent is list
processing (indeed, it's the name), which arguably games *are*, and it's
functional, which ought to be perfect for increasingly data-parallel game
technology designs. If the syntax is just "too weird" -- that can be
changed, while leaving the core language design intact (again, GOAL). 

http://www.gamasutra.com/features/20020710/white_02.htm

Of course, for the past ten years we've been developing for (until recently)
single-threaded Von Neumann architectures, so I'm not surprised the tools
haven't changed -- they still target the same basic hardware. Until we break
away from that processing model you're not likely to see many changes in the
tools we use. Larrabee (driven largely by GPU design) is a step in that
direction, but it's still (by business necessity) rooted in the x86 legacy
that has been around for over 30 years now.

They define the difficulties in moving to something different in that
Gamasutra article: you can't hire anyone who knows (new language X), you
can't find middleware or tools written in it (because we've used the same
tools and hardware for the past 30 years). Even using common higher-level
languages such as Python, C#, Ruby, etc., those are still based on the same
processing paradigm we use in C++...so why change when the tools, arguably
(unless you are developing for the Wii), are actually fairly usable, and the
middleware and libraries are so readily available?

Short answer: we use C++ and its tools because it is still the best
compromise, using multiple criteria, among all of the possible solutions.
Granted, C++0x may change that, but luckily it's still a draft...

I would ask -- to which game-development-specific problems do you refer?

Greg