[Tustep-Liste] Quo vadis? - Ordnungsruf!

Do Jun 17 19:48:32 CEST 2004

Liebe Freunde, Kollegen, Diskussionsteilnehmer,

die lebhafte Debatte um das von Herrn Giacomazzi
losgetretene "Quo vadis?" finde ich im Grunde ganz
prima. Je mehr Perspektiven sich eroeffnen, desto
besser; eventueller Unfug sollte in einer sachkun-
digen Argumentation leicht wegzufiltern sein, und
der ueberstehende Rest dem Fortschritt dienen. Da
ich weder von Ruby noch von Python etwas verstehe,
hatte ich eigentlich vor, mich entspannt zurueck-
zulehnen und den weiteren Gang der Ereignisse mit
Interesse zu verfolgen. Mein Standpunkt war dabei
der von Martin Glessgen, der prononciert von Herrn
Giacomazzi und Herrn Derkits forderte "Zeigt doch
mal, worin der besondere Wert einer solchen offe-
nen Schnittstelle bestehen koennte!"
  Einer solchen Aufforderung nachzukommen, ist zu-
gegebenermassen auf einem E-Mail-Forum nicht ein-
fach. Vielleicht verlohnte es, ein Kolloquium oder
gar einen Workshop zu veranstalten, auf dem die be-
teiligten Debattanten, vielleicht auch die Entwick-
ler, in unmittelbarer Rede, Gegenrede und Demon-
strationen ihre Standpunkte praezisieren und exem-
plifizieren koennten. Ich sage das aus dem einfach-
sten aller Gruende: Ich habe den Eindruck, dass es
um etwas Wichtiges geht, verstehe aber einen guten
Teil der aktuellen Debatte nicht - manches Grund-
saetzliche ebenso wie zahlreiche Implikationen -,
und ich weiss aus Gespraechen mit Kollegen, dass
ich nicht der einzige bin, dem es so geht. Erlau-
ben Sie mir, dafuer ein paar Beispiele zu geben.
   Einer der wichtigeren Kritikpunkte von Herrn
Giacomazzi ist etwa das TUSTEP-Dateiformat. Auf
http://www.giacomazzi.de/tustep/nummeriere.html
steht zu lesen:
  "Da TUSTEP-Dateien nur in TUSTEP lesbar sind
  (was man sich auf der Zunge zergehenlassen
  sollte), kann kein fremdes Programm die Seiten-
  und Zeilennummer von TUSTEP-Dateien ermitteln.
  Dagegen habe ich in "Quo vadis?" besonders pro-
  testiert."
Streiten wir uns nicht darueber, ob es nicht doch
moeglich ist, mit einem fremden Programm das TUSTEP-
Dateiformat zu lesen, denn die TUSTEP-Entwickler
machen m.W. kein Geheimnis aus dem Aufbau der In-
dizes. Streiten wir uns ausserdem nicht darueber,
dass es eine Kleinigkeit ist, TUSTEP-Daten nach
aussen, anderen Programmen, verfuegbar zu machen.
Grundsaetzlich verdient ein proprietaeres Datei-
format in der Tat Kritik, da sind wir sofort
d'accord. Aber gibt es denn eine Alternative?
Auf den Grossrechnern bestand (und besteht bis
heute) nicht der geringste Zweifel daran, dass
die *einzige* Moeglichkeit, grosse Dateien effi-
zient *und* sicher zu verwalten, in einem sog.
indexsequentiellen Dateiformat besteht. Fuer die,
die nicht wissen, was das ist: Es ist absurd zu
glauben, dass man Dateien in der Groesse von Dutzen-
den von Megabytes (in Trier werden fuer einzelne
Projekte auch schon Dateien weit ueber 1 GB Groesse
verarbeitet) als einfache Text-(SDF-)Dateien schnell
und sicher bearbeiten koennte: Eine punktuelle Aen-
derung in der Mitte der Datei wuerde jedesmal das
Speichern der Gesamtdatei oder das temporaere
Zwischenspeichern von Fragmenten der Gesamt-
datei erfordern - und was das an haarstraeubenden
Risiken birgt, weiss jeder TVA-Anwender, der ein-
mal pro Vierteljahr die unzaehligen temporaeren
Ueberreste seiner Programmabstuerze von der Platte
putzt. Der saubere, allgemein anerkannte und m.W.
nirgendwo in Frage gestellte Ausweg besteht eben
in indexsequentiellen Dateien: Dort wird genau der
Satz, der vom Anwender gerade veraendert wurde,
(und *nur* dieser) wieder in die Datei zurueck-
geschrieben, ggf. einfach ans Ende der Datei ge-
setzt. Damit die logisch richtige Abfolge der
Saetze gewahrt bleibt, sind die sog. Indizes
im Kopf der Datensaetze noetig, die Auskunft
darueber geben, an welche Stelle die Saetze hin-
gehoeren. Eben dies ist der Grund (und das Bau-
prinzip) des proprietaeren TUSTEP-Dateiformats.
Ich bin seit zwanzig Jahren an einem Rechenzen-
trum mit EDV in allen moeglichen Erscheinungs-
formen befasst - aber ich habe noch *niemals*
ein derart effizientes, performantes und zugleich
sicheres Dateiformat im Einsatz erlebt wie das
von TUSTEP. Ich fuege hinzu: mit grossem Abstand!
Frage in die Runde: Hat jemand andere Erfahrungen
gemacht? Wenn jemand eine gute Alternative vorwei-
sen kann - gerne wuerde ich sie mir ansehen und
mich ueber Besseres belehren lassen.
   Nicht unerwaehnt lassen will ich ferner die
mir lieb und teuer gewordene Seiten-/Zeilennum-
mer, die in TUSTEP (natuerlich) ueber die Indizes
des Dateiformats realisiert wird. Ich gehe davon
aus, dass auch die Kritiker des TUSTEP-Dateifor-
mats diese Seiten-/Zeilennumerierung schaetzen.
Aber wie zum Henker realisiert man diese unver-
zichtbare Hilfe, wenn man das TUSTEP-Dateiformat
zugunsten eines offenen Dateiformats aufgibt??
Etwa indem man die Numerierung in das Text-
feld selbst hineinschreibt? Das wird nie und
nimmer funktionieren: Man stelle sich nur vor,
was fuer ein Unheil ein unbedachtes Austausche,
ja sogar ein einzelner versehentlicher Tasten-
druck an der falschen Stelle in einer grossen
Datei anrichten kann! Nein, solche Verwaltungs-
informationen *muessen* unbedingt vom Text selbst
getrennt bleiben.
   Hinzu kommt ein Weiteres: Vor kurzem noch
stand als besonderer Wert des TUSTEP-Dateifor-
mats ganz hoch im Kurs, dass - egal auf welcher
Plattform die Daten erstellt wurden, egal auf
welchem Rechner, mit welcher Codepage, unter
welchem Betriebssystem und mit welchem Programm
(und welcher Version davon) - *alle* Daten und
Sonderzeichen immer und unter allen Bedingungen
eindeutig interpretierbar waren. Bei SDF-Dateien
hingegen gibt es nur die eine Garantie, dass naem-
lich das Tohuwabohu beim Plattformwechsel unaus-
weichlich vorprogrammiert ist - und bitte glau-
ben Sie mir, dass ich weiss, wovon ich rede,
denn ich habe schon viel Blut, Schweiss und
Traenen ueber danebengeratenen Konvertierungen
vergossen. XML und Unicode werden (vielleicht)
einmal mit dem ganzen Unheil aufraeumen, aber
die Realisierung und die Durchsetzung dieses
Utopias auf breiter Front werden noch eine Weile
auf sich warten lassen. Bis zu diesem Zeitpunkt
besitzt das TUSTEP-Dateiformat einen Qualitaets-
vorsprung, der nicht hoch genug eingeschaetzt
werden kann. Dass diese gewaltigen Vorteile
mit kleineren Komforteinbussen bei der Ueber-
gabe der Daten an fremde Programme erkauft
werden (naja, man muss halt entweder ein #u
oder einfach die Zwischenablage bemuehen),
laesst sich m.E. verschmerzen. - Auch hier die
Frage an die Runde: Sieht das jemand anders,
oder sieht jemand gar die Chance, die hier
skizzierten Vorteile des TUSTEP-Dateiformats
mit einem offenen Dateiformat zu verheiraten?

Aber lassen wir das Dateiformat beiseite, inter-
essanter scheinen mir ohnehin die Vorteile zu sein,
welche die TUSTEP-Gemeinde aus den geforderten of-
fenen Schnittstellen zu gewaertigen hat. Das ist
der Punkt, ueber den ich gerne mehr und Genaueres
in Erfahrung braechte. Auf die Bitte von Martin
Glessgen haben sowohl Herr Giacomazzi wie auch
Herr Derkits Beispiele gebracht, die viel Zu-
stimmung gefunden haben. Nichts liegt mir ferner,
als der Staenkerer sein, der aus Maekelsucht oder
aus ideologischer Verbohrtheit Kritik uebt, ich
will vielmehr nur den Finger darauf legen, dass
die Stossrichtung *aller* gebrachten Beispiele
vorderhand an einer wichtigen Erwartungshaltung
der weitaus meisten TUSTEP-Anwender vorbeizielt:
Die typische TUSTEP-User ist ein Fachwissenschaft-
ler, der an EDV nur soviel Interesse hat, wie er
mit ihrer Hilfe seine Probleme loesen oder deren
Loesung erleichtern kann. Es ist deshalb nur fol-
gerichtig, dass er weniger daran interessiert
ist zu erfahren, welche Aufgaben er *ausser* mit
TUSTEP *auch noch* mit anderen Programmen erledi-
gen kann, als vielmehr, welche Aufgaben, die er
*nicht* mit TUSTEP bewaeltigen kann, durch die In-
tegration etwa von Skriptsprachen wie Python oder
Ruby nach TUSTEP loesbar werden. Es gab schon
vor knapp zwanzig Jahren Programmsysteme, die
einzelne TUSTEP-Leistungen ebenfalls boten - ich
erinnere an das Oxford Concordance Program (OCP),
den WordCruncher, Snobol, GNU-AWK, TACT, auch
die Regular Expressions von Unix als Konkurrenz
fuer das TUSTEP-eigene Pattern Matching, auch
TEX als Satzprogramm-Ersatz, auch den CET als
Satzprogramm-Ersatz fuer kritische Editionen.
Es waren teilweise recht gute Programme darun-
ter, aber die TUSTEP-Anwender vermochten sie aus
einem simplen Grund nicht vom Hocker zu reissen:
Sie boten nichts, was als Leistung nicht auch in
TUSTEP erreichbar war - und ihr wohl gravierend-
ster Nachteil war, dass sie kein System bildeten.
Auf letzteres werde ich gleich noch einmal zurueck-
kommen, moechte aber zuvoerderst meine Verstaendnis-
schwierigkeiten an zwei Beispielen erlaeutern:

1. Hans Derkits schrieb in einer seiner ersten
   Mails zum Thema "10 sehr kurze Zeilen ersetzen
   dabei oft 50 oder mehr 'Parameterkarten'." -
   Weniger *und* einfachere Notation - ist das nicht
   im hoechsten Masse aufregend? Genau *diese* Art
   Art von Effizienzsteigerung war ja immer eines
   der Haupargumente schlechthin *fuer* TUSTEP.
   Wenn das *noch* besser, schneller, einfacher
   und perspektivenreicher ginge - na, das waer'
   doch was! Dem nicht nachzugehen, waere fahr-
   laessig - und das war ja sicher auch fuer Martin
   Glessgen der Grund, um illustrierende Beispiele
   zu bitten. In seiner Antwort freilich gab Herr
   Derkits am 01.06.04 ein Ruby-Skript von 27 Pro-
   grammzeilen, mit dessen Hilfe ein Index verborum
   (mit Stopwoertern, Sortierung, Ausgabe etc.) rea-
   lisiert wird. Dass das auch fuer TUSTEP nur eine
   Kleinigkeit ist, sollte klar sein:

-- TUSTEP-Prozedur fuer eine einfache Wortliste: --

#rv,Q,Z.1,mo=+,lo=+,pa=*
        * Trennzeichen zwischen Woertern:
tr        |.| |_|:|;|,|-|"|!|?|'|=|/|(|)||%>@|
        * Stopwoerter:
t-        |der|die|das|dem|er|sie|es|hat|ist|
        * Sortierschluessel:
ssl       20 20
        * Sortiervorgaben:
xs1       |ä|ae|ö|oe|ü|ue|ß|ss|%>@><>@||
xs2       |ä|az|ö|oz|ü|uz|ß|sz|%>@</|<=01X|
xs2       |%>@>@</|<=01Y|%>@%>@>@</|<=01Z|
*eof
#so,Z.1,Z.1,so=17+40'0,ti=17+40,lo=+
#ra,Z.1,-,mo=+,lo=+,pa=*
ssl       0
drt       PS-10
        * Absolute Haeufigkeiten ausgeben:
ah        1
        * Relative Haeufigkeiten ausgeben:
rh        1
*eof

------------------------------------------------

   Hans Derkits beschloss sein Ruby-Skript mit der
   Feststellung "... es kann wirklich Freude machen,
   das einfach hinzuschreiben, uneingeschränkt vom
   Korsett der Durchgangsangaben, Wahlschalter, Be-
   rechnung von Sprunganweisungen". Genau da ist der
   Punkt, wo ich mit dem Nachvollzug der behaupteten
   Vorteile meine Probleme habe: Das TUSTEP-Skript ist
   erstens kuerzer, zweitens nach meiner Ueberzeugung
   nicht weniger leicht verstaendlich, drittens kann
   es mehr (zweistufige benutzerspezifische Sortie-
   rung) - und die insinuierte Korsage von Durchgangs-
   angaben, Wahlschaltern und Sprunganweisungen gibt
   es auch nicht. Die Beweisfuehrung ist deshalb (fuer
   mich und fuer viele Kollegen) noch nicht stichhal-
   tig. Es muss irgendwie anders und mit schlagenderen
   Argumenten gezeigt werden, wo die Vorteile oder
   Staerken der Skriptsprachen liegen.

2. Fuer mein zweites Beispiel moechte ich alle an
   der Diskussion Interessierten bitten, sich Herrn
   Giacomazzis exemplarische Umsetzung eines eigenen
   Numeriere-Ersatzes (in Python) unter dem URL
   http://www.giacomazzi.de/tustep/nummeriere.html
   und dort ganz besonders den vorgestellten Pro-
   grammcode anzuschauen. Um es vorweg zu betonen:
   Ich finde die sparsame Neuprogrammierung einer
   durchaus komplexen Leistung nicht weniger ge-
   lungen als die luzide didaktische Hinfuehrung.
   Aber der am Programmieren eher desinteressierte
   durchschnittliche TUSTEP-Anwender, der bis dahin
   fuer Numeriere-Zwecke etwa den folgenden Dreizei-
   ler (Kommentarzeilen abgerechnet) verwendet hat

---------------------------------------------

#nu,q,z,,+,*
      Auf LNR werden diejenigen Zeichenfolgen
      angegeben, hinter denen die neue laufende
      Nummer eingesetzt werden soll:
LNR       |==|
      Auf VNR werden diejenigen Zeichenfolgen
      angegeben, hinter denen die Verweisnummern
      stehen, die aktualisiert werden sollen:
VNR       |#..|
*eof

--------------------------------------------

   wird unwillkuerlich sowohl Kuerze wie auch Ver-
   staendlichkeit der beiden Programme miteinander
   vergleichen - und ich wage die Behauptung, dass
   auch dieser Vergleich zugunsten der TUSTEP-Loe-
   sung ausfallen wird. (Nun gut, es stimmt, es gibt
   in TUSTEP-NU ein Limit fuer die laufenden Nummern
   und Verweise, das bei 99999 liegt. In meiner eige-
   nen Praxis bin ich bisher - in einer fuenfbaendi-
   gen Bibliographie - nur bis ca. 31000 gekommen,
   weshalb ich davon ausgehe, dass Herr Schaelke den
   Grenzstein versetzen wird, wenn es sich als pra-
   xisrelevant erweisen sollte.) Erneut Frage in die
   Runde: Sieht das jemand nicht so? Oder anders -
   fuer statistische Zwecke: Wer aus der Schar der
   TUSTEP-Anwender fuehlt sich beim Vergleichen des
   Python-Codes mit dem o.a. TUSTEP-NU versucht,
   sein Numeriere-Problem (oder irgendein anderes)
   mit Python statt mit TUSTEP-NU zu loesen? Fuer
   zahlreiche rueckhaltlos offene Wortmeldungen
   waere ich sehr verbunden.

Man verstehe mich bitte recht: Meine Argumentation
ist ausdruecklich *nicht* als Kritik an Python oder
Ruby (und schon gar nicht als Abwehrversuch) zu ver-
stehen. Aber wenn fuer deren Integration nach TUSTEP
bzw. fuer die Schaffung von offenen Schnittstellen
plaediert wird, ist es unerlaesslich, dass an konkre-
ten und moeglichst rundum ueberzeugenden Beispielen
der zu erwartende Mehrwert verdeutlicht wird - und
das ist nach meiner Einschaetzung bisher nicht ge-
lungen. (NB: Dass diesem Erfordernis Rechnung ge-
tragen werden muss, gilt natuerlich erst recht, so-
lange mit der Programmierer-Manpower von Herrn
Schaelkle gegeizt werden muss.)

Es gibt noch ein Weiteres, dessen besondere Berueck-
sichtigung ich mir in der Debatte wuenschte: Ich habe
schon weiter oben darauf abgehoben, dass eine einzelne
punktuelle Programmleistung noch nichts ist, was die
Hunde hinterm Ofen hervorlockt: Modularitaet und Sy-
stemcharakter tun not. Ich habe schon etliche grosse
Projekte mit hoechst komplexem Anforderungsprofil
mit TUSTEP realisiert - und habe dabei niemals nur
*einen* Programmbaustein benoetigt. Es gab *immer*
tausenderlei Projektspezifisches, was kein Programm-
autor in einem einzigen Automatismus haette verankern
koennen. In meiner letzten Satzroutine etwa fuer eine
grosse Edition (eine veritable Besonderheit, zugegeben)
mussten fuenf Satzlaeufe mit 54(!) KOPIERE, vier SV/SO,
zwei RV/RA und drei EINFUEGE zu einer Gesamtleistung
kombiniert werden, von der ich offen gestanden nicht
wuesste, wie sie anders als ueber die Modularitaet
des TUSTEP-Systems zu realisieren waere. Ich betone
das nicht, *weil* ich ein TUSTEP-Anhaenger bin - die
Kausalitaet ist vielmehr genau umgekehrt: Ich bin
hauptsaechlich *wegen* dieser konsequent und gut
umgesetzten Modularitaet ein TUSTEP-Anhaenger.

An eben diesem Punkt sehe ich auch die beste Chance
zur Synthese: Wenn es in der Diskussion gelingt,
ueberzeugend zu zeigen, welche Programmleistung(en)
- ueber das TUSTEP-eigene Leistungsspektrum hinaus
- und/oder besser/effizienter/einfacher/schneller
  als in TUSTEP
ueber entsprechende Schnittstellen in TUSTEP zu
Skriptsprachen realisiert werden koennen, wird
sich sicherlich sofort ein Mehrheitsvotum dafuer
bilden. Ich fuer mein Teil wuerde mich dem jeden-
falls anschliessen. Und damit bin ich wieder an
meinem, nein richtiger: an Martin Glessgens Aus-
gangspunkt angelangt: Legt die Karten auf den Tisch
- aber achtet bitte darauf, dass es gute sind!

Oder sollten wir uns doch einmal - wie oben ange-
dacht - in groesserem Kreis zu einem Kolloquium/
Gedankenaustausch ueber das Thema treffen?

Herzliche Gruesse an alle von

Michael Trauth

---------------------------------------------------------------
Dr. Michael Trauth                  e-mail: trauth at uni-trier.de
Rechenzentrum                       office: Tel. 0651-201-3413
der Universitaet                            Fax  0651-201-3921
Universitaetsring                secretary: Tel. 0651-201-3417
D-54286 Trier
---------------------------------------------------------------