Hacker Language
https://wiki.c2.com/?HackerLanguage
A language that allows one to easily customize syntax, flow control structures, etc. for the convenience of the author without regard to future readers. It allows one to create their own language or sub-language in their mind's own image without worrying about other readers' preferences or grokkability of the style. Contrast with a CorporateLanguage that assumes or targets masses of mediocre PlugCompatibleInterchangeableEngineers (programmers) where there may be many readers with varying skills. Such a language tends to hard-wire ways of things to reduce variation. One can say that a CorporateLanguage is for the herd of sheep while a HackerLanguage is for the lone wolf. ("Hacker" could be "hobbyist" or "tinkerer" also in this context. It's not meant to only include the devious version of "hacker".)
One can often achieve high personal productivity with a HackerLanguage, but readability may fit a very narrow audience or be questionable. Sometimes derogatorily called a WriteOnlyLanguage.
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...