Slashdot Mirror

← Back to Stories (view on slashdot.org)

Common Lisp: Inside Sabre

Posted by chrisd on from the little-inventive-scheme-programmers dept.

bugbear writes "I just got permission from the author (Carl de Marcken of ITA Software) to publish this email, which describes the inner workings of Sabre, the flight search software that the airlines and travel agencies use. It is a case study in cheap Linux/Intel, NT/Intel and Hpux boxes replacing mainframes, and also the use of lisp and other languages in a server-based app. Update: 01/16 13:45 GMT by H :RawDigits writes "Common Lisp: Inside Sabre - correction. The Lisp engine is used by Orbitz, and not Sabre. Sabre still maintains mainframe systems for their booking. I should know, I am sitting in the Orbitz NOC right now ;)"

7 of 227 comments (clear)

  1. Lisp without GC! by nagora · · Score: 2, Insightful
    How very odd... I'd have liked a bit more on why they used Lisp since one reason many give is normally the garbage collection which isn't being used here. Why is GC too slow in Lisp when there are years of experience behind it?

    TWW

    --
    "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
    1. Re:Lisp without GC! by jonis · · Score: 2, Insightful

      > A garbage collector has to scan all the data in memory to decide which bits are needed and which bits are garbage.

      This is actually not right. GC does not have to (as opposed to _can_) scan everything. Some (e.g. copying) GCs scan only the objects that are referenced (live objects). And in generational GCs the set of objects scanned is usually a fraction of live objects (recently created ones).

  2. And I thought I'd never... by Andorion · · Score: 2, Insightful

    I just finished CS161 (Artificial Intelligence) at UCLA last quarter.... nice to see some applications for the stuff they teach us here, as most of it seems like garbage. -Berj

  3. Good lessons by f00zbll · · Score: 3, Insightful
    The post had some valuable lessons:

    1. use the right tool. As the post stated, they chose to use C when LISP would incure a performance hit. Loading all the data into memory statically makes a lot of sense, considering how many searches it has to support.
    2. advanced topics like algorithms are good tools for solving challenging problems
    3. try to maximize your knowledge of the system. This is probably one of the hardest, since most projects are under "I want it yesterday" schedules. When it was necessary, they looked at how LISP compiles the code and weighed the benefit of optimization or using C. Realistically, most projects don't have the time for this step, but it is still worth while to attempt it.

    Reguardless of the language, I found the post insightful and informative. All of the techniques and decisions described in the post can be applied to most projects. Sure, most websites don't need to support the massive number of searches like Sabre, but programmers can apply those principles. Keeping a balanced foot isn't easy and there's always politics added to the brew, but with perseverance, programming can be something that provides a great service and tremendous personal pride.

  4. Re:LISP, language for "perfect code" by CrazyLegs · · Score: 3, Insightful

    You make an interesting point, but the 'obscure languages' angle cannot work in a typical corporate IT environment. In this world you need to deal with legions of meatball programmers peppered with a few alpha-geeks to set direction. The realities here are:

    • software change is constant
    • organizational change is constant
    • code development is a business process

    The only way to deal with all this is to ensure that a hive mentality is enforced where coding standards and methodology are King. This ensures that, from a purely technical perspective, all code looks (somewhat) familiar to all programmers and new programmers can be put to good use in fairly short order.

    Sounds boring (and maybe evil) - sure. But this has been my experience and observations at more than a few large development sites.

    --

    CrazyLegs

    "Pork!!" said the Fish, and we all laughed.

  5. Re:This problem isn't as hard as they make it soun by cracauer · · Score: 2, Insightful

    You are abolutely right, it's easy.

    Unfortunately you're just talking flights and not fares. [Hint: if you think you pay a price for a flight you board like you do in a Bus, you're wrong].

  6. Language chauvinism by epepke · · Score: 4, Insightful

    The vast majority of language preferences reduce to religion, and of those the vast majority are dilettantes who know a dozen languages or fewer.

    In reality, LISP isn't slow, and it really never was, compared to the alternatives. About 20 years ago, some deluded souls converted some heavily numerical FORTRAN code to LISP and found out it ran about 20% faster on LISP. I call them deluded because they were under the false impression that any of the detractors of LISP would care. They don't.

    People prefer languages primarily for cultural reasons. LISP fits certain cultures and doesn't fit others. You can say the same about FORTRAN, C++, Java, Visual Basic, or any other language you like. Pseudo-quantitative arguments come later as justifications to be used in arguments.

    Beyond that, different languages are good for different things, but it's almost impossible to have a discussion about it. If we were to have such a discussion, I would say that LISP is a great choice for anything involving graph theory, which a reservation system obviously does.

    Me, I'm in the middle of writing a game engine and editor that's built in C and C++, does the plotting in an embedded Scheme, uses a Postscript-like code for run-time, interfaced with the Scheme, and under OSX uses Objective C for the user interface layer. So, what do I know anyway?