From mboxrd@z Thu Jan 1 00:00:00 1970 From: ggm@algebras.org (George Michaelson) Date: Fri, 16 Feb 2018 12:56:59 +1000 Subject: [TUHS] Happy birthday, Niklaus Wirth! In-Reply-To: References: <20180216011815.GD8295@mcvoy.com> <20180216024108.GG8295@mcvoy.com> Message-ID: 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 wrote: > On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy 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 >> > 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. >