[TUHS] Happy birthday, Niklaus Wirth!

[ggm@algebras.org (George Michaelson)]

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 at gmail.com> wrote:
> On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy <lm at 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 at 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.
>