[Allegro] FLEX: Kurze oder lange Befehle?

[Bernhard Eversberg]

Kollegen Lehmann und Fischer schrieben:
> > befehle sollten in einer eindeutigen art und weise geschrieben
> > werden. wenn ich dateien auf deren befehlsinhalt kontrolliere, dann
> > muss ich eben4 schreibweisen berücksichtigen? geht nicht!

>  Ich möchte mich diesem Wunsch anschließen und in dahingehend
>  erweitern, dass in Skripten (Job, Flex) Befehle grundsätzlich
>  ausgeschrieben werden sollten. Wenn man schnell einen Aufruf
>  losschickt, kann man von mir aus gerne abkürzen, aber in
>  ausgelieferten Dateien würde ich der Lesbarkeit wegen den vollen Text
>  vorziehen.


Da ist was dran, das klingt natürlich plausibel.
Es erschließt sich nicht leicht und intuitiv, warum FLEX so ist wie
es ist. Deshalb ein paar Bemerkungen zu den Hintergründen, die sich
in der Doku so nicht niedergeschlagen haben.

1. Die offizielle Form der Befehle ist die dreibuchstabige (das
Trigramm oder Triliteral). Nur die wird vom Programm beachtet, der
Rest nicht. Der Rest ist eine Konzession an Verständlichkeit und
Merkfähigkeit, aber redundant.
Sie können statt "var" auch "variable" schreiben! Statt "write" auch
"writethis", statt "eval" auch "evaluate" oder "evaluiere" oder barsch
"eva", statt "end" auch unmißverständlich "ende-des-programms", statt
"aresqa" auch "aregano", statt "perform" auch "perxyz" - alles wurscht.
(Für "export" gibt es, das ist aber eine historisch bedingte Ausnahme,
drei gleichwertige Trigramme: "exp", "xpo" und "dow".)
Die in der Doku stehende Vollform wird vom Programm in keiner Weise
bevorzugt oder honoriert. Es zählen stets nur die ersten 3 Zeichen, der
Rest - wie lang auch immer - wird ignoriert. Ausnahmen sind nur "erase"
und "include", auf daß es damit kein Vertun gebe, denn "erase" ist
ja riskant und muß deshalb mit Bedacht ausgesprochen werden, und
"include" ist kein Befehl, sondern eine Direktive.
Die ersten drei Buchstaben, kurz gesagt, sind eindeutig. Das ist ein
Designgrundsatz und wird bei Einführung neuer Befehle streng beachtet.
Sie können sich also gefahrlos eigene Langfassungen überlegen -
diejenigen der Doku sind nur Empfehlungen.

2. FLEX ist keine kompilierende, sondern eine interpretierende
"Sprache". Das ist ein ganz großer Unterschied, vor allem wenn es
um Schleifen geht: bei jedem Durchlauf muß jeder Befehl neu
interpretiert werden: neu eingelesen, neu erkannt, neu ausgeführt,
und es macht bei 1 Million Durchläufen schon spürbar was aus, wenn
jeweils doppelt so viele oder mehr Zeichen zu verarbeiten sind.
Kommt doch nicht drauf an bei den Prozessoren heutzutage?
Genau diesen Bequemlichkeitsreflex, so menschlich er ist, haben wir
beim Entwickeln stets konsequent gemieden. Das Programm würde
sirupähnlich kriechen, hätten wir ihm stets nachgegeben, weil sich
die Entschleunigungen summieren oder multipli-, wenn nicht gar potenzieren.


WENN wir nun also auf 100% Eindeutigkeit der Befehle umstellen wollten,
käme dafür aus mehr als einem Grund nur die triliterale Form in
Betracht. Die Überlegung ist aber müßig, denn die Zeit für ein solches
Unternehmen fehlt uns natürlich. Dies wäre allerdings ein Betätigungs-
feld im Sinne von OpenSource! Durchaus denkbar ist ein Perl-Skript, um
zumindest die gängigsten Befehle zu normieren. Denkbar wäre, darüber
weit hinausgehend, ein Editor mit der Fähigkeit, die Befehlswörter
auf Knopfdruck zur Vollform zu erweitern statt sie nur farblich
hervorzuheben. Wer packt's an? Aber der funktionale Gewinn wäre
in jedem Fall exakt Null.

Nur ganz nebenbei: Man könnte einwenden, daß Freiheit eine Kategorie
sei, die auf diesem Felde eher kontraproduktiv wirke. Dies  wurde
auch gegen die neue Variantenfülle der sog. "Rechtschreibreform" ins
Feld geführt. Deren Befürworter wollten das jedoch nicht akzeptieren,
sie wollten eine Lockerung der herkömmlichen, strikten Präskription
des Wörterbuchs und sahen das als Erleichterung. Anscheinend ist
diese, man lese nur Zeitungen oder Schulaufsätze, mehrheitlich
aufgegriffen worden und kann somit als Mainstream gelten. Und ohne Not
sich solchen Megatrends zu verschließen, na ich weiß nicht ... würde
das nicht heißen, einer Erleichterung für die Maschine mehr Gewicht
zu geben als einer solchen für den Menschen? Würde damit nicht auch
das menschliche Potential, mit Vieldeutigkeit umzugehen, was ihn über
die Maschine weit hinaushebt, negiert und brachliegen gelassen?
Ich fürchte, es bleiben nagende Zweifel.


B.Eversberg



-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://bibservices.biblio.etc.tu-bs.de/pipermail/allegro/attachments/20110712/58ec0294/attachment.html>