Closed mikesperber closed 2 years ago
Siehe erstmal die obigen Commits bei dem es ums grundsätzliche geht.
Zu den einzelnen Punkten:
"Was kann man als Basis für eine DSL verwenden?": Dazu findet sich in vielen LZs was - es wird ausführlich auf die Möglichkeit eingebetteter DSLs hingewiesen, das Design als Library, mit Makros, mit diversen Tools.
"Was sind Beschränkungen dieser Umgebungen?" Das hängt von den konkret in der Schulung besprochenen Umgebungen bzw. Umgebungstypen ab. Siehe dazu #5, den wir separat bearbeiten.
"Gibt es unterschiedliches „Commitment" zu DSLs?" Ja, gibt es: Daß es ein Spektrum und damit auch einen graduellen Weg hin zur Einführung einer DSL gibt, spielt in jedem Abschnitt eine zentrale Rolle. Den allgemeinen Punkt haben wir jetzt mit dem obigen Commit auch nochmal in der Einführung prominent aufgeführt.
"Gibt es Kosten/Qualität/... Abwägungen?" Ja, dazu haben wir noch einen Punkt in das ersze Lernziel aufgenommen.
"Was sind Alternativen zu DSLs in Grenzfällen?" Die Frage ist in der Allgemeinheit unmöglich zu beantworten. Die offensichtliche Alternative ist, keine DSL zu machen. Generell ist die Lehrmeinung hinter dem Curriculum, daß man graduell vorgehen sollte, um den sinnvollsten und effizientesten Punkt im Spektrum zu treffen.
"Muss man immer neu entwickeln oder kann man auch Features einer GPL nutzen die man schon verwendet?" Nein, aber dazu finden sich zahlreiche Punkte im Curriculum, unter andem unter den Stichwörtern "embedded DSL", "library" und "macros"
"Welche eignen sich dafür?" Auch das wird im Curriculum prinzipiell behandelt: Sprachen mit Makros, First-Class-Continuations, Effektsystemen, stratfiziertem Syntax-Design. Wir werden dazu aber noch konkreter werden unter #5.
"Welche Inputs sind sinnvoll von Anforderungsseite? Wer sind Ansprechpartner für Begriffs/Konzept-Findung?" Die Antworten hier sind nicht anders als sonst im Software-Design, spezifisch im DDD. Es erschien uns nicht sinnvoll, das hier nochmal zu wiederholen.
"Wie geht man mit späteren Sprachänderungen systematisch um?" Wir haben ein neues LG 4-1 aufgenommen, wo das behandelt wird. Allerdings gehen wir nicht davon aus, daß dieses Thema grundsätzlich anders gelagert ist als sonst im Architekturdesign.
Vom Council:
Die drei Ziele des Moduls aus dem Abstract (Einsatzbereiche, Design, Einbettung) sind interessant. In einem Advanced Modul für Architekten sollten alle diese Themen auch in die Breite diskutiert werden, die Einsatzbereiche und Alternativen wären aus meiner Sicht besonders wichtig. Dieser Aspekt kommt über das gesamte Modul gesehen zu kurz.
Was kann man als Basis für eine DSL verwenden? Was sind Beschränkungen dieser Umgebungen? Gibt es unterschiedliches „Commitment" zu DSLs? Gibt es Kosten/Qualität/... Abwägungen? Was sind Alternativen zu DSLs in Grenzfällen? Muss man immer neu entwickeln oder kann man auch Features einer GPL nutzen die man schon verwendet? Welche eignen sich dafür? ...
All diese Fragen und einige mehr Richtung Umsetzung (Wie geht man im Design einer DSL gut vor? Welche Inputs sind sinnvoll von Anforderungsseite? Wer sind Ansprechpartner für Begriffs/Konzept-Findung? Wie geht man mit späteren Sprachänderungen systematisch um?) sollten einen großen/größeren Teil des Moduls ausmachen. Und falls sie in den noch nicht definierten Teil des Moduls fallen sollten: Nach 4-Quadranten-Modell sollten sie vor die Umsetzung und das Konkrete Design rutschen.