Lenat's AM and Eurisko worked because large fraction of legal token strings were meaningful.
How a new DSL may survive in the era of LLMs
11–20 of 21 posts
Re: How a new DSL may survive in the era of LLMs
#12A 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 essentia…
> 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. I use LLMs…
When LLMs write bash one-liners today, it often leads to errors. There's a large range of possible functionality, different versions, extra abstractions, uncertain errors, varying functionality, lack of types and schemas. The CLI is kinda like a language, but much more abstract; this confuses the LLM. Imagine if the English language changed as often and as widely as a CLI program's arguments, options, outputs can across versions, platforms. On the other hand, if the LLM writes python instead of bash, it often leads to more reliable results for the same task, since it varies less frequently, is more specific, can be syntax-checked, has standard metadata, more expressive logic, etc. But there's also a lot of useful functionality exposed by applications that doesn't exist in many libraries, so there are limits.
We do need more tools for the AI to turn our requests into deterministic, reliable, correct results. But this isn't a DSL thing, it's more like a pipeline of steps to get from A to Z. This will likely require multiple bidirectional passes, to confirm with the human along each step, and fix and re-do the pipeline when a mistake is found. You could encode the final result in some kind of DSL, but it'd only be useful as a read-only artifact; if you change a line of it, without extensive testing in an immutable environment, it introduces bugs. We need to lean more into reliability with LLMs since they are so fallible.
Re: How a new DSL may survive in the era of LLMs
#13Earlier quoted context omitted.
I've been working on DML, a Prolog-based DSL [0] used to define and orchestrate agents and LLM workflows. It's been quite fun, although - given the amazing capabilities of SOTA models - I am not so sure anymore how meaningful it will be to continue with this work. Anyways, the language and also supports DCGs, so it should allow for plenty of interesting ways to combine grammars, LLMs, agents etc. [0] https://github.c…
> I've been working on DML, a Prolog-based DSL [0] used to define and orchestrate agents and LLM workflows. ... I am not so sure anymore how meaningful it will be to continue with this work. Perhaps the research documented in "Combining Constraint Programming Reasoning with Large Language Model Predictions"[0] can provide meaning and/or options to your work. I hope so, because the idea of Prolog leveraging language m…
Thank you! This looks very interesting!
Re: How a new DSL may survive in the era of LLMs
#14Digital Subscriber Line? Ah, Domain Specific Languages. Sigh, so many acronyms.
No, digital subscriber line, obviously
Re: How a new DSL may survive in the era of LLMs
#15reminds me a lot of mesos
Re: How a new DSL may survive in the era of LLMs
#16Yet another YAML?
yaml is not a DSL. no matter how much people try and fail repeatedly to use it as one.
Re: How a new DSL may survive in the era of LLMs
#17One 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.
Agreed @simonw and if you can give positive examples you get better results with negative examples of what not to do
Re: How a new DSL may survive in the era of LLMs
#18[dead]
Re: How a new DSL may survive in the era of LLMs
#19Digital Subscriber Line? Ah, Domain Specific Languages. Sigh, so many acronyms.
whatever you do, don’t search urban dictionary for DSL definition
Re: How a new DSL may survive in the era of LLMs
#20A specific example. Slangify: The Case for DSLs in LLM Workflows. https://rakujourney.wordpress.com/2026/06/08/slangify-the-ca...
glad you mention https://slangify.org … we are pulling together a set of tooling and example DSLs to make this kind of LLM-DSL combination super easy