[Allegro] Flex-Jobs, OpenSource und Softwaretechnologie

[Anando Eger]

Hallo Herr Eversberg,

da ich dieses Thema sehr wichtig finde, möchte ich es trotz
meiner begrenzten Zeit ausdiskutieren:

Sie schrieben u.a.:

> Am 20.12.2011 09:21, schrieb Anando Eger:
> >
> > Was spricht dagegen, beispielsweise Herrn Bergers update.job
> > in die Standard-Auslieferungsversion von Allegro zu übernehmen?
> >
> Hatte ich eigentlich schon mal zu begründen versucht, aber ok:
> 
> Zuerst brauchen wir eine plausible Erklärung, warum die zusätzlichen 
> Variablen $OPTS.* nötig sind, wenn sie nichts anderes umfassen und
> darstellen als was in $ARGV:* schon steht, nur mit anderen, viel
> längeren Benennungen. Das braucht, finde ich, eine solide
> Rechtfertigung, dazu reicht mir "heutige softwaretechnogische
> Standards" nicht aus, da fehlt mir das Augenmaß. So viele Zeilen mehr
> als wirklich nötig, das kann man nicht ernsthaft elegant nennen.

Ist "elegant" eine relevante Eigenschaft für die Gestaltung von 
Quelltexten? Nach meiner (und nicht nur meiner) Meinung ist die 
Verwendung ausdrucksstarker Bezeichner und die saubere Gestaltung
von Abstraktionsebenen viel wichtiger.

> Bedenken Sie doch, daß FLEX-Jobs immer sehr begrenzte Objekte sind,
> nicht zu vergleichen mit wirklichen Programmen wie a99 oder acon
> selbst. 

Sie haben diese "Sprache" geschaffen - und jetzt wollen Sie, dass
man sie nicht richtig benutzt?
Gerade diese Flexsprache ist doch, bei allen Mängeln die sie hat,
DAS Alleinstellungsmerkmal von allegro, oder? Wenn das anders wäre,
würden wir uns hier nicht unterhalten.
Wie Sie wissen, bin ich selbst mit den Flexen öfter an
die Längenbegrenzung für die Flex-Quelltexte gestoßen. Wenn man
die Prinzipien Kapselung und Wiederverwendbarkeit bei der Programmierung
umsetzt, sammelt sich halt was an - was man für weitere, oft komplexe
Aufgabenstellungen sehr gut und ZEITSPAREND wiederverwenden kann.

> Und die Variablen haben gerade bei acon keine Lebenszeit über
> das Ende des Jobs hinaus! Wenn man so etwas dann so anlegt wie ein
> enormes Java-Klassengebilde, dann ist das überdimensioniert und fordert
> dem, der es rezipieren will, unnötig viel Zeit ab allein für's Lesen
> und dann auch für's Schreiben, wenn man die Variablen dann
> verwendet. 

Ich kann Herrn Bergers Flexe viel schneller lesen und verstehen,
als die, die z.B. für alf oder die anderen Zusatzmodule mitgeliefert 
werden.

Klar ist der Zeitbedarf für's Schreiben größer, aber was meinen Sie, 
weshalb auch ich diesen Mehraufwand gern in Kauf nehme?
Doch nicht, um mich selbst zu beweihräuchern!!! Sondern um Zeit zu 
SPAREN!
Wenn das nicht so wäre müßten meine Kunden für weniger Funktionalität 
mehr Geld bezahlen oder ich würde weniger verdienen.

> Na gut, die Namen sind "sprechend", aber eine Liste dafür
> braucht man trotzdem zum Nachschauen und Abschreiben, allein wegen
> der Gross-Kleinschreibung und Sonderzeichen - je länger ein Name,
> umso mehr Chancen zum Verschreiben.

Also ich kann mir die Bedeutung von dreibuchstabigen Kürzeln als
Bezeichner viel schlechter merken.

>  Dann tun's die $ARGV-Namen genauso.

Wofür? Herr Berger hat sicher einen Grund, weshalb er eine weitere
Abstraktiopnsschicht eingebaut hat. Das würde ich in diesem Fall
ganz ihm überlassen. Und es funktioniert doch, oder?
 
> Ich würde, summa summarum, Bergers update.job gerne übernehmen, aber
> 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?

Viele Grüße
Anando Eger

---------------------------------------------------------------------
Anando Eger Datenverarbeitung
Herr Dipl.-Ing. Anando Eger
Gustav-Voigt-Str. 24
01156 Dresden
Tel.: +49 (0)351 454 1236  http://www.aneg-dv.de
Fax: +49 (0)351 454 1238  mailto:a.eger at aneg-dv.de
---------------------------------------------------------------------