How a new DSL may survive in the era of LLMs

I don't think we need to worry about the survival of DSLs. DSLs + LLMs are a powerful combo. I've hit limits with building MCP tools for LLMs using low-level interfaces, and I overcame it by making small, quickly teachable DSLs that the LLM can interface with better.

For example, working with MIDI-based music at a low level was a struggle to get musical results from an LLM, so I switched to a custom notation for representing MIDI data [1]. Then, doing interesting operations on MIDI wasn't working well so I designed a "language" for transforming MIDI data [2]. To get the LLM to understand it, a skill-like context was designed that teachers it the grammar and use cases via many examples [3]. To ensure this actually works better, I have automated evaluations in this repo that ask the LLM to do various musical operations and judge the efficacy.

So in my experience, tight little DSLs for specific complex things can make an AI much more effective. The tricky part is token management. If the DSL is too complex and requires too many examples, then you have to burn a lot of tokens every conversation to make it work well. It's not a big deal with frontier models, but once you start targeting on-device small language models, the tokens really matter and it's a challenging balancing act. I've dealt with this via a simplified skill set that doesn't teach any of the advanced DSL features and simply pretends they don't exist.

In any case, the beginning of the article sounds like it's wondering how we're going to make new programming languages, which is a different concern from DSLs.

[1] https://github.com/adamjmurray/producer-pal/blob/v1.4.13/src... [2] https://github.com/adamjmurray/producer-pal/blob/v1.4.13/src... [3] https://github.com/adamjmurray/producer-pal/blob/a98f322dd84...

One thing I'd add to this list: lots and lots of examples.

Coding agents are absurdly good at understanding and adapting examples. If your new language includes a large collection of searchable examples even a weaker model should be able to find something close to what it's trying to achieve and directly adapt that example code.

Lenat's AM and Eurisko worked because large fraction of legal token strings were meaningful.

A DSL exists to give you the power and flexibility of a language, with functionality built-in to make it easier to accomplish specific tasks. It's like an application with a library and config file, but takes it a step further by allowing you to express complex logic.

Humans need help in forming, understanding, and expressing logic; that's what a language is. But computers have an easier time of it. They can essentially read and write whole lot of 0's and 1's and automate the same process without language. An AI is an in-between state: a computer designed to deal with language, to think and act like a human. AIs are pretty good at dealing with human stuff, but they're a poor choice for doing computer stuff.

So really, if you want to do something you'd normally use a DSL for, you should be talking to your AI, and telling the AI to encode it into computer-speak. Binary files, libraries, programs, composeable piped applications. The AI can take what you think and turn it into a regular old computer program, just as easy as you would write a DSL. But you don't need a DSL to do this; the AI can already program.

In fact, talking to an AI might have better results. Humans screw up code because they can't really hold all the logical permutations in their head at once. But the AI can take instructions, decompose them, explode all possible permutations, identify outliers, and encode the result in a programmatic format, that a library that parses actions can then turn into a deterministic program. The AI can take your instructions and convert it into executable binary. No need for pseudocode.

So the future of programming, if we desired to go there, would be Natural Language Programming. Our speech is the programming language, and the AI is the compiler. The trick would be to work on the loop between the human and AI, to be as specific and deterministic as possible, to ensure the compiled program does what we intend and expect. It's not hard for an AI to make a deterministic program, but it is hard to be sure that it's deterministic in the specific way we want.

A specific example. Slangify: The Case for DSLs in LLM Workflows.

https://rakujourney.wordpress.com/2026/06/08/slangify-the-ca...

Digital Subscriber Line? Ah, Domain Specific Languages.

Sigh, so many acronyms.

Yet another YAML?