Re: [Algorithms] Complexity of new hardware

[Mat N. <mat...@bu...>]

> My point is that they don't exist, other sects of development are constantly creating new tools (web development for example) yet no one creates them with game development in mind. Perhaps that's because of the tradition we seem to have, or otherwise in not paying the kind of wages required to bring in a lot of people who are capable of creating those tools, I'm not sure.

LLVM (www.llvm.org) is one approach that is more useful than most. Or Microsoft's Phoenix, if that ever becomes publically available.

Most programming development endeavors try to capture an entire end of the programming spectrum: either from users of a programming language down or a specific virtual platform on up. Unfortunately for game development, the more we can control the entire spectrum the better.

MSN
-----Original Message-----
From: Nicholas "Indy" Ray [mailto:ar...@gm...]
Sent: Thursday, April 16, 2009 3:14 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Complexity of new hardware

On 4/16/09, Jeff Russell <je...@8m...> wrote:
> Working in C++ all the time I feel like the language has become a problem.
> The whole industry seems *really* stuck on it, probably because it has the
> "when in doubt, add a feature" mindset that so many programmers have (and I
> count myself). I'd love to see something a bit more powerful in a language
> that still affords very good performance.

I think the reason the industry is stuck on it is because c++ is the
last real systems programming language. Game Development is a soft
real-time app and performance critical, General GC doesn't seem to be
good enough for Game Development. Our Special case just doesn't come
up in language development otherwise.

On 4/16/09, Gregory Junker <gj...@da...> wrote:
> 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).

For me it's not a matter of admitting, outside of game development,
scheme is my language of choice. It's a pity that Andy had left
Naughty Dog, I think something like GOAL is just the sort of thing
that is needed. Regarding syntax, considering how trivial it is to
parse and rewrite S-expressions it should also be trivial to create
IDE's with all sorts of "views" into the code, as opposed to how the
complexity of parsing C++ requires the "source" to be the only view
into the code. (To be fair, IDEs like Visual studio do provide
additional views, but none of them are editable)

>  They define the difficulties in moving to something different in that
>  Gamasutra article: you can't hire anyone who knows (new language X),

I think this is a matter of hiring skilled professionals who can learn
new languages, they already have to learn so much else at new studios,
I don't figure it to be a large issue.

>  can't find middleware or tools written in it (because we've used the same
>  tools and hardware for the past 30 years).

At least early on, the key is to have *really good* compatibility with
C++ libraries.

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

My point is that they don't exist, other sects of development are
constantly creating new tools (web development for example) yet no one
creates them with game development in mind. Perhaps that's because of
the tradition we seem to have, or otherwise in not paying the kind of
wages required to bring in a lot of people who are capable of creating
those tools, I'm not sure.

Nicholas "Indy" Ray

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list