Brian Mastenbrook: So, um.

There was this fancy snazzy Web 2.0! application which was written in Common Lisp, by a bunch of guys who also knew Python. They ran into trouble making Common Lisp work for them. They went back to Python. Who's surprised?

Honestly the only thing which bothers me about the whole kerfluffle is that "Such-and-so couldn't make Common Lisp work for them, subject to the constraints that they (a) needed threads, (b) needed to use the same implementation for development and deployment, (c) were deploying on FreeBSD, (d) were developing on OS X, and (e) wouldn't pay for a license of Allegro Common Lisp" somehow turned into a statement about Lisp in general. Even given every one of those constraints, I'd still be using an implementation of Lisp to work in. And if I couldn't use any of those I still wouldn't be working in Python, Perl, or Ruby. There are other languages that I could choose without giving up my stock of accumulated experience in Lisp programming.

So, for those who seek a lesson in all of this: there are plenty of Common Lisps around which focus on performance. Which is the Common Lisp for someone who is happy with the performance of Python, but wants to use the same implementation, with the same features, on several platforms, and also wants features like threads? I can't in all honesty recommend CLISP, not least because there's no good way to develop a web application inside SLIME (lacking serve-event and threads, your web listener will block the REPL). CLISP also isn't usable by a good number of people as an extension language, because only programs distributed under GPL-compatible licenses can link to it.

I'm not sure I have much use for this anyway. But it might have been interesting to those folks working on that Web 2.0 program. Myself, I've got some exciting code to work on.