It's referring to metaprogramming. Lots of large programs end up full of DSLs and config files with bespoke parsers and code generators, which are largely inferior (in that they are bloated, bespoke and less expressive) to the metaprogramming tools available in Common Lisp.

Reminds me of Ansible. YAML is quite certainly the worst dialect of Lisp I ever encountered...

YAML even has the worst form of macros I've even encountered in the form of go templates.

structs de/serialization(e.g. JSON) and complex initialization/modification routines at runtime that rely on these structs/objects, data-oriented architecture and internal script interpreters at some level. Lisp itself can embedded in C, but at that point the program likely has a more efficient scripting DSL at place.

The contrapositive is enlightening: "Any C or Fortran program that does not contain an ad-hoc, informally-specified bug-ridden, slow implementation of half of Common Lisp is insufficiently complicated."

Works for the famous Arthur C. Clarke quote too: "Any technology that is distinguishable from magic is insufficiently advanced."

Nice!

The rule is referring to application plugins and extensions. In the early 90s, there was an antipattern in lots of large applications to evolve an extension language that was originally just a dialect of a config language of some kind. Then the developers would try to add if/else without changing the syntax of the config language, and then add functions, and before long, you have an overcomplicated yet poorly specified and slow implementation of something almost but not quite entirely unlike Lisp.

This same phenomenon is the reason why John Ousterhout wrote Tcl and the GNU project started Guile.

Think in terms of enterprise apps. Jira, say. But with enterprise stuff, you can't totally insist that the company do it your way. Too many companies have custom steps at points in their workflow. So you need the ability to do some custom process at some points in your enterprise app.

So you needed more than just a configuration file. You needed a configuration file that could contain code. That's what brings you to Lisp - the ability for a data file to contain code that could be imported and executed by a running program.

> This same phenomenon is the reason why John Ousterhout wrote Tcl and the GNU project started Guile.

Except that Guile is an implementation of Scheme, which is essentially a somewhat minimalist variant of Lisp. So in this case, a real programming language was included intentionally as configuration language.

And this is the same concept as why GNU Emacs is an editor written in Lisp on top of C routines - very similar how data science is often done in Python on top of Numpy and several other packages.