I haven't seen these message regarding Lisp/GOAL and games by Scott
Shumaker (lead programmer Naughty Dog) mentioned here, so I'll take a
minute to do so. It all sounds delicious (and perhaps a bit familiar)
to Lisp advocates:
>From what I gathered, what GOAL had that I'd like:
>- fast iteration (due to the listener)
Well, fast iteration times weren't merely due to the the listener -
that was a nice touch, but only the tip of the iceberg. We could
basically dynamically link per-function or variable. Effectively,
you could hit a key while working in the IDE, and whatever function
the cursor was on would instantly get compiled, sent across the
network to the TOOL, linked and dropped into the game while it was
running. The whole process took a fraction of a second. You could
also do the same per-file. This feature was sort of like Edit and
Continue, but you didn't have to broken in the debugger - it could
be done while the game was running. This was insanely useful for
programming gameplay, physics, and fx, as well as prototyping,
visual debugging (just drop in some debug spheres or prints while
you have the game in some interesting state), etc. We also used it
for dynamic code streaming - so only a fraction of the executable
code was loaded at any given time (to conserve memory).
It's astonishing at how much this ability changes your coding style
- you gravitate to a much more iterative development process, and
write small bits of code that evolve the codebase while the game is
running. It's obviously also much better for robustness and
reliability, because you're testing out each little piece of code
as it gets added (as opposed to writing a whole mess of code and
trying to get it compiled and debuggged). As for bugs, often you
can fix them while the game is running and test out your changes
instantly - this makes bugfix verification much easier.
http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003798.html
Apparently the ability to easily mix various forms of PS2 assembly code into
your Lisp was also a big win (in a nearby message by the same
author). And to use macros.
Since being acquired by Sony, it seems ironically that Naughty Dog has
had to move to C++, so that their technology could be shared with
others:
In all honesty, the biggest reason we're not using GOAL for
next-gen development is because we're now part of Sony. I can only
imagine Sony's shock when they purchased Naughty Dog a few years
back, hoping to be able to leverage some of our technology across
other Sony studios, and then realized that there was no way anyone
else would be able to use any of our codebase. :)
Sony wants us to be able to share code with other studios, and this
works both ways - both other studios using our code and vice versa.
Add this to the difficulty curve of learning a new language for new
hires, lack of support from external development tools (we had our
own compiler, linker, and debugger, and pretty much had to use
Emacs as our IDE), etc, means that there are clearly a lot of other
factors involved. Note, however, that these issues aren't really
technical problems, they're social ones.
http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003789.html
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
On 2006-01-20, Thomas Lindgren <···········@*****.***> wrote:
> Add this to the difficulty curve of learning a new language for new
> hires, lack of support from external development tools ...
I bet that this conservative attitude towards languages is in part
directly attributable to the crappiness of mainstream languages like
C++; painful without support from external development tools, taking
years to learn well to do serious projects in. In contrast, I don't see
why a bright programmer couldn't learn the basics of GOAL or any other
Lisp in a few days, and the rest would be learning the libraries, which
they'd have to learn no matter what language they were using.