Google in talks to buy ITA(theregister.co.uk)
theregister.co.uk
Google in talks to buy ITA
http://www.theregister.co.uk/2010/04/21/google_travel_buy/
8 comments
The ITA tool is pretty awesome from the mileage runner standpoint, although this is kind of a niche market.
I've used it for searches like, "find me trips between point A and point B that involve three segments on the outbound and two on the return, all on American."
When I wasn't trying to come up with some insane routing just for miles/segments, it still was better at coming up with routes/prices than whatever my old company's corporate travel service used. I would never let them book me anything once I found out I could take five minutes, look on ITA, and more often than not find a more convenient route for less money.
I've used it for searches like, "find me trips between point A and point B that involve three segments on the outbound and two on the return, all on American."
When I wasn't trying to come up with some insane routing just for miles/segments, it still was better at coming up with routes/prices than whatever my old company's corporate travel service used. I would never let them book me anything once I found out I could take five minutes, look on ITA, and more often than not find a more convenient route for less money.
How about kayak? Kayak buzz is extremely useful [not to mention a nice iphone app], and works for all pairs of cities while bing travel only has a limited amount of pairs.
Well, I'm not impressed. Try http://www.bravofly.com/vg1/flights.do . I believe it's the best for trips in Europe
Tried my next 2 trips on it, and it's no cheaper than Expedia. Nice slick interface tho'.
By far the most important aspect of this potential deal has been totally overlooked in the articles and comments I've read so far.
ITA powers Kayak & Bing/Farecast and has the direct relationship with the airlines. ITA is foundational to travel search in a way that Kayak or Bing/Farecast is not.
ITA powers Kayak & Bing/Farecast and has the direct relationship with the airlines. ITA is foundational to travel search in a way that Kayak or Bing/Farecast is not.
Excellent point. I wonder if that could create regulatory/antitrust problems for a Google acquisition of ITA?
They pay their engineers REALLY well.
ITA had some pretty interesting open problems for prospective engineering applicants a few years back while I was looking.
The problems were definitely google-esque.
The problems were definitely google-esque.
The Sling Blade Runner puzzle is my favorite. Been hacking on and off on it for the past three years. Every six months or so I come back and spent a few weekends on it. So many different ways to approach the problem. Genetic algorithms, graph simplification, splitting, and pruning algorithms, graph key node analysis, all sorts of different traveling salesman approaches, not to mention creating super small/fast brute force, there is always something new to try against it. Even generated various images of the graph with dot just for kicks. If anyone is looking for a problem to try this would be one I recommend to try. Going by number of movies you should have no problem getting more then 200 in length and with something better (or luck) over 300. Have something really good and you can get above 320 :)
Just got over 9000 with a snippet in Perl, using regular expressions.
You might want to check your code. Since each title can be used at most once in the solution and there are 6589 movies, it would seem that there are at most 3294 possible solutions, no?
There isn't even 9000 movies. Sounds like you are looping and counting the same set of movies over and over.
This is a brilliant idea from Google's perspective. The travel industry is very very profitable, and a lot of the travel shopping process is basically the hunt for information - tell me where I can stay, how much, give me options, etc. This is a problem Google could really optimize.
How do you figure that? Airlines are losing money like it's going out of fashion.
Well how I see it, the Airlines are losing money. Not the travel search sites. They still take their cut no matter what the margins look like for the underlying airlines. And it is a lot of revenue, even if not a lot of profit(I doubt that, but don't have relavent experience/documentation to back that up). And at the very least the travel search itself brings a LOT of eyeballs, which google has interest in.
On an unrelated note, ATI's co-founder Dave Baggett was on the founding team for the original "Crash Bandicoot"...which is awesome.
On an unrelated note, ATI's co-founder Dave Baggett was on the founding team for the original "Crash Bandicoot"...which is awesome.
Some do, some don't: there wouldn't be any airlines in business if it wasn't extremely profitable. All that post 9/11 "we're going out of business!%!%#@!!" madness was mostly a TARP-style bail out quest.
The reason you see so many commercials on TV for travel-related sites such as Expedia, Hotels.com, Priceline, etc., is because the margins and volumes are so large.
The reason you see so many commercials on TV for travel-related sites such as Expedia, Hotels.com, Priceline, etc., is because the margins and volumes are so large.
If Google bought them, would they force ITA to rewrite their C++ / Lisp engine in Java?
I hope not and I doubt that would happen. One of ITA's biggest assets is their employees. Those employees are there in large part because they get to use lisp on the job.
Also ITA deals with incredibly complex problems and has very complex software, rewriting it in other languages would be a serious undertaking.
Also ITA deals with incredibly complex problems and has very complex software, rewriting it in other languages would be a serious undertaking.
While I'm not sure I buy the GP/GGP (can't see from the post window >_<) point that Google NEEDS a Lisp/CL team, I have a hard time imagining they would buy ITA for such a large sum of money only to piss off all the employees, and at the same time basically throwing away the tech if they wanted to rewrite it away from CL. The money is simply too much for doing that to make sense.
Unless they feel ITA's market position alone is worth that much cash, but I find that hard to believe.
edit: Bah wasn't in the same exact thread line but was mentioned, excuse the dumb on the grandparent/Great Grand Parent part.
Unless they feel ITA's market position alone is worth that much cash, but I find that hard to believe.
edit: Bah wasn't in the same exact thread line but was mentioned, excuse the dumb on the grandparent/Great Grand Parent part.
Why would they do that? Half of Google uses C++.
But not Lisp.
Google is using Scheme for most of the code on their "App Inventor for Android" program, which is supposed to be a modern-day successor to Hypercard: a way for interested amateurs to easily make basic mobile phone apps.
Then again, not every Google project has Hal Abelson on the team. That might have something to do with it.
http://googleresearch.blogspot.com/2009/07/app-inventor-for-...
Then again, not every Google project has Hal Abelson on the team. That might have something to do with it.
http://googleresearch.blogspot.com/2009/07/app-inventor-for-...
Given that Google does rewrite the code of many companies that they buy, it wouldn't be surprising if they did rewrite the ITA code.
As others pointed out, there's already an existing code base. It's large, it works (solves hard problems) and it's scalable. There's also non-trivial C++ and Lisp integration, replacing Lisp FFI with Java JNI in some of these cases might not even work _at all_. ITA also does use Java, so Java integration is already there, to plug into Google's front/middle tier.
I imagine data persistence and distributed workloads are handled by the C++ portion of ITA code, which means plugging into GFS, BigTable, Chubby and more wouldn't be that difficult. ITA had already done the hard job of working around Common Lisp's missing pieces (a standard on concurrency and systems/network programming), something which would have been a huge distraction to e.g., Google in 2001 (when Ron Garrett attempted to evangelize Lisp).
Lastly, ITA isn't dependent on an acquisition by Google in the same way a start-up with no revenue (being acquired for talent and/or audience) would be. They're being bought partly for talent, but also they're being bought for actual technology and a working, profitable business. That gives them a lot more leverage in setting the terms of the acquisition (has e.g., Postini undergone a full re-write?). These issues is what "technical due diligence" is supposed to work out and resolve: would an integration necessarily mean driving the employees away? If this is so and such integration would have to occur, then the merger may simply not happen.
Even in the case of a pure talent acquisition care has to be taken to avoid an exodus. Money isn't going to the deciding factor here: I'd imagine ITA employees are less bound by golden handcuffs; they're not staring at life changing sums of money and (like most hackers) are more motivated by doing interesting work with smart peers and powerful tools, than by what is effectively a equivalent to a yearly bonus (I am assuming they're likely looking at $100,000-$200,000 in shares vesting over a four year period).
I imagine data persistence and distributed workloads are handled by the C++ portion of ITA code, which means plugging into GFS, BigTable, Chubby and more wouldn't be that difficult. ITA had already done the hard job of working around Common Lisp's missing pieces (a standard on concurrency and systems/network programming), something which would have been a huge distraction to e.g., Google in 2001 (when Ron Garrett attempted to evangelize Lisp).
Lastly, ITA isn't dependent on an acquisition by Google in the same way a start-up with no revenue (being acquired for talent and/or audience) would be. They're being bought partly for talent, but also they're being bought for actual technology and a working, profitable business. That gives them a lot more leverage in setting the terms of the acquisition (has e.g., Postini undergone a full re-write?). These issues is what "technical due diligence" is supposed to work out and resolve: would an integration necessarily mean driving the employees away? If this is so and such integration would have to occur, then the merger may simply not happen.
Even in the case of a pure talent acquisition care has to be taken to avoid an exodus. Money isn't going to the deciding factor here: I'd imagine ITA employees are less bound by golden handcuffs; they're not staring at life changing sums of money and (like most hackers) are more motivated by doing interesting work with smart peers and powerful tools, than by what is effectively a equivalent to a yearly bonus (I am assuming they're likely looking at $100,000-$200,000 in shares vesting over a four year period).
Unlikely. ITA's codebase is probably really, really, really huge by now, and I get the impression that they consider their use of Lisp to be important to their success.
I think Lisp would be one reason TO buy them. Google needs a Lisp team and I imagine they realise this.
Can you expand on why you believe Google needs a Lisp team? I am having trouble coming up with any convincing argument for needing one.
Because it's a language in which you can be incredibly productive. The only downside is speed of execution, but optimisations help.
Why I think Google needs one? Because they don't have one, and considering their financial resources, they can afford it, and because ITA will pay for itself.
Why I think Google needs one? Because they don't have one, and considering their financial resources, they can afford it, and because ITA will pay for itself.
I think they probably have a couple people that know Lisp... Peter Norvig probably knows some :)
1 billion dollars for a developer team who uses certain language? Wouldn't it be cheaper just to hire the team?
Airline flight scheduling and pricing is harder than lisp.
Do you think they'll also spend top dollar to "buy teams" that are good at other languages? Kind of a ridiculous concept - surely if the gains of Lisp were actual, Google would just pay their employees to learn and use Lisp.
(also answer to pavs) Well, when Google acquired ReMail, everyone here said "It's a talent acquisition". So why should this be any different - $1b for the world's best Lisp hackers?
Talent acquisitions are usually in the millions, not the billions. If you're paying a billion dollars, you want to get more than talent out of the deal. There are probably cheaper ways for Google to get excellent Lispers.
Not at all http://www.flownet.com/gat/jpl-lisp.html
The conversation went something like this:
Me: I'd like to talk to you about something...
Him: Let me guess - you want to use Smalltalk.
Me: Er, no...
Him: Lisp?
Me: Right.
Him: No way.
And that was the end of Lisp at Google.Sounds a bit like how Smalltalk was banished from Viaweb:
http://xach.livejournal.com/146281.html
http://xach.livejournal.com/146281.html
I believe "him" was Urs Holzle, who built runtimes for Self, Samlltalk and Java (which was later bought by Sun). Urs knows way more about these languages than Gat. His "no way" should be enough for anyone.
OK, but Ron Garrett's no lightweight either: http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a2...
...with Lars Bak.
this doesn't make a ton of sense. A (majority?) good share of ITA's profits are from sales to other traffic search sites and directly to airlines. Google's never had a strength in selling to other enterprises and surely doesn't want to manage yet another enterprise software sales team. I find it unlikely this purchase would go through given they'd be paying for the enterprise software portion when they only want the consumer engine portion.
I partly agree, Google's operations just aren't of high enough quality in terms of uptime for the QPX market. It's one thing to be shut out of Gmail for a half hour, quite another to not be able to book tickets for any long period of time.
This acquisition only makes sense if the QPX operations parts of ITA stay separate from Google; in general, Google would have to avoid "Googlizing" operations and probably the working code base as well.
QRES, though, isn't as far as we know isn't in good shape WRT to its potential market due to the Great Recession and now the Iceland volcano and its one customer (Air Canada) suspended its formal involvement in it (now's just not a good time to make a switch). I wouldn't be surprised if that got spun off or more likely canceled. I'm assuming ITA's leaders are shopping around the company or at least entertaining offers due to it's poor prospects for the foreseeable future, it's a very good idea with very bad timing.
This acquisition only makes sense if the QPX operations parts of ITA stay separate from Google; in general, Google would have to avoid "Googlizing" operations and probably the working code base as well.
QRES, though, isn't as far as we know isn't in good shape WRT to its potential market due to the Great Recession and now the Iceland volcano and its one customer (Air Canada) suspended its formal involvement in it (now's just not a good time to make a switch). I wouldn't be surprised if that got spun off or more likely canceled. I'm assuming ITA's leaders are shopping around the company or at least entertaining offers due to it's poor prospects for the foreseeable future, it's a very good idea with very bad timing.
So could it be that google doesn't have enough boffins, being from the west coast? From the article: founded in the mid-90s by boffins from Massachusetts Institute of Technology
Does the codebase matters more than the ideabase?
The one place where Google is getting spanked by Bing is in travel search. Bing travel is IMHO hands down the best fare search engine out there, and I travel a lot. http://matrix.itasoftware.com site comes in second place for me, even though it looks like crap.
It has some insanely useful tools for a mileage runner such as myself. For instance, ITA has a domain specific language that you can use to search for fares. What I use it all the time for, is to find the cheapest fare between two cities on a single airline over the course of the next month.