> But maybe those projects should have been done in C++ (or ML or something) instead of Lisp in the first place, because the things that Lisp is good at are very much not the things C++ is good at.
Common Lisp was not developed as a scripting language like Python or JavaScript. It was developed for complex applications (100k to 10M lines of code were not rare - for example the PTC CAD system written in C and Lisp had 7 MLOC Lisp code already over a decade ago) and derived from a language with was actually a systems programming language: Lisp Machine Lisp.
Thus there were a bunch of ambitious projects initially written in Lisp and then continued in C++ (and also in C) for better performance on smaller machines, smaller memory footprints and less need to mix C and Lisp.
I know it was, and today Emacs has over a million lines of Lisp even without considering Elpa, but I think Lisp embodied some ideas about the best ways to structure large programs that turned out to be wrong.
In particular, Lisp in general (including Common Lisp) is designed as far as possible to maximize flexibility, and I think there's an unavoidable tradeoff between flexibility and correctness. Oversimplified, programs are flexible when they can do things their original author did not anticipate; they are correct when they cannot do things their original author did not anticipate.
Of course, in reality, it's not that simple. But this obviously false formulation contains important bits of truth. Testing a flexible program is more difficult, and more bugs are likely to slip through your testing, and each one usually takes more effort to diagnose and fix. And of course in general any two virtues trade off against one another in the limit, because if you take every possible measure to increase the first, some of them will happen to decrease the second. (By the same token there are some measures you can take that will increase both.)
Yeah, or sometimes by abusing the fuck out of templates, though that wasn't a possibility yet in the early 01990s. Emacs uses the same approach (adding an embedded dynamic scripting language), and I think PTC CAD does too, and in these cases the "embedded dynamic scripting language" is a Lisp. (AutoCAD, too, but I don't think they wrote significant parts of AutoCAD in AutoLisp.) It's a good approach that avoids paying the cost of flexibility except where you need it.
Since Lisp is often compiled to machine language, C/C++ is often only glue to the OS and large parts of the software is actually written in Lisp. GNU Emacs now has a variant with native compilation, so it there would possible to get rid with much of the C code without much loss of performance. Thus in a large CAD system, compiled Lisp is not just the scripting language, but can be much of the implementation.
Yeah, as I said above, it's not mostly about the performance¹ but about the bugginess, which is to say, the comprehensibility. There are arguments both ways about whether C or Lisp is more bug-prone (less comprehensible) but I think the results are in. And there are new languages like TypeScript which combine and exceed the advantages of both.
______
¹ Though GCC still routinely generates much better code than SBCL, much less the new Elisp compiler, that's not the primary consideration. I'm not sure why you're mentioning it.
Common Lisp was not developed as a scripting language like Python or JavaScript. It was developed for complex applications (100k to 10M lines of code were not rare - for example the PTC CAD system written in C and Lisp had 7 MLOC Lisp code already over a decade ago) and derived from a language with was actually a systems programming language: Lisp Machine Lisp.
Thus there were a bunch of ambitious projects initially written in Lisp and then continued in C++ (and also in C) for better performance on smaller machines, smaller memory footprints and less need to mix C and Lisp.