4 ms·
> 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
by zeveb 9y ago
> 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/ 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 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.
- Sinidir 9y ago>Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/ http://abcl.org/), which runs on the JVM. First public release of ABCL seems to be after first release of clojure.
- zeveb 9y agoWas it? Ward's Wiki indicates someone was using it in 2004: http://wiki.c2.com/?ArmedBearCommonLisp http://wiki.c2.com/?ArmedBearCommonLisp (as an aside: why is JavaScript required now?), while Clojure dates back to 2007.
- endgame 9y ago> (as an aside: why is JavaScript required now?) Because it was "improved" (rebuilt) recently.
- joe-user 9y ago> Pity he hadn't heard of Armed Bear Common Lisp (http://abcl.org/ http://abcl.org/), which runs on the JVM. He was certainly aware of SBCL. He had a number of reasons for not wanting to use it. [1] > I don't mind mutable state, since the real world is not functional: I hear this argument often, but the "real world" is not linked lists or hash maps or mutable or 0s and 1s either, but they are all useful representations. > real programs are all about side effects Clojure has plenty of facilities for side effects, and without having to resort to monads (though you could if you wanted). [1]: https://www.youtube.com/watch?v=cPNkH-7PRTk https://www.youtube.com/watch?v=cPNkH-7PRTk