[Allegro] Flex-Jobs, OpenSource und Softwaretechnologie

[Thomas Berger]

Lieber Herr Eversberg, lieber Herr Eger,

>>> nicht mit dem $OPTS-Overhead. So etwas braucht zumindest eine wirklich
>>> unabweisbare Rechtfertigung, sonst nenne ich das l'art pour l'art.
>>
>> Ist die bessere Funktionalität und Wartbarkeit kein solcher Grund?
>>
> Die ist, wenn ich nicht irre, nicht weniger gegeben, wenn man auf die
> $OPTS-Variablen verzichtet. Mir fehlt genau dafür der wirklich
> überzeugende Grund, denn sie machen doch ein nicht unerhebliches
> Volumen aus, was zusätzlich überblickt, beherrscht und gewartet sein will, und
> es sind doch nur Synonyme, weiter nichts. Entweder die
> Variablen gleich so nennen oder mit $ARGV arbeiten, und bessere
> Funktionalität kann ich da keine erblicken.

Das ist alles schon eineinhalb Jahre her oder noch laenger, so genau
erinnere ich mich nicht. Ich hatte halt den Anspruch, alle Feinheiten
der Aufrufzeile, also z.B. mehrfache -e-Schalter, die ja in sich
wiederum in Parameterdatei und Ausgabedatei binnenstrukturiert sind
nebst "verbindendem" Steuerzeichen, und den Fallback ins Environment
verarbeitbar zu machen.

Wie immer stellte sich dann schnell heraus, dass das alles nicht so
trivial ist, zumal ja auch manchmal etwas in Anfuehrungszeichen
eingeschlossen sein kann, wie etwa bei den -U-Schaltern fuer die
Vorbesetzung von Anwendervariablen. D.h. etwas simplistisches wie
var #ucl(b" -U")
ins #ucL
wird irgendwann nicht funktionieren, und fallweiser Eingriff in
Skripte ist fuer mich nie eine Option.

Weil ich gleichzeitig eine Ueberarbeitung von srch.job und update.job
vorbereitete, und mir ausserdem bekannt war, dass in fast allen
Programmiersprachen irgendwann Libraries fuer "Option processing"
entstanden sind, habe ich mich bemueht, den Code abzukapseln und
wenn moeglich sogar auszulagern. Dazu gehoeren gerade in der Flex-
Sprache auch Ueberlegungen zur "Pollution", d.h. Anwendervariable
sind eigentlich generell tabu und alle $-Variablen sollten irgendwie
aehnlich heissen.

Eigentlich auch zu meiner eigenen Ueberraschung hat das Ergebnis
dann zwei Schichten gehabt: Einerseits das *Parsen* der Kommandozeile
$ARGV und andererseits die Aufteilung der darin vorliegenden Schalter
in Optionen im Sinne von Argumenten fuer die Hauptprodzedur (und da
ich da nichts neues erfinden wollte, habe ich dafuer die Namen aus der
a99.ini genutzt und bin dafuer schon letztes Jahr von Ihnen gescholten
worden), d.h. z.B. auf Schalterebene gibt es ein mehrfach belegtes
"$ARGV:e" (mit eindeutigem Trenner), auf Ebene der Optionen dann
"$OPTS.ExportParameter:1", "$OPTS.ExportParameter:2", $OPTS.OutputFile1
etc.

Weil das dann schon viele Zeilen hatte, war es umso wichtiger, noch
mehr Zeilen einzubauen, damit (ueber Optionen, also $OPTS steuerbar),
diese ganzen Mechanismen (sowie auch die eigentlichen Funktionen srch
und update) eine vernuenftige eingebaute Diagnostik haben (dazu zaehle
ich auch das Mitzaehlen, wie es SRCH und UPDATE als Executables auch
kennen). Weil ich nicht der Ansicht bin "wer alles richtig macht, den
wird das Programm durch korrekte Arbeit belohnen" bzw. der Umkehrung
"wenn das Programm crasht, hat der Operator etwas falsch gemacht. Selbst
schuld." faellt das bei mir etwas aufwendiger aus als in Braunschweig.
Natuerlich erhoeht das die Komplexitaet und die Wahrscheinlichkeit von
Bugs, und die Zusatzlogik fuers fallweise Auswerfen oder Unterdruecken von
Meldungen *ist* stellenweise umfangreicher als die eigentliche Ablauflogik.
(siehe auch < http://en.wikipedia.org/wiki/Unusual_software_bug >, speziell
den "Heisenbug").

Aber ich denke, es muss so sein, denn der Regelfall ist, dass ein
Bearbeiter/Operateur anhand von Meldungen sich ein erstes Bild ueber die
Korrektheit des Ablaufs macht, *aussagekraeftige* Meldungen versetzen
ihn in die Lage, die Ursachen abzustellen ("BUMM!" gehoert nicht dazu).
Dass die Jobs lesbar sind, hat fuer mich erst zweite Prioritaet, bzw.
faellt bei mir unter ein allgemeineres Kriterium von Wartbarkeit: [Von
Microsoft wurde kolportiert, dass sie Modularisierung nicht wegen der
Nachnutzbarkeit (Wette auf die Zukunft) betreiben, sondern eigentlich
aus genau umgekehrter Motivation: Wenn eine Komponente nicht funktioniert,
wird gar nicht versucht, den Code zu lesen und einen Fehler zu finden,
sondern im Zweifel die Sache neu programmiert und ausgetauscht: Dank
Modularisierung geht das.] Allegro-Steuerdateien sind ja unendlich
langlebig (noch heute sind gewiss irgendwo um 1990 mit "DOS-Compilern"
erzeugte Programme im Einsatz, die irgendwie PRESTO aufrufen und grosse
Teile von d-wrtf.apr beruhen auf Code, der aelter ist als 20 Jahre),
selbst wenn *ich* etwas geschrieben habe, heisst das nicht, dass ich
in 10 Jahren damit spontan klar komme, wenn ich ploetzlich einen Fehler
darin suchen muss. Ich hoffe natuerlich, dass auch jemand anderes
beim Code-Lesen von dieser Versicherung gegen zukuenftigen Arbeits-
aufwand profitiert, Prioritaet hat es allerdings nicht (denn es ist
mir wie gesagt wichtiger, dass hundert Anwender nie in den Code schauen
muessen, als dass zehn Anwendern das mehr oder weniger leicht faellt).

Das nur als Erlaeuterung, warum die Dinge so sind wie sie sind. Und
sie bleiben natuerlich so, wie sie sind: Selbst wenn ich nicht der
Meinung waere, dass die von mir gewaehlten Wege Vorteile gegenueber
den nicht gewaehlten haben, warum sollte ich meinen Code freiwillig
umschreiben, damit er den aesthetischen oder anderen Vorstellungen
Dritter entgegenkommt? Doch hoechstens dann, wenn man mich davon
ueberzeugen kann, dass das eine Verbesserung darstellt, etwa weil
ein konkreter oder ein potenzieller Bug aufgetaucht ist. Oder weil
*zu wenig* Redundanz in Variablennamen ist, die Wartbarkeit also
durch Verwechslungen gefaehrdet sein koennte. Ich bin der Ueberzeugung,
dass es einen Zusammenhang zwischen "Aesthetik" (des Codes) und
"Design" (der Anwendung) gibt, und werde mich Argumenten aus dem
Bereich nicht verschliessen. Substantiell war aber bislang nur, dass
"lange Variablennamen" und "viele Zeilen" negativen Einfluss auf das
Laufzeitverhalten haben, durch Messungen erhaertete Zahlen dazu kenne
ich nicht, die Aussage kann aber durchaus stimmen, offenbart m.E. dann
aber nur Design-Probleme der Flex-Engine ;-)

viele Gruesse
Thomas Berger


viele Gruesse
Thomas Bergre