sovereigntyai

The Role of Domain Specific Languages

·6 min read

How the demand for sovereign data formats and large language models push the need for domain specific languages.

Over the last decade, Domain Specific Languages (DSLs) have been picking up are as a base for software tools. But what exactly does that mean for software development and the tech sector?

Notable Projects

  • Iaac
  • Atopile
  • zoo.dev

Over the last few years, two trends have emerged that make the use of domain specific languages ever more important and valuable. On the one hand there's demand for sovereign, interoperable and open file formats as a result of geo political tensions and over-reliance on proprietary tech. On the other hand, LLMs are starting to prove their usefulness as seen with the rise of a new market for AI-enabled tools. Both trends clearly benefit from investing more into open declarative languages.

Why DSLs

Towards Interoperable Software

EU member states are starting to embrace open source tools and standards. The benefit for government office workers is clear: interoperable and open formats break off the shackles put on by Big Tech companies. Such a realization does not just lead them to the "next Microsoft" but instead puts preference towards interoperability to rule out tech tyranny by design. It's important to apply such preventative thinking not just in the government sector, but across all of the tech industry. Monopolies have been able to enshittify the tools we rely on simply because they're too big to fail and we currently have nowhere else to go.

When someone sends you a Word document or PowerPoint presentation, along with it comes the expectation that you have purchased proprietary Microsoft products and consented to their Terms and Conditions. Such office tools should rather be part of the public commons drafted by international standards bodies. The design space for such interoperable standards can draw inspiration from existing web standards: HTML, CSS and Javascript are just a collection of text files at the end of the day. Editing or reading them does not require proprietary software, all information is embedded into the text file as a DSL.

Another benefit of using DSLs as a data format for software tools is that changes to such text files can easily be tracked. Conflicts can easily be managed as the differences

While not perfect, there are some other notable examples in other domains that make

file format is ripe for domain specific languages and then have arbitrary .

There is no need for such software to be built on top of data formats that are either binary files or some bespoke markup. Rather they should be commonly accepted text files that declarative format that can simply be edited using a text editor.

To combat this, software tools that everyday people rely on should be designed such that the underlying

agreed to the Terms and Conditions of Microsoft Word and PowerPoint after

to be based on an open and declarative language

By designing our software tools to export to open and declarative formats

open & declarative formats for the software that we depend upon

Open Languages for Large Language Models

The jump in programming capabilities of LLMs is in part thanks to the investments made by software companies to prioritize improvements in code generation. Models have been getting better at generating code, but haven't progressed as much in other areas like telling jokes. Another reason why LLMs have gotten so much better in programming, is because they've been given tools that they understand. Some tools output helpful error messages and warnings which can be fed back into the model in an iterative fashion. Unsurprisingly, the software industry has a focus on source code and has thus built an ecosystem of tooling around source code itself. This is immensely useful for a machines that inherently just generate text.

However, in comparison with domains that aren't centered around text, LLMs have yet to make the same leaps in capability. A recent study found that LLMs "struggle to integrate sequential planning with visual understanding". The LLM simply can't make use of PowerPoint's user interface the same way that a human can. It's only able to work with the underlying representation of the slide deck, namely a large pile of hard to read XML files. If there was better tooling around those XML files, the LLM could make use of it and likely advance its capability in generating slide decks.

iterative loop

where the agents can validate, test and run the code themselves.

By editing

For the last few decades, software tools enabled us to express our intentions about design, form, and function and have thus dominated office work entirely. For example, a photographer might use Photoshop to edit their pictures and a business analyst might use Excel and PowerPoint to convince shareholders. However in those cases the

However, a programmer expresses their intent to the computer by following the rules of a programming language. As a productivity tool, the programming language has a fundamental benefit over Photoshop, Excel and PowerPoint, namely because it's a medium that deterministically generates the product of value (the executable program). The source code is not just the blue print of the final product, but with the press of a button it becomes the final product. The two are inextricably linked.

it constrains the set of valid expressions of intent. It's easy to make a

Declarative Languages

Examples

  • Infrastructure as code
  • Latex / Typst