alt Hacker NewsDSLs Enable Reliable Use of LLMs
Comments
What is the general consensus on Martin Fowler - I worked with Thought Works and they were obsessed with overcomplicating everything, but maybe that is just agency in general?
I think it goes without saying that the biggest fight we have as developers is keeping things as simple as possible when most external factors encourage complexity, especially LLMs.
I already had a DSL and with a proper prompt and a checker tool, even tiny LLMs could build really good scripts in that language. Gemma 12B QAT was excellent.
Actually the tool-calling convention is a small DSL too.
I suspect the DSL ideally has to be similar to something in the LLM's training set though.
It doesn't have to feel too alien, otherwise the description of it has to be thorough and will eat up a lot of context.
Frontier models don't suffer as much of this limitation since they can grab onto a larger corpus of knowledge, but they're expensive.
Pretty much how I use LLMs these days. Even Chatbots are able to work with a 200 line spec for the DSL.
You'd think it wouldn't because, well, no training data, but a short spec is usually enough.
This reminds me of this Bjarne Stroustrup's Rule (creator of C++): - For new features, people insist on loud, explicit syntax. - For established features, people want terse notation
Hillel Wayne [1] argues that the same applies for the differences between what beginners and experts desire from a language: Beginners need explicit syntax, experts want terse syntax.
In my mind, DSLs are related to that – a short notation to avoid repetition. And LLMs are the experts.
I wonder if Lisp with its powerful DSL-creating macros will enjoy more popularity in the near future.
[1] https://buttondown.com/hillelwayne/archive/stroustrups-rule/
Logically this makes sense, but in practice it doesn’t, at least in my experience with SwiftUI. The LLM isn’t any better about generating/understanding it.
While the DSL is more formal than natural language, it’s not what we’re communicating to the LLM with, so it’s advantages are washed away. And typical code is more strict/rigorous than DSLs so I think that’s why I see worse results, because a typical languages compiler “catches” more mistakes, versus a DSL that’s easy to write but has lots of implicitness.
I’ve had the same journey experimenting with levels if abstraction too. Going lower, and exposing the LLM to the “full-stack” works much better than trying to build up abstractions it can’t see into without extra steps.
I don’t want to be too much of a hater, but these types of panacea/architecture posts are usually written by people who don’t work in the field, lack pressure or constraints, and get paid to goof around in castles of the mind. I would simply skip over it and hold my comments/opinions to myself, but they tend to have an outsized influence on software engineering practices.
As much as I dislike them [1], DSLs are an easy way to provide domain specific backpressure to your llm which might not easily be available in your language.
1- https://mikehadlow.blogspot.com/2012/05/configuration-comple...
The post would have been stronger and more useful focusing and expanding on the abstraction portion of his message as well as system and program design. Those elements were there but seem sidelined by the focus on DSL. For most developers on most projects, the key take away is we all have to both get good at system and program design especially around abstractions, shapes, responsilibility. Then we have to get good at inserting our selves in the AI loop to steer those decisions a lot in the beginning, regularly as the project kicks off and still more than we think as the project matures.
This remains one of the best articles I have read on LLMs (by the same author) https://martinfowler.com/articles/llm-learning-loop.html
Also this article is a good pre-cursor to the DSL article:
What I do for my one framework (in dotnet, strong typing & compiler) is to create claude skills (bash scripts and dotnet console apps) that claude can call to do various things within the framework. I have a template engine (for classes/db scripts/view engine templates), build tools, deployment tools, backup tools, infra docs - all of it works amazingly well. I built them in a standardized way so it's easy to chain them together and claude just 'gets it'. It feels like a DSL on steroids.
edit: this is all on linux + posgresql.
Rather than DSLs I’ve found careful force tools results force the same kind of discipline in a more straightforward way to implement. So it’s normal to ask the llm to answer only yes or no and they are pretty good at following that instruction but it doesn’t scale so well. Whereas if the shape of the force tool call gives them more richness without giving them freedom to go off piste it scales to more nuanced results whilst also being trivial to parse.
I agree. What is missing from the discussion about DSLs are the importance of tooling such as linters, LSPs, etc, to give the LLMs further context.
For example, charts/plots are often stringly typed with regards to column names and a DSL specific to plotting could give immediate feedback to an LLM.
The gap I've hit generating GPU kernels with agents code that compiles and runs fine but is slower than the baseline. Validator says pass, result is useless. Speed targets have to be part of the check, not just correctness
I discovered this a few months ago when I was describing a binary data format using Dogma. On a whim, I tried handing the task off to Claude and it not only finished it correctly, but also fixed some errors!
I frequently blur the line between ad-hoc DSL and pseudocode, and just hand it off to the LLM. I want to get the thoughts out of my head as fast as possible, using whatever structure makes sense to me. Even if you know all of the code to be written, I think this is a huge win with LLMs, where your intent is more important than syntax.
That’s basically LISP 101. Before solving a problem, you build out the spare parts and the tooling. And then the software building feels like assembling lego blocks. Building a DSL or a good set of symbols (functions/classes/constants/enum/…) is the cornerstone of DDD.
The actual implementation details only matters at the coding stage. At the design stage, it’s better to define the glossary and its semantic.
Blimey there is always a new thing to learn/use/know with AI - keeping up is getting tiring.
The only thing which enables reliable use of LLMs are statistical techniques.
Even the most constrained and well-designed Disney world ride will break down in some embarrassing way every now and again. As you increase the # of parallel rides, the chances that at least one of them will touch the desired parts of the search space go up dramatically.
The fact that the major model providers keep publishing nano/mini/luna variants should be a massive hint that there's more to this than one big fat loop magically one-shotting everything.
So, formal verification then...
> PlantUML, Mermaid, and Graphviz are domain specific languages for visual modeling; SQL is a DSL for querying databases; Kubernetes YAML is a DSL for describing cloud infrastructure.
Arent these all in training data too?
I'm really starting to tire of people making broad, general claims about how LLMs work or how to use them with N = 1 or 2.
An LLM is a statistics machine for goodness sake. Basically any general claim about them needs to exploit the law of large numbers to be even remotely sensible. You cannot extrapolate from one-off behavioral successes. LLMs are not understanding anything in the way humans do. If they did, yeah, maybe you could extrapolate hard from small samples, but they don't work or understand things like we do. You need to show that the behavior you are documenting is an average behavior the LLM converges toward in the long run.
The return of Ruby =]
"DSL" is a stupid word. If it's a language, it's a language.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
what does it do , can u explain more?
> The advantage holds while the DSL stays small and constrained enough that a few in-context examples can convey its usage. There is also a real upfront cost in designing and maintaining the language and its semantic model. The payoff is therefore concentrated in well-factored, genuinely constrained DSLs backed by a validator.
dsl stays small is doing all the heavy lifting here
the premise is that because of these few existing dsls (like PlantUML mentioned) my "new dsl" will be equally effective. PlantUML has millions of examples in the training data, my new dsls are not (specially if its not json/yaml or just function chain based). as the number of things that can mix and match increase you are basically looking at a whole system prompt just describing the new language.
this brings us to the second part. step 2: after dsl is 'planned' (note they use the java compiler), the dsl need to have a real compiler/executor, not just a validator. because if then you are going to ask the llm to "compile the dsl to implementation" we are back to square 1.