But will an LLM write dense Common Lisp? A lot of that density comes from well-designed domain-specific macros. An LLM will have no incentive to write these on its own, though it could if a human prods it sufficiently.
They don't write dense Python. I'll tell you that. The individual functions might look good, but there's just so much repeated or nearly repeated code.
Yea, this seems to be a consistent issue. The models don’t know when to think strategically and often make local edits that keep growing individual functions with more and more conditional logic.
The only issue have faced with generating Lisp/scheme code, especially on small models, is that it always misses some closing parenthesis. However, because the small core language, you can use structured output in the LLMs that support it and it works quite well.
I found that explicit instructions to keep nesting depth below a limit helps limit the damage. That limit was 5 in my case, which can be inconveniently tight in some situations.
In the Clojure world, there is a small utility that is pretty popular called clj_paren_repair (part of clojure-mcp-light: https://github.com/bhauman/clojure-mcp-light/blob/main/src/c...) that uses parinfer’s indentation algorithm to help repair out of whack Lisp parens (and brackets and braces for Clojure). It’s easy to expose this as a skill or tool. I had Pi create me a tool in 60 seconds. I have to say that before I discovered it, I had no time for parinfer (paredit all the way, baby), but this really does the trick as often the model gets the indentation correct (from being trained on so much Python??).
Yes, human direction will still be required for the foreseeable future (whatever that means in this fast-paced field) to recognize where introducing a DSL or a macro makes sense.
