bloomberg.com
If GOOG buys them, will they force a rewrite in Python? I'm under the impression that ITA funds a lot of development/creation of tools for Common Lisp, so what impact might that have on the Lisp ecosystem?
A more pressing question is what would happen to QPX, ITA's flight search system. Google's policy of making acquired companies rewrite their software according to Google's standards would, if applied, mean rewriting QPX in C++, Java, or Python. Given how often QPX has been cited as a system that leverages the power of Common Lisp to do complex things, that would be an interesting thing to follow. I bet Google wouldn't do that, though. For an acquisition of this size (the article says $1B), the rules are probably different. (Did they rewrite Youtube?) I must say it would be neat to see Google break their no-Lisp policy.
(As a side note, it's true that if you don't care that much about continuing to evolve a complex Lisp system, it's often possible to rewrite it in a less powerful language; you just end up with a larger and less changeable codebase.)
An even more pressing question: what would happen with QRES? Reservation systems don't seem like a business that Google would want to be in, but it was supposed to ITA's golden ticket. Is selling out at this point basically an admission that this decade's rewrite of all that old mainframe code didn't work either?
(Disclaimer: just my personal opinions, not speaking for anyone else).
Dan Weinreb said there is a lot of interest in it (NOTE, seems to be gone: http://www.youtube.com/watch?v=xquJvmHF3S8), but that everyone wanted someone else to go first, and that was Air Canada, which suspended their participation after the recession started. At that point I can see the leaders of ITA exploring all possibilities to keep the company alive.
I am pretty sure they ported to use their own distributed filesystem at least, I remember reading about it.
Depending on how tight that latter 2 GB is, I wonder if a piecewise replacement with something else that doesn't share the same GC would work well. A wholesale rewrite would be ugly ... I'm not entirely sure it would make sense for Google to do that, and they would send a bad signal if they did, as well as likely provide another proof of Greenspun's Tenth Rule of Programming (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule).
On the other hand, if it's running out of headroom (address space), a 64 bit rewrite might make sense today, in which case all bets are off. The company started in 1996 and the world of CPUs and memory is very different today.
Yes. I could even start to answer to Google head hunters...
I am a Lisper by day-job, and it too is capable of being a royal pain in the ass. Only difference is, instead of bitching about other people's code; in Lisp, I have to write the code then bitch about it :-/
Which is my guess as well: Common Lisp is stuck in standardization amber prior to it dealing with too many things that are critical today (concurrency and network programming being the two biggest ones), Scheme is in a mess due to the mess with R6RS and moves slowly. At least it moves, unlike CL, but it's so slow there isn't even yet a standard for multidimensional arrays; at this point I expect it to continue in its niches of education and language research for a long time.
To do anything useful with common lisp I had to spend a lot of time researching which CL supported which APIs, and stuff like GUIs and SQL weren't standardised (or maybe they were, but finding implementations of the standards was difficult).
Contrast this to my experience with Clojure, where I had a REPL running in a text widget within an hour of starting to play. Sure, most of the code isn't very Lisp-y ATM but then it's mostly direct library calls. As I learn more I expect I will start using macros for things like GUI building (or perhaps someone has already created a more natural clojure library for GUIs and I will use that)
Being able to get started and productive immediately is a big win for Clojure (and other JVM based languages). Even if you don't know much Java, there are abundant tutorials and examples on pretty much any API that are relatively simple to translate from Java to Clojure.
Google's infrastructure is just not up to this level. Customers with multi-year contracts like Alitalia will be none too pleased if QPX's infrastructure and code is mindlessly "Googlized" (well, Alitalia might be a bad example given Google's problems with Italy, maybe they'll say "Nice airline you have here, it would be a shame if anything happened to it." :-).
I can seem them doing the above, spinning off or ending QRES (a problem of bad timing as I've noted elsewhere), and then doing interesting things with various parts of QPX. At the very least ITA has a whole bunch of interesting data feeds ... then again, I wonder what sort of contractual restrictions there might be on them. Still, Google would be miles ahead by buying ITA and only requiring negotiations instead of starting from scratch, i.e. not even knowing what data feeds are out there until they hire domain experts. And then there's capture and formatting and all that stuff, all already done in C++ by ITA.
They could be buying ITA for its domain expertise plus its pile of crackerjack programmers, the ones working on QRES wouldn't be pleased to be moved from Common Lisp but that could beat the alternatives. Tough luck for the QRES Oracle RAC people at all levels, but perhaps there's a good market for their expertise (Microsoft sure had fun there when they screwed up with Danger/Sidekick). And the QRES front end software is in Java (only the middleware is in Common Lisp).
Over the years, subsystems will get converted one-by-one to C++/Python/Java, and programmers will get converted one-by-one to C++/Python/Java programmers. Google would have a lot of good arguments for playing by the rules - they would be able to leverage scalable computing and storage at scales ITA could only imagine, and the rest will fall into place
The backend database of QPX is in C++ and loads half of a 32 bit address space with route data, SBCL CL runs in the other half to figure out the "right thing" which is complicated in more than one way (e.g. a good result is not 100 fares doing roughly the same thing all within a few dollars; see the talk linked in the next paragraph).
The backend of QRES is Oracle RAC, the middleware is stateless and almost almost entirely in Clozure CL, although Dan Weinreb mentioned in his talk (NOTE, seems to be gone: http://www.youtube.com/watch?v=xquJvmHF3S8) that one team was using something else (Java, I think). The front end is in Java with a zillion web libraries.
They aren't Lisp fanatics ... I'm sure enough of them remember where that attitude got Symbolics.
Unlikely, because then they would have to pay a percentage of their revenue to Allegro in perpetuity. (Allegro has an insane revenue model http://www.franz.com/products/licensing/commercial.lhtml)
How can Franz not realize that they're guaranteeing their own obsolescence by stubbornly sticking to that model? The new generation of Lisp hackers cross them off the list immediately because of it. I don't get it. Perhaps they just make enough money the old way and don't care.