I would like to view this page in
Eine domänenspezifische Sprache ist eine Programmiersprache mit höherem Abstraktionsniveau, die für eine spezifische Klasse an Problemen optimiert ist. Eine DSL nutzt Konzepte und Regeln, die zu einem bestimmten Feld oder einer Domäne gehören.
Eine domänenspezifische Sprache ist in der Regel weniger komplex als eine universell verwendbare Sprache wie Java, C oder Ruby. In der Regel werden DSLs in enger Zusammenarbeit mit Menschen entworfen, die Experten auf dem Gebiet sind, für das die DSL entwickelt wird. In vielen Fällen richten sich DSLs nicht an Softwareentwickler, sondern an Nicht-Programmierer mit einer Spezialisierung in der Domäne, auf die die DSL zugeschnitten wird.
Die Verwendung von DSLs kann viele Vorteile mit sich bringen. Der offensichtlichste Vorteil liegt in der Optimierung der allgemeinen Performance: Sobald Ihnen eine Sprache und eine Transformations-Engine zur Verfügung stehen, werden Ihre Arbeitsprozesse in dem spezifischen Aspekt der Softwareentwicklung, den die DSL abdeckt, viel effizienter, da Sie sich ab da die manuellen Routinearbeiten sparen können. Wenn Sie Quellcode aus Ihrem DSL-Programm generieren (anstatt ihn zu interpretieren), können Sie bequeme, domänenspezifische Abstraktionen ohne Erhöhung von Laufzeit-Overhead verwenden, da der Generator – genau wie ein Compiler – alle Abstraktionen entfernen und effizienten Code generieren kann.
Wenn Sie die Möglichkeit haben, domänenbezogene Probleme in einer Sprache zu formulieren, die sich stark an Ihrer Domäne orientiert, werden auch Ihre Gedanken klarer, da der Code, den Sie schreiben, nicht mit überflüssigen Details zur Implementierung überladen ist. Mit anderen Worten: Dank DSLs können Sie das Wesentliche von anfallender Komplexität trennen.
DSLs, deren Domäne, Abstraktionen und Notationen sich stark an der Ausdrucksweise der Domänenexperten (d. h. Nicht-Programmierer) orientieren, ermöglichen eine hervorragende Integration der Arbeitsprozesse von Technikern und Domänenexperten.
Die Verwendung von DSLs und einer Ausführungs-Engine trägt dazu bei, dass die im DSL-Code dargestellte Programmlogik nicht von der Zielplattform abhängig ist. Mithilfe von DSLs kann die Qualität des Endprodukts gesteigert werden: weniger Bugs, bessere Übereinstimmung mit der Architektur, erhöhte Wartungsfreundlichkeit. Das alles ist das Ergebnis des Verzichts auf (überflüssige) Freiheitsgrade, der Vermeidung von Codeduplikaten und der Automatisierung von Routinevorgängen.
Es gibt zwei grundlegend verschiedene Methoden für die Integration von traditionellem Code und DSLs. Bei der ersten Methode werden der DSL-Code und der gewöhnliche Code in separaten Dateien gespeichert. Der DSL-Code wird dann mittels automatischem Code-Generator in den Code der jeweiligen Programmiersprache transformiert, oder das Programm lädt den domänenspezifischen Code und führt ihn aus. Die erste Herangehensweise, bei der die Universalsprache (GPL) und der DSL-Code separiert sind, wird als externe DSL bezeichnet. SQL ist ein gutes Beispiel für eine externe DSL.
Eine alternative Herangehensweise mischt DSL-Code und den universellen Code in derselben Programmdatei, was zu einer viel stärkeren Integration der beiden führt. Die DSL verwendet die Grammatik und den Parser der GPL und nutzt die verfügbaren Erweiterungen der Hostsprache. Solche Szenarien werden als interne DSLs bezeichnet.
Es sollte erwähnt werden, dass einige GPLs besser für eine Erweiterung geeignet sind als andere.
Beide Herangehensweisen sind je nach Umständen sinnvoll, und MPS unterstützt beide.
Die Struktur und Syntax einer DSL wurde bestimmt durch den Code der Sprache, in die die DSL eingebettet werden sollte. In der Regel wussten IDEs nichts über die DSL und boten deshalb auch keine Unterstützung (Codevervollständigung, spezifische Fehlerüberprüfung usw.). MPS ist da anders: Sie können das MPS-Framework mit seinen auf Sprachentwicklung spezialisierten DSLs nutzen, um Spracherweiterungen zu definieren. Die IDE weiß dann von den DSLs, und das System stellt vollständige IDE-Unterstützung für die domänenspezifischen eingebetteten Sprachen zur Verfügung.
Der Begriff sprachorientierte Programmierung wurde von Sergey Dmitriev in seinem 2004 erschienenen Artikel Language-Oriented Programming: The Next Programming Paradigm (Sprachorientierte Programmierung: das nächste Paradigma der Programmierung) geprägt. Dmitriev war Gründer und erster CEO von JetBrains und ist der „Vater“ von MPS. Andere haben ähnliche Ansätze entwickelt, meist unter anderen Namen. Ein Beispiel ist Charles Simonyi und sein Ansatz der „intentionalen Programmierung“; Martin Fowler hat seinen Ansatz in seinem 2005 erschienenen Artikel Language Workbenches: The Killer-App for Domain Specific Languages? (Language-Workbenches: Die Killer-Anwendung für domänenspezifische Sprachen?) beschrieben.
Die Kerngedanke hierbei ist, dass wir nicht nur eine einzige Sprache beim Entwickeln von Software verwenden, sondern immer auf die Sprachen zurückgreifen, die am besten für die jeweilige Aufgabe geeignet sind. Im Kontrast zu Polyglot Programming, was oberflächlich gesehen eine ähnliche Herangehensweise verfolgt, werden Entwickler beim Language-Oriented Programming explizit ermuntert, ihre eigenen DSLs zu erstellen oder bestehende Sprachen im Rahmen dieser Idee mit domänenspezifischen Konzepten zu erweitern. Language Workbenches wie MPS sind hierbei ein wichtiger Bestandteil des sprachorientierten Ansatzes und machen ihn erst möglich.
Mit MPS können Sie für jede neue Sprache einen eigenen Editor festlegen, um die Verwendung von DSLs zu vereinfachen. Selbst Domänenexperten, die nicht mit dem traditionellen Programmieren vertraut sind, können mühelos mit MPS arbeiten und domänenspezifische Sprachen nutzen, die unter Berücksichtigung ihrer eigenen, domänenspezifischen Terminologie entwickelt wurden.
Das folgende Video zeigt ein Beispiel für eine interaktive Sprachantwort (Interactive Voice Response, IVR), die mit MPS erstellt wurde. Diese DSL richtet sich an Personen ohne technischen Hintergrund, und die Benutzererfahrung wurde dementsprechend gestaltet.