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...