407 private links
Domain-Specific Languages are small languages designed to focus on a specific aspect of a software system. We deal with DSLs every day: SQL can be considered a DSL, LaTeX is a DSL, AWK is a DSL, Kubernetes’ YAMLs are a DSL.
The Token-Oriented Object Notation is optimized to have fewer tokens to parse for LLMs.
A domain-specific language is by definition smaller in scope than a general-purpose language, so it should be easier to design and implement; moreover, if the language is designed well, it should lead to a more efficient usage of the context window.
If we can abstract away parts of our domain into a higher-level language, we can effectively use the LLM to
- generate the implementation of a DSL
- generate documentation and examples for such our DSL
- point the LLM to docs and examples and prompt it to generate more code using our DSL
So, instead of trying to come up with a general-purpose language for LLMs, we define a tiny DSL for each specific subsystem we mean to realize.
Examples
- Piano
- Business Rule
About maintenance: the author claims they can be automated with LLMs.
The cost of defining an external DSL (own language with syntax and parser) is reduced compared to internal DSL (in a generic programming language). Also not a problem with LLMs.
In recent years, there has been something of a “winter” in DSL design and development due to the high maintenance costs and the tooling expectations from end users. This blog post explored the syntactic dimension of “token-efficiency” in DSL design: I invite you to explore more of this space, including semantics; I, for one, will welcome more crazy DSL implementations!
