> That was not written in C++, that was around the time I discovered Common Lisp, which was about 8 years into that 15 years. And there was no way the consumer of this would use Common Lisp, so I wrote a Common Lisp program that wrote all the yield management algorithms again out as SQL stored procedures and gave them this database, which was a program.

> Eventually I got back to scheduling and again wrote a new kind of scheduling system in Common Lisp, which again they did not want to run in production. And then I rewrote it in C++. Now at this point I was an expert C++ user and really loved C++, for some value of love

> [Audience laughter]

> that involves no satisfaction at all.

> [Audience laughter]

> But as we'll see later I love the puzzle of C++. So I had to rewrite it in C++ and it took, you know, four times as long to rewrite it as it took to write it in the first place, it yielded five times as much code and it was no faster. And that's when I knew I was doing it wrong.

Seems like a pretty good argument for Common Lisp here.

> So, when I discovered Common Lisp, having used C++, I said that, "I'm pretty sure to the answer to this question is, 'yeah, absolutely'". And can we do that with a lower cognitive load? I also think, "yes, absolutely". And then the question is, "can I make a Lisp I can use instead of Java or C#?". Cuz you just heard my story, and I used Common Lisp a (?) couple of times, every time it got kicked out of production, or just ruled out of production, really not kicked out, it didn't get a chance. So I knew I had to target a runtime that people would accept.

Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/), which runs on the JVM.

> And the old Perlis, you know, quip about, you know, "any sufficiently large C or C++ program, you know, has a poorly implemented Common Lisp", is so true.

That's actually Philip Greenspun: https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

I (unsurprisingly) don't think his list of problems with Lisp are convincing. I don't mind mutable state, since the real world is not functional: real programs are all about side effects. I don't mind that not everything is a list: as he notes, lists aren't the perfect data structure. I think the package system is very clean & understandable.