[Allegro] "acon -j srch.job" als Ersatz fuer SRCH.EXE

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> ich hatte auch untersucht, ob einige der gaengigen "automatischen"
>> Dokumentationssysteme (Doxygen, ROBODOC, und 50 weitere) eingesetzt
>> werden
>> koennen,
> Da wäre ich gegen, denn die erzwingen alle die Einpflanzung noch einer
> weiteren Logik, Syntax und Semantik, die ebenfalls gepflegt,
> verstanden und genutzt werden will - kostet alles extra Zeit und
> Aufmerksamkeit, der Effekt ist aber eher sporadisch wirklich nützlich.

Hinweise auf Aufrufschalter, Dateiversion, "known Bugs" und vieles
andere mehr gehoeren aber einfach in solche (Quell)-Dateien hinein.
Und wenn das halbwegs einheitlich passiert, kostet es sogar weniger
Aufmerksamkeit, weil man dann nach diesen Informationen nicht suchen
muss, sondern weiss wo sie stehen. Passiert das dann sogar noch
halbwegs ernsthaft, weiss man sogar, dass die Informationen stimmen.

Diese automatischen Dokumentationssysteme versuchen dann nur noch,
aus diesen "halbwegs einheitlichen" Kommentaren eine schoene
HTML-Seite zu machen.

Sie koennen ja einen Compiler schreiben, der Kommentare entfernt und
auch sonst kuerzt (bei Spammern beliebt sind ja z.B. Obfuskatoren,
die alle Variablen in eine zufaellige kuerzestmoegliche Form umbenennen).
Bei den freien Variablen sollte es auch keinen Unterschied machen,
wie lang ihre Namen sind (sofern weniger als 2048 Zeichen)


>> ... Ich schlage daher
>> vor, dass Sie sich an zu langen Variablennamen und redundaten Kommentaren
>> einfach nicht stoeren ...
> 
> 12 Bytes for a name ought to be enough for anybody, um einen bekannten
> Entwickler mal zu paraphrasieren. Und unsere Jobs sind doch
> vergleichsweise winzige Gebilde, für die man nicht gleich großkalibrige
> Geschütze auffahren muß wie bei Java-Konglomeraten.
> 
> Und nicht vertraute Strukturen suggerieren durch [...] oder {...}, wo es
> sie in Wahrheit nicht gibt. Fehlgeleitete Intuition ist kontraproduktiv.

Wie gesagt, ich hatte diese Art der Suggestion fuer offizioes gehalten.
Mir waere natuerlich auch lieber, wenn die Job-Sprache ausser String
(und den singularen iz und iZ) noch andere Datenstrukturen kennen wuerde.

Jedenfalls geht es darum, eine verstaendliche Syntax zu erfinden fuer das,
was man in anderen Sprachen ueber einen Hash oder eine Objektmethode etc.
realisieren wuerde: Wenn $ARGV{-s} ein zu suggestiver Name fuer das
entsprechende Skalar ist, waere dann $ARGV#-s besser (oder sollte man
besser speziell "#" vermeiden?). Zeichen, die mit Operatoren verwechselt
werden koennen, moechte ich lieber vermeiden ('+', '*', '-', '%', '/'),
wegen "-" im "key" faende ich auch $ARGV->-s oder $ARGV_-s oder $ARGV.-s
nicht sonderlich gelungen. Buchstaben hingegen koennten in anderen Faellen
mit Inhaltszeichen verwechselt werden: Letztlich laeuft es doch stets
auf irgendeine Klammerung hinaus und da ist dann die Frage, ob man bewusst
Klammern erfinden koennte oder sollte, die so befremdlich wirken, dass niemandem
etwas falsches suggeriert wird: $ARGV#-s# oder $ARGV|-s| oder $ARGV))-s((
oder $ARGV:X:-s: ...

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkwXWYwACgkQYhMlmJ6W47OtkwP/b6LmvJsv70h3Jryr7lNQnxXF
ltZhZ9EeP0JpHFJ2zI0WI/XXujU7xXjG/TttQ7Az1+Z3tJG3CtbjIDSIWNQpem7M
7c9IigBtwuOhEfDdyH1XosZX6kVeWQZ3/k5LVvutjqB3IDzFxyueXydmLyci67Pm
EJBWJSPv5/7VBbtfk8E=
=RrnE
-----END PGP SIGNATURE-----