Game Oriented Assembly Lisp
en.wikipedia.org
en.wikipedia.org
From the late 80s through the early 2000s Lisp was my language of choice.
The post author went through many of its advantages -- mostly true. I even
went so far as to write an entire compiler and environment (a
several man-year endeavor) to design two different runtime oriented
dialects called GOOL and GOAL used in 8 Naughty Dog Crash Bandicoot
and Jak & Daxter games. All 30-60 FPS action games -- 40 million copies
sold. All written in Lisp! (more or less)
Eventually, it was Ruby that got me off Lisp. It does most of what made
Lisp great, and the support factor is huge. There are clean standard
libraries for everything, the garbage collector is good (the one in ACL
is was so awful and dated -- I last used it in '07 -- you pretty
much had to turn it off.
I miss the S expressions and the macros. But you can do most macro like
things with a good block expression in Ruby, and you can even do
auto-generated macro like functions with strings. It just isn't
as elegant as Lisp.
The Ruby class system is a bit baroque, but it's actually
better in many ways than CLOS, which suffers from being too dated.
In Ruby you can do a lot of very cool things with extend and include.
It's just a slightly different way of thinking.
The implementation isn't the fastest, but it's good. The Lisp
implementations were all clunky and felt like 80s codebases.
Oh wait, they are.
Support. The rate of change in Ruby is 1000x that of Lisp.
Some new website has an API -- someone writes a Gem immediately.
In Lisp you don't even have a really standard networking library!
I found this interesting. Ruby doesn't have a particularly cutting edge GC afaik, just a standard mark and sweep collector [1]. Why does ACL, which is a commercial lisp and supposedly one of the better CL implementations at least technically[2], have a (relatively) terrible gc?
[1]maybe this changed recently - I don't track Ruby or use it - but Andy is talking of 2007
[2] their licensing terms were terrible last I checked. If you use ACL to build a product you have to give them a chunk of your revenue forever (see the "Value Added Reseller" license at http://www.franz.com/products/licensing/commercial.lhtml#var ) I am surprised anyone signs up for this.
I came to Python not because I thought it was a
better/acceptable/pragmatic Lisp, but because it was better
pseudocode. Several students claimed that they had a hard
time mapping from the pseudocode in my AI textbook to the
Lisp code that Russell and I had online. So I looked for
the language that was most like our pseudocode, and found
that Python was the best match. Then I had to teach myself
enough Python to implement the examples from the textbook.
I found that Python was very nice for certain types of
small problems, and had the libraries I needed to
integrate with lots of other stuff, at Google and
elsewhere on the net.
I think Lisp still has an edge for larger projects and for
applications where the speed of the compiled code is
important. But Python has the edge (with a large number of
students) when the main goal is communication, not
programming per se.
In terms of programming-in-the-large, at Google and
elsewhere, I think that language choice is not as
important as all the other choices: if you have the right
overall architecture, the right team of programmers, the
right development process that allows for rapid
development with continuous improvement, then many
languages will work for you; if you don't have those
things you're in trouble regardless of your language choice.
Then, at ITA, we used Lisp for the QPX airfare pricing system. Both projects used lisp because the early people at both companies came out of the MIT AI Lab: Andy and I at Naughty Dog; Jeremy, Carl, and I at ITA.
The issue with lisp -- especially in light of decent alternatives like Ruby and Python -- is that it's hard to find developers. Yes, you can hire from the higher-than-average-talent set of current lispers. But that's a finite and shrinking set. I think that both Andy and Carl (who wrote the basis of ITA's lisp airfare system) would probably tell the current crop of startup hackers to use a more popular dynamic language. Personally, I'm using Python now, and Peter Norvig's comment about the psuedocode-like nature of Python really resonates with me.
But the main reason the popular dynamic languages are winning now, IMO, is all the code you don't have to write. Look at CPAN, PyPi, and whatever the Ruby equivalent is: there are hundreds of really well-written open source modules to do all the things you need to do on a big project. CPAN was first, but Perl poses so many syntactic challenges that it's hard to use it for a big project.
In terms of productivity, no language design can compete with not have to write code at all. That's the bottom line for me these days.
So, Yahoo acquires Viaweb and rewrites it. The end result
is inferior to the original Lisp-based product. Sony
acquires Naughty Dog and decides to eliminate the
Lisp-based development infrastructure. The end result is
an inferior game development environment. Sure, there
were probably a lot of reasons for these decisions by
Yahoo and Sony (probably none of which had anything to do
with productivity or technical excellence - large
companies have other drivers which have more importance
than these two); however, the end result for both
companies has been something inferior to what they
originally acquired.
Edit: The post has more about in what respect the author considers the replacements inferior.
For example:
http://www.naughtydog.com/docs/Naughty-Dog-GDC08-Adventures-...