Lohnt es sich, eine eigene Programmiersprache samt Syntax-Highlighting, Code Completion anderen Features im Editor nur für ein einzelnes Projekt zu erstellen? Was sich auf den ersten Blick nach viel Arbeit anhört, ist dank Language Server Protocol (LSP) deutlich einfacher geworden. Durch die reichhaltigen Möglichkeiten zur Interaktion mit Texteditoren wie Visual Studio Code eignen sich domänenspezifische Sprachen (Domain Specific Languages, DSL) als eine vollwertige und auch unterschätzte Möglichkeit der Gestaltung einer UX.

Anwenderinnen und Anwender jenseits der Informatik nehmen Spezifikationen oft mit Formularen vor. Je komplexer die Anforderungen sind, desto komplizierter wird die Umsetzung per Formular. Ein grotesk wirkendes Beispiel zeigt Abbildung 1: Anweisungen für einen Compiler, über ein Formular zu spezifizieren.

Gleich mehrere Gründe machen diese Idee so absurd:

• Die Spezifikation ist völlig aufgebläht: Die noch unvollständige Implementierung des Heron-Verfahrens zum Wurzelziehen lässt sich auch mit nur drei Zeilen Code umsetzen.
• Als direkte Folge davon ist das Formular deutlich schwerer verständlich.
• Für erfahrene Nutzer ist eine Programmiersprache sehr viel effizienter, weil sie in der gleichen Zeit wesentlich mehr Spezifikationen verfassen können.
• Es ist nur schwer vorstellbar, wie man eine formularbasierte Programmspezifikation versionieren kann. Textbasierte Algorithmen, wie Git sie verwendet, funktionieren hier vermutlich nicht.

Eine komplexe Spezifikation ist keine Besonderheit der Informatik, auch in anderen Fachbereichen gibt es schwierige Probleme, die immer mehr mithilfe von Computern gelöst werden sollen. Das kann die Automatisierung von Workflows sein, die Planung von Bauteilen oder Gebäuden, die Dokumentation von manuellen Prozessen oder vieles mehr. Ein Erfolgsfaktor von Programmiersprachen ist sicherlich, dass Programme sowieso abstrakt sind, während sich physische Bauteile oder Gebäudepläne schon immer auch grafisch haben repräsentieren lassen. Das Beispiel von Prozessautomatisierung zeigt aber, dass in vielen Bereichen ebenfalls abstrakte Konzepte auftreten.

Innerhalb der Informatik haben sich textuelle Sprachen auch jenseits des Programmierens bewährt. Admins legen Infrastrukturen in der Cloud schon lange nicht mehr per Formular an (diese Praxis wird eher als ClickOps geschmäht), sondern in Textform per Infrastructure-as-Code. Die Gründe sind dieselben: die Spezifikation ist schlanker, verständlicher, einfacher zu versionieren und man ist damit schneller.

Einfacher zu versionieren als Formulare, sind generische Formate wie JSON oder XML. Sie sind allerdings ursprünglich nicht dafür gedacht, für Menschen lesbar zu sein, sondern für Maschinen. Da viele Anwendungen ohnehin eine maschinenlesbare Sprache benötigen, ist es bequem, diese auch als alternative Schnittstelle anzubieten.

Aber auch solche Konfigurationsdateien erreichen nicht die Prägnanz, Lesbarkeit und Effizienz einer domänenspezifischen Sprache, zumal auch Validierungstechnologien wie XML Schema oder JSON Schema nur die Struktur der Dokumente validieren, aber wenig zur fachlichen Analyse beitragen können.

DSL als Alternative zu Formularen und Konfigurationsdateien

Komplexe Vorgänge, die Menschen gern sehr prägnant, lesbar und versionierbar ausdrücken wollen, kann man vorteilhaft mit einer domänenspezifischen Sprache spezifizieren, mit der gleichen Editorunterstützung wie bei Programmiersprachen. Beispiele wären Reisekostenabrechnungen, Nebenkostenabrechnungen, Steuererklärungen, Umsatzabfragen, Prozessautomatisierungen oder Bauplanungen.

LLM-basierte Chatfunktionen sind dabei kein Ersatz für domänenspezifische Sprachen, umgekehrt aber können domänenspezifische Sprachen die Intention eines KI-Systems einfacher überprüfbar machen. Anstatt agentenbasierte Systeme kritische Dinge tun zu lassen (was zumindest in der EU per AI Act streng reglementiert ist), kann man KI-Systeme auch eine in natürlicher Sprache vorliegende Beschreibung in eine DSL umformulieren lassen.

Das Language Server Protocol als Enabler für eine DSL-UX

Die Entwicklung einer domänenspezifischen Sprache reduziert sich nicht nur auf einen Parser: Nutzerinnen und Nutzer sind den Komfort von Syntax-Highlighting, Code Completion, bequemes Springen zur Definition oder zu Referenzen gewohnt, die wesentlich für eine gute UX und gesteigerte Produktivität sind. In den letzten Jahren ist dies durch das von Microsoft entwickelte Language Server Protocol (LSP) deutlich einfacher geworden. Dieses Prinzip hat sich auf weitere Bereiche ausgeweitet, zum Beispiel auf grafische Sprachen mit dem Graphical Language Server Protocol (GLSP). LSP und GLSP erlauben es, weitgehend auf die Entwicklung von UI-Komponenten zu verzichten und sich stattdessen auf die Semantik einer Sprache zu konzentrieren.

Aus diesem Grund können Editoren wie Visual Studio Code mit beliebigen Programmiersprachen umgehen: Während sie als Frontend immer dasselbe UI verwenden (im Fall von Visual Studio Code den Monaco-Editor), liefert ein LSP-Server die sprachspezifische Editorunterstützung. Da LSP auf JSON-RPC basiert, das keine Transportschicht definiert, lässt sich LSP wahlweise über stdin/stdout oder über Websockets betreiben. Das ermöglicht viele Optionen für das Deployment: Der Client kann in einer Desktopanwendung (in Fall von Visual Studio Code via Electron) oder im Browser laufen, während der Server entweder in die IDE eingebettet oder auf einem entfernten Rechner arbeitet.

Mittlerweile gibt es für die Entwicklung von LSP-Servern mehrere Frameworks, je nachdem, mit welcher Programmiersprache man die DSL entwickeln will. Für die Beschreibung der Grammatik der DSL kommt ebenfalls eine DSL zum Einsatz. Daraus generiert das Framework Parser, Klassen für den abstrakten Syntaxbaum und die Editorunterstützung. Entwicklerinnen und Entwickler können das Ergebnis durch manuellen Code ergänzen oder überschreiben. Beispiele für entsprechende Tools sind Xtext für Java (siehe auch: [1]), Langium für TypeScript und AnyText für .NET (siehe auch [2]).

Eine neue DSL entwickeln

Der Startpunkt für die Entwicklung einer neuen DSL ist mit allen dreien der genannten Frameworks eine Grammatik, die auch die abstrakte Syntax der Sprache ausdrückt. Die abstrakte Syntax ist hierbei die Definition der Konzepte, die die Sprache ausmachen. Für die Grammatik werden bei Xtext und Langium kontextfreie LL(k)-Grammatiken verwendet, bei AnyText Parse-Expression-Grammatiken (PEGs). Beide Klassen von Grammatiken arbeiten mit Nichtterminalen (= Platzhaltern) und Produktionsregeln, die bestimmen, wie ein Nichtterminal ersetzt werden kann. Diese Produktionsregeln lassen sich bequem über die Metasprache Erweiterte Backus-Naur-Form (EBNF) spezifizieren, die zusätzlich noch um Zuweisungen ergänzt wird, um auch die abstrakte Syntax angeben zu können.

Praktischerweise bietet Langium mit dem Playground eine Möglichkeit an, mit der Entwicklung einer DSL ohne Installation einer Software direkt im Browser zu beginnen. Für Xtext oder AnyText bieten die Tutorials gute Einstiegspunkte.

Um beispielsweise die (hier vereinfachte) Deklaration einer Klasse in einer Programmiersprache zu spezifizieren, genügt das folgende Fragment:

Class: ‘class’ name=ID ‘{‘ members+=ClassMember* ‘}’;

Dieses Beispiel geht davon aus, dass es weitere Nichtterminale ID und ClassMember gibt, die regeln, wie ein Identifier genau aussieht und was zulässige Member einer Klasse sein können. Der Postfixoperator * erlaubt hierbei beliebig viele Member. Alternativ sind auch + oder ? möglich, um mindestens oder höchstens ein Vorkommen zu beschreiben. Der Operator | erlaubt auch Alternativen, was unterschiedliche Arten von Membern ermöglicht. Besteht eine Regel ausschließlich aus Alternativen, dann wird das in der abstrakten Syntax durch Inheritance abgebildet.

Die Zuweisung = bzw. += weist das System darüber hinaus an, das Ergebnis des Nichtterminals ID bzw. ClassMember dem abstrakten Element des Nichtterminals zuzuordnen. Das geht entweder als einwertige Eigenschaft (beispielsweise, dass das Ergebnis von ID den Namen bilden soll) oder als mehrwertige Eigenschaft, dass das Ergebnis von ClassMember zur Auflistung members hinzugefügt werden soll.

Aus diesen Zuweisungen lassen sich dann auch Klassen ableiten, um die abstrakten Elemente der Sprache im Speicher darstellen zu können. Sowohl Xtext und Langium als auch AnyText unterstützen den Operator [], mit dem sich Referenzen abbilden lassen, dass also an einer gegebenen Stelle nur eine Referenz auf ein anderes syntaktisches Element erscheinen soll.

Die Konstruktion des Parsers bleibt zwar weitestgehend vor den Entwicklern verborgen, allerdings haben manche Klassen von Grammatiken Einschränkungen, die Entwickler einer DSL berücksichtigen müssen. So sind die Produktionen bei kontextfreien Grammatiken ungeordnet, bei PEGs aber geordnet, weswegen es konstruktionsbedingt keine Mehrdeutigkeiten gibt. Gängige Parser für kontextfreie Grammatiken unterstützen keine Linksrekursionen, für PEGs aber schon.

Die Unterstützung von Linksrekursionen ist vor allem für Ausdrücke wichtig, da man damit sehr intuitiv Formeln umsetzen kann. Insbesondere sind binäre Ausdrücke selbst Ausdrücke, beginnen aber auch mit einem Ausdruck. Für PEGs haben Warth und andere [3] eine Erweiterung von Packrat-Parsern entwickelt, die Linksrekursionen parsen kann, wobei das lineare Laufzeitverhalten von Packrat-Parsern erhalten bleibt.

In AnyText lässt sich daher eine einfache Expression-Grammatik wie in Listing 1 unten dargestellt implementieren. Hierbei überschreibt das Schlüsselwort returns, welche Klasse der abstrakten Syntax das Nichtterminal zurückgibt. Im Beispiel dient es dazu, nicht für jedes einzelne Nichtterminal eine Klasse einführen zu müssen. Das Schlüsselwort enum kommt zum Einsatz, um eine fixe Menge von Werten abzubilden. Ferner beschreibt das Schlüsselwort parantheses ein Nichtterminal für Klammerungen und terminal ein Terminal, dargestellt durch einen regulären Ausdruck.

grammar Expressions (exp)
root Expression

Expression:
  AdditiveBinary | Multiplicative;
AdditiveBinary returns BinaryExpression:
  left=Expression operator=AdditiveOperator right=Expression;
enum AdditiveOperator returns BinaryOperator:
  Add => '+'
  Subtract => '-';
Multiplicative returns Expression:
  MultiplicativeBinary | LiteralExpression | VariableExpression | ParanthesisExpression;
MultiplicativeBinary returns BinaryExpression:
  left=Multiplicative operator=MultiplicativeOperator right=Multiplicative;
enum MultiplicativeOperator returns BinaryOperator:
  Multiply => '*'
  Divide => '/';
LiteralExpression:
  value=Number;
VariableExpression:
  variable=Identifier;
parantheses ParanthesisExpression:
  '(' Expression ')';
terminal Number returns nmeta.Integer:
  /\d+/;
terminal Identifier:
  /[a-zA-Z]\w*/;

UX-Interaktionen im Editor über LSP

LSP ist nicht nur auf das Parsen von Text begrenzt, sondern erlaubt auch praktische Interaktionen mit einem Text in der IDE. Programmiererinnen und Programmierern sind Features wie Code Lenses oder Code Fixes geläufig. Sie erlauben es, Analyseergebnisse wie die Anzahl der Referenzen oder Autor und Datum der letzten Änderung an einer Methode einfach in das Sichtfeld einzublenden. Interaktionen wie Refactorings lassen sich ebenfalls direkt aus dem Code heraus starten.

Zu Features dieser Art gehören:

• Diagnostics: In den seltensten Fällen lassen sich Einschränkungen allein durch die Grammatik ausdrücken, auch domänenspezifische Analysen können auf Fehler hindeuten. Beispielsweise könnte man in einer DSL für Überweisungen eine Analyse des Empfängernamens einbauen und Fehler melden, sollte der Name nicht zur IBAN passen.
• Code Lenses: Code Lenses können an einer beliebigen Stelle im Text eine beliebige Zeichenkette anzeigen. Damit lassen sich viele Arten von Analysen darstellen. Code Lenses können auch Aktionen anbieten, zum Beispiel öffnet sich beim Klicken auf die Anzeige der Referenzen üblicherweise ein Fenster mit Details. Einige Editoren bieten auch an, Unit Tests per Code Lens zu starten. Recht generisch könnte man Code Lenses verwenden, um in einer DSL den derzeitig beschriebenen Zustand auf ein modelliertes System anzuwenden.
• Code Actions: Von Editoren wie der Visual-Studio-Familie mit einem Lampensymbol dargestellt, erlauben es Code Actions, zum Kontext passende Interaktionen auszuführen.
• Inlays: Inlays blenden Texte im Editor ein, die eigentlich gar nicht dort stehen. Während dieses Feature in Programmiersprachen vor allem dazu dient, inferrierte Typsignaturen oder Parameternamen einzublenden, lässt es sich prinzipiell für beliebige Analysen verwenden.
• Hover: Verweilt ein Nutzer mit der Maus auf einem Token, kann ein LSP-Server Kontextinformationen dazu liefern. Eine sehr clevere Nutzung ist beispielsweise, einen Hovertext für Schlüsselwörter mit Erklärungen dazu anzubieten. Gerade weil eine DSL nur für einen eingeschränkten Nutzerkreis gedacht ist, kann eine solche Unterstützung die Anwendung leichter zugänglich machen.

AnyText macht die Entwicklung dieser Features besonders einfach, indem es für jede Regel in der Grammatik eine Klasse generiert, in der Entwickler meist nur eine entsprechende Methode überschreiben müssen, um das jeweilige Feature zu aktivieren. Aber auch mit Langium oder Xtext lassen sich diese Features einfach nutzen.

Fazit: Alternative UX-Technologie

Domänenspezifische Sprachen haben neben Formularen oder KI-Agenten einen eigenen Platz als Möglichkeit verdient, mit der Endanwender spezifizieren, welche Probleme der Computer lösen soll. DSLs richten sich dabei vor allem an Expertinnen und Experten, die solche Spezifikationen häufiger verfassen müssen, für die also Produktivität, einfache Versionierbarkeit und Interoperabilität textueller Sprachen besonders vorteilhaft sind.

Dabei hat sich die Entwicklung neuer DSLs durch Innovationen wie das Language Server Protocol und Frameworks wie Langium, Xtext oder AnyText dramatisch vereinfacht. Wo Developer Parser früher per Hand schreiben mussten, können sie diese heute mit Editorunterstützung weitgehend aus der Spezifikation einer Grammatik ableiten, was den Aufwand stark reduziert. Daher sollten DSLs als alternative UX-Technologie durchaus in Betracht gezogen werden.

Literaturverzeichnis

[1] M. Eysholdt und H. Behrens, „Xtext: implement your language faster than the quick and dirty way,“ in Proceedings of the ACM International Conference Companion on Object Oriented Programming Systems Languages and Applications Companion, Reno/Tahoe, Nevada, USA, Association for Computing Machinery, 2010, pp. 307–309.

[2] G. Hinkel, A. Hert, N. Hettler und K. Weinert, „AnyText: Incremental, left-recursive Parsing and Pretty-Printing from a single Grammar Definition with first-class LSP support,“ Proceedings of the 18th ACM SIGPLAN International Conference on Software Language Engineering, SLE 2025, pp. 98–111, 12–13 Juni 2025.

[3] A. Warth, J. R. Douglass und T. Millstein, „Packrat parsers can support left recursion,“ in Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation, San Francisco, California, USA, Association for Computing Machinery, 2008, pp. 103–110.

(who)