Eine Regel ist "Behandle Code-Zeilen wie Sätze." Ein Satz ist dabei ein vollständig abgeschlossener Gedanke. Das sollte dazu führen, dass man den Code besser und flüssiger lesen kann. Lesbarkeit ist wichtig: Man schreibt Code nur einmal, aber typischerweise wird der Code 2,5 mal gelesen. EIn Beispiel wäre Car,describedAs().insulated().length(50) etc. Wenn man einen Methoden-Aufruf pro Zeile schreibt, wird das übersichtlich. Beispiel eliminiert man dabei die Setter und Getter (was aber zum Beispiel beim IDE-Support meiner Meinung nach zu einem Problem führt). Wenn man hier den Trick nutzt, dass das Objekt verschiedene Interfaces anbietet, so kann man dadurch die Methoden auf bestimmte Stellen einschränken. jMock soll dadurch sehr einfach benutzbar sein, weil man mit der Code Completion durch das Schreiben des Codes gut geleitet wird. Dann gab es ein Beispiel aus Groovy, bei dem man die vorhandenen Java-Klassen wie Date und Calendar eine hübsche API hinzugefügt hat. Ihrer Meinung nach sind XML-Dokumente ein Ergebnis davon, dass die Implementierung einer DSL mit Java nicht so einfach wie mit XML ist. Das ist ihrer Meinung nach eine DSL. Allerdings ist das XML dann nicht sehr lesbar - aber leicht zu parsen. Was bedeutet, dass man sie nicht einem Endanwender zeigen will.
DSLs kann man bauen mit Antlr, Yacc (JFlex/CUP), JavaCC oder SableCC. Interessanterweise fehlen hier die typischen Code-Generatoren wie Open ArchitectureWare, warum auch immer. Vor allem, weil die vorhandenen Werkzeuge laut Martin schwer zu erlernen sind. Seine Empfehlung ist Antlr, weil es dazu ein Buch und auch Tool-Support gibt.
Internal DSLs haben den Vorteil, dass man die volle Mächtigkeit der unterliegenden Sprache hat. Nachteil: Man muss eine Sprache mit Klammern benutzen, was Laien schwer zu vermitteln ist. Und man ist durch die Syntax und Semantik der Sprache eingeschränkt. External DSLs - also DSLs mit Generator - benötigen einen aufwändigen Translator und man hat keine Support für die Basis-Sprache.
Language Workbenches entstehen: Zum Beispiel von Intentional Software von Chares Simnonyi, Ex-Microsoft, Excel und Word-Projektleiter und Weltraum-Tourist. Dann gibt es Software Factories von Microsoft und die JetBrains-Ideen wie MPS von den Machern von intelliJ. Dieses neue Werkzeug macht es möglich, den Abstract Syntax Tree zu editieren. Die editierbare Repräsentation ist eine Projektion der abstrakten Repräsentation.
Aber entstehen dadurch nicht eine Sprache-Kakaphonie? Es ist genauso wie bei Framework und generell: Wenn die Abtraktion in der DSL nicht stimmt, dann wird das kompliziert. Außerdem muss man eh was lernen und es ist nur eine dünne Abstraktion über Frameworks. Meiner Meinung nach ist das nicht vollständig richtig, denn die jeweiligen Frameworks waren ein Problem für die Einarbeitung neuer Mitarbeiter.
Ziel ist es, Code zu schreiben, die ein Analyst lesen kann, aber nicht schreiben können muss. Technologien wie COBOL oder auch SQL; die dazu führen, dass man Code von einem Anwender schreiben lassen kann, haben das jedenfalls nicht geschafft.
Dieser Ansatz sehen sie als ein Wettbewerbsvorteil und möglicherweise als das nächste große DIng nach OOP.
Der Talk war recht interessant und zeigt, dass man sich wieder Gedanken über Sprachen macht. Inhaltlich gab es einige interessante Aspekt, aber DSLs sind ja schon länger ein Thema. Interessant ist eher, dass Martin Fowler und Thoughtworks sich so intensiv um das Thema kümmern. Sie sind auch sonst auf der Konferenz sehr präsent. ¶ 12:58
