This analogy is apt for working with LLMs. Were you aware, tho, that it has repeatedly been used to describe Lisp?

I think Lisp is an ideal language to use with an LLM, because it is essentially a notation for a logical assembly code, and I expect there to be compound benefits in using it with AI.

Lisp [...] made me aware that software could be close to executable mathematics.

— ACM Fellow Profile of L. Peter Deutsch.

APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it [...] and it still looks like a ball of mud!

— R1RS (1978) page 29, paraphrasing remarks attributed to Joel Moses.

Part of the beauty of the ball-of-mud quote is that there really does seem to be a causal connection between Lisp's use of generic, unencapsulated, largely un-type-checked data structures and its extensibility. The converse implication is that we should expect specialization, encapsulation, and aggressive type-checking of data structures — all strategies extensively pursued in various combinations in modern language paradigms — each to retard language extension.

Each of these three characteristics of Lisp serves to remove some kind of automated restriction on program form, leaving the programmer more responsible for judging what is appropriate — and thereby shifting things away from close conversation with the machine, enabling (though perhaps not actively encouraging) more human engagement. The downside of this is likely obvious to programming veterans: it leaves things more open to human fallibility. Lisp has a reputation as a language for good programmers. (As a remark attributed to Dino Dai Zovi puts it, "We all know that Lisp is the best language around, but in the hands of most it becomes like that scene in Fantasia when Mickey Mouse gets the wand.")

Lisp, Mud, and Wikis

https://fexpr.blogspot.com/2018/10/lisp-mud-and-wikis.html#s...

{LISP Is a Ball of Mud}

LISP is extensible in two ways. First, there is the simple ability to define new functions; these are used in a way that is both syntactically and semantically identical to built-in primitive functions like CAR. This is in contrast to “algebraic” programming languages, which either make an arbitrary syntactic distinction between addition, say, and a user function, or wander into the quagmire of extensible parsers. Second, there is a uniform macro facility for transforming one syntactic form into another; this facility is based on internal data structures rather than external character-string syntax.

The Revised Report on Scheme

https://research.scheme.org/lambda-papers/lambda-papers-revi...

https://wiki.c2.com/?HackerLanguage

Also:

Lisp is Clay: The Power of Composable DSLs (video)

https://archive.fosdem.org/2026/schedule/event/HDE7JZ-lisp-i...

Code is clay now