Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp
I call BS on that one. I have worked on very large scale C++ software (games etc.) and have never seen or needed anything like Common Lisp to get the job done. And I actually know how to program in Common Lisp (and Scheme) and have implemented my own Lisp variations for fun.
That's not the point. It's not half a Common Lisp, but half of (the features) of Common Lisp: code generation/macros, runtime scripting language, loading of code, interactive error handling, a console to interact with the program, dynamic objects, exchanging data in a textual format, a configuration language, etc. etc
Comments
I find this quote especially true in games.
I call BS on that one. I have worked on very large scale C++ software (games etc.) and have never seen or needed anything like Common Lisp to get the job done. And I actually know how to program in Common Lisp (and Scheme) and have implemented my own Lisp variations for fun.
That's not the point. It's not half a Common Lisp, but half of (the features) of Common Lisp: code generation/macros, runtime scripting language, loading of code, interactive error handling, a console to interact with the program, dynamic objects, exchanging data in a textual format, a configuration language, etc. etc
This is also especially true, per Morris' corollary, of Common Lisp.