Christopher Spies hat geschrieben:
wird "Deine kleine Skriptsprache" denn Turing-vollständig sein?
Ist kein Design-Kriterium. Könnte höchstens als Nebeneigenschaft herauskommen, was ich bezweifle.
Warum verwendest Du nicht eine existierende Skriptsprache, oder ein passendes Tool Deines Arbeitgebers?
Viel zu komplex, viel zu viel Overhead, viel zu viel Arbeit, um an meine Bedürfnisse anzupassen.
In den beiden von mir besuchten Softwaresysteme-Vorlesungen jedenfalls wurden zwar Unit-Tests (mit JUnit) behandelt, aber vom Einsatz von Skriptsprachen war da keine Rede, schon gar nicht von "hausgemachten" Interpretern.
Unit-Testen ist ja eigentlich eine Philosophie, keine Testumgebung. Die Testfälle muss man schon noch selber entwickeln. Und die Umgebung, in denen sie ablaufen können, auch. Elementare Tests kann ich mit dem Unit-Mechanismus ganz einfach erstellen (C# ist auch die Sprache der Tests), mit wenigen Zeilen pro Testfall. Aber natürlich gibt es auch komplexere Tests, Abläufe im Zusammenhang testen. Was ist denn die typische Funktionsweise eines Stellwerks? Doch eine geordnete Sequenz von Handlungen. Im Original schwingt man Hebel und betätigt Tasten, auf einer Bedienoberfläche simuliert man dies digital. Aber letztlich ist es ein "Programm". Und es gibt mehrere Programme, für den nächsten Zug ein anderes. Natürlich könnte ich für jedes der zu testenden "Programme" einen Testfall schreiben. Und dann jedesmal den Source-Code meiner Testfälle ändern, wenn ich es etwas anders haben will. Ist aufwändig. Vor allem, weil sich dies durch die gesamte Projektlaufzeit ziehen wird. So ein paar Zielen externer Script-Text erscheinen da deutlich beherrschbarer.
Mein Standpunkt ist eigentlich eher, dass man es soweit nur irgend möglich vermeiden soll, irgendwelche Utilities selbst zu basteln, und stattdessen fertige Lösungen verwenden soll -- daher auch meine Frage nach existierenden Skriptsprachen.
.Net (oder Java) bietet etwas ganz besonderes: Reflection - die Möglichkeit der Analyse des existierendes Codes, und die dynamische Nutzung dieses Codes, zur Laufzeit. Für mein Beispiel oben vielleicht so: "Suche eine Klassendefinition namens
Block. Finde dazu eine Methode namens
vorblocken, die einen Parameter und diesen vom Typ
string erwartet. Instantiiere ein Objekt der Klasse und rufe besagte Methode auf." Wenige Zeilen C#-Code. Man muss aber irgendwie die ganzen Text-Konstanten übergeben. Dazu will ich meine Skriptsprache haben, die auch der Benutzer lesen kann.
Vor allem ist mir nicht klar, wozu man überhaupt eine Skriptsprache braucht...
Vielleicht wurde es klarer. Grammatik ist auch nur deswegen nötig, um eine saubere lexikalische Analyse zu ermöglichen, die ich mit OO effizient umsetzen kann.
Man muss dann die Testfälle in der Skriptsprache schreiben -- soll das schneller sein, als sie z.B. in Delphi zu programmieren?
Die Testfälle bleiben in C#. Sie binden die Skripte mit ein.
Die Entwicklungszeit für den Interpreter muss ja auch einkalkuliert werden.
In der Tat. Und deswegen habe auch eine Weile überlegt und dann erst mal Kernfunktion ausprobiert. Der Aufwand scheint beherrschbar, der OO sei Dank.
Wenn man das wirklich häufig braucht, warum sind solche Skriptsprachen dann nicht Teil des jeweiligen Test-Frameworks?
Gibt es. Diverse. Passen aber nicht zu meinem Problem. Anpassung zu aufwändig. Und ein wenig Spaß soll ja auch noch dabei sein.
Nix für ungut
Fragen nach Motivation und Aufwand sind aus meiner Sicht absolut berechtigt.