Hacker News Reader

Comment by Oxryly | Hacker News Reader

Waits for the inevitable "we're switching from Lisp to Python" announcement...

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.

@smanek is a Lisper and worked for ITA a few years ago I believe so perhaps he'll chime in.

smanek is way too busy with postabon to chime in, but I can tell you that half of #lisp on Freenode is idling from *.itasoftware.com

I think that the useful parts (QPX) are still Lisp. IIRC python is more for integration and (their limited) front end.

Not so. Most of QPX and RES is Lisp.

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.

Wikipedia on Blub: http://en.wikipedia.org/wiki/Paul_Graham_%28computer_program...

The interesting question here is what's getting people to try Python but not a Lisp. Perhaps Clojure will help answer that question.

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.

See http://danweinreb.org/blog/the-failure-of-lisp-a-reply-to-br...

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.

> The software that ITA developers that makes them different from the rest

Classic paper by Carl de Marcken, co-founder and former CTO of ITA Software, elaborating the unique domain problems of air travel planning:

"Computational Complexity of Air Travel Planning"

http://www.demarcken.org/carl/papers/ITA-software-travel-com...

"The critical infrastructure pieces (where GC is an issue) are already in C++."

When did this happen? From what I heard last, C++ was just the data importer that dumped everything into mmapped buffers which SBCL worked on.

Data importers, pieces that deal directly with RAC, sound like critical infrastructure where GC is an issue.

I didn't mean critical computation, query and logic components. Perhaps "infrastructure" was too vague.

A tip I picked up from one of pg's essays for finding out what technology a company uses: look at their job listings; they don't lie.

In the "Operations" part of the company it appears you're right, "most work is in Python": http://www.itasoftware.com/careers/jlisting.html?uid=718167

In "Engineering", Lisp tops the "particularly valuable" list at the bottom of "Knowledge and Skills" for http://www.itasoftware.com/careers/jlisting.html?uid=730130

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"

we should add ruby to that.

We really shouldn't.

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.

More likely to be a combination of Python, C and/or Java. ITA uses a lot of C and Java as well.

that mix would fit well at Google

Reply on news.ycombinator.com