Presumably a DSL would allow you to do more heavy lifting in your specific domain with less tokens.
Let's way you wanted to do a web application using LLMs. Using a web framework would cost less tokens than using the vanilla underlying language (Python, PHP, whatever..), which is again way less tokens than building up from assembly (an LLM should be able to do this given enough time and compute).
I hadn't thought of that! Writing a program in fewer tokens* has been Lisp's advantage all along. If, because of token economics, the same advantage accrued at the LLM level, I dare say certain people would be pleased (as would I):
I came to the same conclusion over the last year. The Lisp family, especially used with a CL REPL, present a lot of inherent advantages for agentic coding.
Ironically, this comment of mine from a few days ago touches on a lot of the points from this article and was flagged to death:
But writing good DSLs requires one to be great at going up the ladder of abstraction. Not that LLMs can't do it, but they stuggle and choose the path of least resistance. That's easier even if it results in more code.
Readability for yourself. I find the biggest issue with lots of LLM assisted development is that the agent harness can generate code faster than I can read it. I'm the bottleneck.
There's a "zen" moment felt by folks who've written lots of macros (experienced in Lisps and Forths) where, when designed properly, you really feel like you've "grown" a language and have really walked up the abstraction ladder. My thesis is that macro heavy code when the author designs the macros well are very readable. That an agent's output when stacked upon macros can be a lot simpler to read and understand than in languages where the syntax is less fungible. And if you leave a project for a while and come back, an agent is a perfect tool to help you read your macros and familiarize yourself with the abstraction surface again.
I think what they're saying is that in CL you create DSLs that are tailored for the domain and that will result in lower token use. Not sure about that claim, would like to see some data to backup that assertion. Wouldn't you then need to supply the LLM with a "programming manual" for this new DSL? Wouldn't that cost tokens?
sure, but input tokens are way cheaper than output.
There is also a phenomenon I've named "brevity collapse." Often, when shrinking a codebase, you find you need less glue. Additionally, because it is smaller, you can hold more of it in your head and see more opportunities for shrinkage. Surprising things happen when the bones of your language get more efficient---it's more like going from elephant to flea than elephant to grizzly bear. The smaller scale means there's less "overhead" code, which means you can go smaller still.
> I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done
Pithiness. A human might need to be able to read and understand the code. If the code is much longer than it could have been, it will take much longer to read and understand it.
Smalltalk, in image based systems, absolutely. Erlang not as much, it's more of a "crash the actor and try again" than "rewind, pause, and handle errors in-system"
I dont really understand what macros get you when llms exist since a llm doesnt really need to create dsls to get work done