I've heard that the Python folks already drove most of the Lisp folks out. Lisp is only used for a very small part of their infrastructure, from what I've been told.
Farther down the same page they ask you to solve puzzles. "Puzzles submitted in C++, Lisp, Python, Java or Perl will be reviewed most promptly, because those are the languages we use every day"
If you (or someone else) wouldn't mind taking the time to explain it, I'd really like to know why your unsupported and vaguely anti-Ruby statement is so popular. I'm assuming that it means that the problems with Ruby are so widely known that you don't even need to spell them out in order for people to agree with you, but I guess I didn't get the memo. Why "really shouldn't" we? (Serious question - thanks.)
One thing, of all the dynamic languages the default Ruby implementation is by far the slowest. For anything that is slighty computational expensive, the default Ruby implementation is poor. Also think green, if you have lots of computation in a slow language, that easily adds up in a large data center in form of wasted electricity, which adds to cooling and is generally expensive. Some Ruby implementations try to get in the direction of, say, a Lisp implementation like SBCL - which is used by ITA. SBCL provides since quite some time a compiler that can generate reasonably fast code.
In Dan Weinreb's "Lisp for High-Performance Transaction Processing" talk he mentioned that SBCL was being used for QPX because of the quality of its compiled code (as I recall they started out with CMU CL so this was a natural choice).
For REs, Clozure CL was being used in part because faster compile times were more important and run time preformance was more than adequate; stateless business middleware is a very different beast than compute intensive route construction, where we can be sure the cutoff in optimizing choices is based on response time.
There were other reasons for Clozure CL, including the fact that it has a company behind it, one who's principles Dan and others have had long relationships with and ITA was buying one (man?)day a week of their services to support RES. SBCL is (has always been?) a volunteer effort.
Unlikely that they will go away from lisp. They are heavy users of SBCL (performance) and CCL (fast compile) and have some interesting fraction of a million lines of lisp code and might just be one of the larger employers of lisp programmers.
It also isn't a "location based application that lets you casually hookup with your friends" that used to be acquired in droves 2005-2008. This is a serious and existing, profitable business with a serious and scalable technology platform and experienced talent. Not just ambitious and smart college kids getting a slightly higher hiring bonus (not that there's anything wrong with that).
The critical infrastructure pieces (where GC is an issue) are already in C++. The front-end is already in Java. A full scale re-write will be a dumb thing to do. It's not going to be difficult to have Common Lisp FFI to hook the ITA middleware into Google's infrastructure instead of ITA's.
The software that ITA developers that makes them different from the rest (I am guessing lots of these are heuristic solutions to NP complete problems) is exactly the sweet spot for Common Lisp, where it provides a significant advantage over other languages even for large groups of programmers. While I will enjoy writing a web app in Common Lisp much more so than writing a web app in Java (less boiler plate, interesting language compensates for a mundane task) I doubt there are going to be great advantages to doing the more routine development in CL for a large corporation.
As I understand it, C++ to maintain the QPX in-memory database and SBCL to do the routing magic (which is even more non-trivial than you might think, e.g. a "best" result set is not 20 routes that are all within a dollar and that hit the same airports, etc. etc.).
RES uses Clozure CL (formerly OpenMCL, an evolution of Macintosh Common Lisp) for the stateless middleware with Oracle RAC for the backend and Java with the usual libraries for the web front end.
I'm a current ITAer working on QPX -- by lines of code, QPX is probably actually split pretty evenly between C++ and Lisp. But accounting for verbosity of C++, the logic is heavily on the Lisp side. I think anyone on my team would consider himself to be a Lisp developer before anything else.
It's so good to hear this. I'm always afraid that Python is going to squeeze out Lisp. It's a total absurdity, but people seem happy to learn Python and that puts a huge pressure on keeping Lisp shops alive.
"It's a total absurdity, but people seem happy to learn Python and that puts a huge pressure on keeping Lisp shops alive."
I think that it's less about learning, because Python is way more similar to languages like Java or C++. Using Python, they have to learn less. Than they discover some cool new features in Python and are bought. Then they don't see any need to bother further with lisp.
