In den letzten Emails ging es darum, wozu man eine Anwendungs-spezifische Sprachen (Domain Specific Languages) gebrauchen kann. Wenn man eine eigene (wenn auch kleine) Programmiersprache erfindet, bekommt man zwar gute Lesbarkeit für Nicht-Programmierer, muss aber auf der anderen Seite viel Programmierarbeit für die Interpretation dieser Sprache aufwenden. Da bietet es sich an, einfach die Haupt-Programmiersprache möglichst lesbar zu verwenden (wie wir es für Ruby gezeigt haben).

Manchmal geht es auch mit noch weniger Aufwand, indem man auf ein gängiges Datenformat aufsetzt. Im einfachsten Fall lässt sich die Spezifikation in Tabellenform pressen. So macht es etwa das Test- und Kommunikationstool Fitnesse. Anwender können einen Akzeptanztest dann zum Beispiel so schreiben:

In den Zeilen der Tabelle stehen einzelne Beispiele mit dem jeweils erwarteten Ergebnis. Man kann mehrere solche Tabellen in einem Wiki-Dokument mit erklärendem Text kombinieren. Ein bisschen “glue code” sorgt dann dafür, dass die Beispiele in echte Akzeptanztests übersetzt werden. Den glue code zu schreiben ist wesentlich leichter, als z.B. einen Parser für eine universelle “Test-Sprache” zu implementieren.

Wenn Tabellen zu unflexibel sind, kann man noch auf Formate wie JSON oder YAML setzen, dort gibt es Zahlen, Texte, Listen und Dictionaries (Schlüssel-Wert-Paare) als Bausteine. Daraus kann man schon recht komplexe Dokumente zusammensetzen, die wiederum einfach zu interpretieren sind (weil etwa der JSON-Parser einfach nachgenutzt werden kann).

Hier ist ein Beispiel aus Vega-Lite, einem System für Visualisierungen. Das Diagramm zeigt den mittleren Niederschlag für Seattle, es wird mit diesen wenigen Zeilen spezifiziert:

So ziemlich alles, was man sich an interaktiven Diagrammen denken kann, lässt sich in Vega-Lite ausdrücken. Der Quelltext ist in JSON, die Anführungszeichen und geschweiften Klammern sind vielleicht etwas gewöhnungsbedürftig. Aber der Inhalt sollte doch ziemlich leicht verständlich sein, weil auch hier wieder spezifiziert (“deklariert”) wird, was zu tun ist, während das “Wie” der Software überlassen bleibt.

Matthias Berth