From: Vladimir Sedach
Subject: Re: Python & C++ and Lisp questions
Date: 
Message-ID: <87d5zjljcg.fsf@shawnews.cg.shawcable.net>
Here are my two cheap Canadian cents:

Like everyone else has said by now, don't specialize. It's not that
hard to become proficient in all three of Lisp, Python and C++,
especially in four years. Mastering any one of them will take the rest
of your life, though.

Now, as far as the virtues of the three languages when it comes to
game development, lots can be said, and most of the good stuff points
to Lisp. The nice thing about Lisp is that it can both very dynamic
(Python is roughly in the same class) and it can be very
high-performance (*), and you can decide the trade-off where you want,
when you want. Most games nowadays are written in two layers, one in a
"scripting" language (Python is becoming pretty popular for this) and
the other in C++, all for no better reason than the scripting
languages being too slow and C++ lacking any run-time features
whatsoever. This causes a lot more problems than people realize,
especially because the relationship between the two layers has to be
cemented at the beginning of design time and is almost impossible to
change without breaking everything afterward (which is why a lot of
games get bad press for having crummy scripting languages; one famous
example is Bioware's Neverwinter Nights). With Lisp, you don't have to
make this artificial dichotomy. I also think this would increase
performance a little, since doing the "scripting" parts in Lisp is a
lot faster than doing them in Python or Lua, and there are no
foreign-function data marshaling penalties.

The one place where Common Lisp totally creams the competition is when
it comes to language features and flexibility. Take the save system
for example. One nice thing about Common Lisp is that it is very easy
to serialize data structures (most built-in types come with printing
methods, and there are lots of libraries to print CLOS objects and
other custom things), but even more important is that those data
structures can be serialized to source code. Since you always have a
compiler around, just print the game state to a file, compile it, and
you have a machine code save game file that loads nearly
instantly. With Python you have pickling, but you still have to parse
and interpret the file each time you load. With C++, you have to write
your own serializer and parser for every game! But then you can use
macros and the Meta-Object Protocol of CLOS to go beyond simple
world-dumping to prevalence or an object-oriented database with very
little change. This isn't easy in Python, and it requires major
re-working in C++.

There are other nice features in Lisp that make building and extending
games a lot easier, but I suggest you find that out for yourself
(~). Chances are good that the language you use will largely be
determined by your TAs and/or instructors, so if you want to use Lisp,
get on their good side or just say you're using it as the scripting
language. :)


* CMUCL and SBCL both beat out g++ on the Coyote Gulch benchmark:
http://home.comcast.net/~bc19191/blog/040308.html

~ See Paul Graham's ANSI Common Lisp and David B. Lamkins' Successful
Lisp (available for free on the Internet, soon to be on paper). I
suggest using CMUCL and CL-SDL. They're both straightforward and
high-performance, and SDL works very nicely interactively. If you're
stuck on Windows, Corman Lisp is a good, inexpensive compiler that can
make very small stand-alone executables, and also has SDL bindings.
http://www.psg.com/~dlamkins/sl/cover.html
http://www.cons.org/cmucl/
http://cl-sdl.sourceforge.net/
http://www.cormanlisp.com/index.html
http://www.balooga.com/lisp_sdl.php3