Zum Hauptinhalt springen

Language Workbench

Eine Language Workbench ist eine Entwicklungsumgebung für den Bau eigener, meist domänenspezifischer Sprachen (DSLs). Sie liefert alles, was eine Sprache praktisch nutzbar macht: Sprachdefinition, Editor mit Code-Completion, Validierung sowie Codegenerierung oder Interpretation. Der Begriff wurde 2005 durch einen Artikel von Martin Fowler geprägt.

Was eine Language Workbench leistet

Eine Sprache zu definieren ist der kleinere Teil der Arbeit — nutzbar wird sie erst durch Werkzeuge. Genau diese liefert eine Language Workbench aus einem Guss:

  • Sprachdefinition: Grammatik bzw. Struktur der Sprache — das Metamodell mit Konzepten, Beziehungen und Constraints.
  • Editor: Syntax-Highlighting, Code-Completion, Navigation und Refactoring für die neue Sprache.
  • Validierung: Domänenregeln werden beim Tippen geprüft, nicht erst beim Build oder Test.
  • Generierung und Verarbeitung: Codegeneratoren, Interpreter und Modelltransformationen erzeugen aus den Modellen Code, Konfiguration oder Dokumentation.

Ohne Language Workbench müsste jede dieser Komponenten von Hand entwickelt werden — was den Bau externer DSLs früher meist unwirtschaftlich machte.

Parserbasiert vs. projektional

Zwei Paradigmen dominieren:

ParadigmaPrinzipTypischer Vertreter
ParserbasiertModelle liegen als Text vor und werden geparst. Textdateien sind diff- und mergebar und lassen sich nahtlos in Versionskontrolle und CI/CD-Pipelines integrieren.Xtext
ProjektionalNutzer bearbeiten direkt den Abstract Syntax Tree; die Notation ist nur eine Projektion darauf. Das ermöglicht Notationen jenseits von Text — Tabellen, mathematische Ausdrücke, grafische Elemente — und die saubere Kombination mehrerer Sprachen.JetBrains MPS

Bekannte Language Workbenches

Xtext ist die etablierte Open-Source-Workbench für textuelle DSLs auf Basis von Eclipse und dem Eclipse Modeling Framework. Über das Language Server Protocol (LSP) lassen sich Xtext-Sprachen auch in moderne Editoren wie VS Code einbetten. itemis zählt zur Entstehungs-Community von Xtext (seit 2006) und stellt aktive Committer.

JetBrains MPS ist die bekannteste projektionale Language Workbench. Ihre besondere Stärke: Mehrere Domänensprachen lassen sich sauber kombinieren, und Notationen sind nicht auf Text beschränkt. itemis ist Hauptmaintainer zentraler MPS-Extensions (iets3, mbeddr) und arbeitet als JetBrains-Partner seit über zehn Jahren mit dieser Technologie.

Language Workbenches in der Praxis

Die Wahl der Workbench folgt aus zwei Fragen: Welche Notation braucht die Domäne — reiner Text oder auch Tabellen, Formeln, Grafik? Und wo soll das Werkzeug laufen — in VS Code, im Browser, als Erweiterung einer bestehenden Toolchain? Für textuelle DSLs mit IDE-Integration ist Xtext plus LSP ein bewährter Weg; für komplexe Sprachkomposition und formale Notationen ist MPS die flexiblere Wahl. Unabhängig vom Werkzeug gilt: Der Erfolg einer Sprache entscheidet sich in der Domänenanalyse davor — eine Workbench beschleunigt den Sprachbau, ersetzt aber nicht das Verständnis dafür, wie die Experten einer Domäne tatsächlich arbeiten.

Häufige Fragen

Was ist der Unterschied zwischen Xtext und JetBrains MPS?
Xtext erzeugt textuelle Sprachen mit eigenem Editor, Syntax-Highlighting, Validierung und Code-Completion — auf Basis von Eclipse und dem Eclipse Modeling Framework. MPS arbeitet projektional: Nutzer bearbeiten direkt den Abstract Syntax Tree, nicht Text, was Hybridnotationen (Text, Tabellen, Grafik) in einer Sprache ermöglicht. Xtext ist näher am klassischen Editor-Paradigma; MPS bietet mehr Flexibilität für nicht-textuelle Sprachen.
Brauche ich für jede DSL eine Language Workbench?
Nein. Interne DSLs, die in eine Wirtssprache wie Kotlin oder Ruby eingebettet sind, nutzen deren Syntax und Werkzeuge mit. Eine Language Workbench wird gebraucht, wenn eine externe DSL mit eigener Syntax entstehen soll — samt Editor, Validierung und Generator, die sonst von Hand gebaut werden müssten.
Wie lange dauert die Entwicklung einer Sprache mit einer Language Workbench?
Ein Sprachprototyp, der die Kernkonzepte abdeckt, ist meist in 4 bis 8 Wochen realisierbar. Ein vollständiges DSL-Projekt mit Editor, Validierung und Generator umfasst je nach Komplexität der Domäne 3 bis 12 Monate.

Verwandte Begriffe

Fachlich geprüft von Axel Terfloth, Principal Engineer am 20. Juli 2026