> Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Sure, because C and Fortran are extremely limited languages - no first-class functions, no sum types, pitiful error handling. In a world where language design was extremely-primitive, user-defined macros made sense. Once languages that offered standard ways of doing the constructs that most programs need were invented (i.e. ML in 1973), there were better alternatives.
> The Lisp eval function is easier to read, understand, and modify than to start over and rewrite it from scratch.
That's not actually true though. The definition in the link uses a bunch of obscure lisp-specific terminology and doesn't really gain anything from doing so. It genuinely is easier to reimplement it from scratch (perhaps with the help of a more neutral reference) than to understand the Lisp version.
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
What are these amazing 'commercial' programs?
And why are they so large? And, do they need to be so large?
Does the entire team understand all the inner workings of the commercial program?
The Lisp eval function is easier to read, understand, and modify than to start over and rewrite it from scratch.
( As for those brackets, well ... https://xkcd.com/859/ https://xkcd.com/541/ https://xkcd.com/297/