I tried to hire an engineer in the 1990s. She came to the interview
with her (probably over-controlling) father who was the founder of the
two person consulting company she'd been working for. They coded a
huge traffic-light management system entirely in LISP. Major stuff.
From memory, we offered but I think daddy didn't
like the way we
behaved, she didn't accept. I think she was an incredibly good
programmer. Really smart, competent. It was my first clue that out in
the "real world" (I was working in a university) you could code in
LISP and sell solutions that ran things like traffic lights: People
die if you get that wrong. Awesome. (it's equally likely we didn't
offer, being stupid)
On Fri, Feb 16, 2018 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote:
On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy
<lm(a)mcvoy.com> wrote:
On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote:
On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart
<stewart(a)serissa.com>
wrote:
ITA???s airline flight booking system, that was
used by Orbitz and
others
was pretty much entirely written in Common LISP, and it was certainly
both
large and commercially successful. Orbitz was bought by Google for
$700
million. I don???t know how much of the LISP survived sustained
attention by
Google.
Google bought ITA, not Orbitz. Most of the logic in QPX is still in
Common
Lisp, but it's not what you'd call "idiomatic" CL code. If one reads
a
bunch of Paul Graham and Peter Norvig books and then gets onto QPX with
the
expectation of that sort of elegance, you end up pretty unhappy pretty
quick. They do a lot of things very differently to squeeze as much
performance as they can out of what has, historically speaking, been a
fairly mediocre compiler.
Which is sort of my point. I don't know all the details but lisp and
performance is not a thing.
That's a tad unfair.
It *can* be fast, it's just that the "Lisp" you're writing in that
case
probably isn't the Lisp you wanted to be writing when you read about how
cool and elegant Lisp was: you're avoiding some constructs to prevent boxing
and unboxing arguments (e.g., put things inside of labels or flet's instead
of defun's or passing arbitrary lambdas around) or generating useless
garbage (don't cons up a list; setq the cdr) and favoring others that are
less elegant to get better object code out of the compiler.
If you can stomach the death-defying twists and turns from all the hoops you
have to jump through for all of that nonsense, then you can make it fast --
but at the loss of the expressive advantage. But that trade-off begs the
question: why not write in a language that lets you write fast (executing)
code without jumping through hoops? That's a fair thing to ask and most of
the answers in Lisp's favor aren't particularly great.
- Dan C.