[Tustep-Liste] Quo vadis? - Ordnungsruf!

Di Jun 22 12:36:58 CEST 2004

Lieber Herr Trauth, liebe Listenteilnehmer,

zuerst halte ich einfach folgendes aus Ihrem Ordnungsruf fest:

- Sie räumen ein, daß TUSTEP keine offene Schnittstelle hat
- Sie räumen ein, daß TUSTEP ein proprietäres Dateiformat hat.

Ob das gut ist, möchte ich diskutieren; wenig ist das nicht. Sodann:

- Sie sagen, diese Diskussion sei Ihnen wichtig, aber nicht warum.
- Sie gehen immer noch nicht auf die Frage nach den zwei 
Programmierkonzepten von TUSTEP ein, obwohl Sie dabei in "Quo vadis" 
namentlich vorkommen.

Sinn offener Schnittstellen
---------------------------

"Zeigt doch mal, worin der besondere Wert einer solchen offenen 
Schnittstelle bestehen koennte!"

Macht für Sie eine offene Schnittstelle wirklich keinen Sinn? Wie Sie 
auf einer Tagung wörtlich und auch wahrheitsnah sagten: Sie kochen 
selbst den Kaffee mit TUSTEP. Aber: In Frage stellen, daß eine offene 
Schnittstelle Sinn macht, kann sich nur leisten, wer mit TUSTEP schon 
versorgt ist.

Für andere, die dieses Glück nicht haben oder den Preis dafür zu hoch 
finden, hätte eine offene Schnittstelle den großen praktischen Wert, 
auch mit anderen Tools
(1) auf TUSTEP-Dateien einschließlich der Satznummer direkt zuzugreifen
(2) TUSTEP-Module in eigenen Prozeduren einsetzen, steuern, ersetzen, 
ergänzen zu können.

Der Wunsch nach offenen Schnittstellen hat nicht nur eine rechtliche 
(Danke an Herrn Mayer) und eine technische Seite. Er hat auch mit einem 
Generationenproblem zu tun, auf das in einer frühen Zuschrift von Herrn 
Till treffend hingewiesen wurde. Wer heute in TUSTEP investiert, hat bei 
sehr hohem Einsatz (s. Herr Hammers Mail) beruflich so gut wie keine 
Perspektiven. Mutatis mutandis gilt das auch für akademische 
TUSTEP-Projekte. Gäbe es zwischen KOPIERE und anderen 
Programmiersprachen zumindest Redundanzen, Synergieeffekte, sähe es 
besser aus; man stiege leichter ein und aus. Die Wahrheit ist, daß wer 
TUSTEP effizient einsetzt, von TUSTEP total aufgesogen wird. Wie uns die 
Autoritäten überraschend freimutig und stolz bestätigen: Wer TUSTEP 
wirklich kennt, kennt nur TUSTEP. Das ist ein hoher Preis. Daß die alte 
Garde, die vorgesorgt hat, sich für diese auch existenzielle Problematik 
junger bzw. neuer TUSTEP-Nutzer einfach nicht interessiert und zur 
Ordnung ruft, finde ich nicht in Ordnung.

Auf dem Deckel des Handbuchs steht klar:

"Von der Ersterfassung der Quellen bis zur Publikation deckt TUSTEP alle 
Arbeitsschritte ab."

Wer so denkt, will nichts anderes. Wäre die Empirie nicht so fies, 
bräuchte der selbst UMWANDLE nicht. Wer hingegen andere Realitäten als 
nur TUSTEP realisiert, dem gefällt das ganze UMWANDLE rein und raus (und 
was kommt da rein? was kommt da raus?), das KOPIERE der Satznummer rein 
und raus und bei signifkanten Satznummern auch EXECUTE auf Dauer nicht. 
Dieser status quo ist praktikabel, wenn es um den einmaligen Import nach 
TUSTEP geht. Braucht man den Datenaustausch aber systematisch aufgrund 
einer anderen Arbeitsweise, sind diese Ansätze sehr beschränkt und 
umständlich.

Der "Diskussion" liegt somit eine tiefe Differenz der Gesichtspunkte, 
der Prämissen und der Arbeitsweisen zugrunde. Diese Differenz ist 
möglicherweise unüberbrückbar. Viele, die hier die Insel verteidigen, 
haben noch nicht bemerkt, auf einer Insel zu leben.

XML-Unterstützung
-----------------

Früher habe ich den Austausch zwischen TUSTEP und dem Rest der Welt auf 
der Ebene der XML-Konvertierung gehandhabt (Punkt 1 oben):
http://www.giacomazzi.de/tustep/word2xml2tustep.html.
Da drängt sich der Folgesatz vom Deckel des Handbuchs auf:

"Die Unterstützung moderner Standards wie XML und Unicode garantiert die 
langfristige Nutzbarkeit der mit TUSTEP erarbeiteten Daten."

Wenn überhaupt unterstützt TUSTEP eine Untermenge von XML in einigen 
Unterprogrammen. An XML-Export, was für die langfristige Nutzbarkeit 
nötig wäre (technisch auch spannend), gibt es nichts, außer, was der 
Benutzer sich selber baut. Die langfristige Nutzbarkeit von TUSTEP-Daten 
ist somit ausschließlich an die langfristige Nutzung von TUSTEP gebunden.

Nummeriere-Beispiel
-------------------

Der Nummeriere-Beitrag geht über die Konvertierungsebene (1) einen 
Schritt weiter zur Ebene (2), dem Zusammenspiel von Software-Komponenten 
zur Laufzeit. Ist wirklich nicht klar, wovon die Rede ist? Nichts 
anderes ist gemeint als das Zusammenspiel der Ihnen allen bekannten 
TUSTEP-Programme innerhalb einer TUSTEP-Prozedur, nur erweitert um 
fremde Module und Tools; und anders herum: um das Zusammenspiel aller 
Komponenten auch innerhalb einer fremden Prozedur (Python, Batchdateien, 
was Sie wollen).

Daß das pythonische Beispiel eine Schwäche der Originalversion, dem 
NUMERIERE  von TUSTEP ausbügelt, ist dabei Nebensache, aber nicht 
uninteressant. (Die 99999er-Grenze stört schon, wenn man z.B. 10 
verschiedene ID-Reihen hat und dann für jede nur 9999 Nummer übrig 
bleiben.) Zentral beim NUMMERIERE-Beitrag ist vielmehr, daß alle Aspekte 
der Arbeit an und mit TUSTEP unter einem modernen Konzept in den Blick 
kommen: Den Belangen des Benutzers, des "Power-Users" und des 
Entwicklers wird Rechnung getragen, aber zugleich werden fließende 
Übergänge zwischen diesen Sphären sichtbar, wie sie derzeit undenkbar 
sind. Bei modernen Skriptsprachen kann der "Benutzer" viel leichter zum 
"Power-User" werden, ein "Power-User" kann dem Entwickler zuarbeiten. 
Fürchten jetzt die "Power-User" um ihre Machtstellung?

Falls jemand den absurden Eindruck hat, ich möchte TUSTEP durch Python 
ersetzen, der lese den Python-Beitrag noch einmal. Steht da nicht: "Fuer 
den Profi andererseits waere es moeglich, einen solchen Prototyp etwa in 
C++ (oder Fortran) zu transponieren und aus dem Prototyp ein hoch 
performantes TUSTEP-Modul zu machen." Ich wiederhole: "ein hoch 
performantes TUSTEP-Modul zu machen"

Bitte nehmen Sie, Herr Trauth, die Zuordnung der Beispiele zu den 
genannten Kompetenzen zur Kenntnis; ich habe das nun im Code expliziert. 
Das nicht so einfache Grundmodul (Teil 3) richtet sich doch an den 
Entwickler und nicht an den Benutzer! Warum vergleichen Sie also die 
Klassen mit einer numeriere-Anwengung in TUSTEP anstatt diese mit meinen 
Anwendungen 1, 2 und nach den Klassen zu 3 und 4? Ist denn

#nu,q,z,,+,*
LNR       |==|
VNR       |#..|
*eof

wirklich klarer als "numberAll" oder bedarf es dazu nicht 6 Zeilen 
Kommentars? (Immerhin kommentieren Sie). Wo bleibt bei Ihnen der 
eigentliche NUMERIERE-Code? Der ist ja in Tübingen und würde nie auf 
eine halbe Seite passen. Ist das aber ein guter Grund, Birnen mit Äpfeln 
zu vergleichen?!

Nichts lag mir ferner als ein Wettbewerb, wer den kürzesten oder den 
schnellsten Code liefert. Mir und Herrn Derkit ist auch nicht 
eingefallen, Python und Ruby gegeneinander auszuspielen. Wenn es um 
Gesamtperspektiven geht, sollte sowieso nicht ein Beispiel oder ein 
Aspekt, sondern die Bilanz entscheiden.

Ich habe mir oft ähnliche Beiträge von TUSTEP-Fachleuten gewünscht!

KOPIERE vs. Makros
------------------

Ich wünschte mir, Sie würden auf die Sie ansprechende Frage nach dem 
Verhältnis von KOPIERE und Makros bei TUSTEP eingehen. Kopiere ist 
museumsreif, aber das bei weitem verbreitetste Modell. Sie lehren beide, 
aber zwei Programmierkonzepte sind zu viel und alles andere als 
selbstverständlich. Das ist ein hausgemachtes TUSTEP-Problem, auf dessen 
Erörterung ich schon lange warte - von wegen Python oder Ruby. Schreiben 
Sie doch mal ein Tutorial und ein Kochbuch zur Makrosprache und setzen 
Sie beides ins Netz. Dann könnte sich jeder eine fundierte Meinung 
bilden, eine Lern- und Arbeitsstrategie entwickeln. Wenn es gute 
Literatur zur Makrossprache und zu TUSTEP gäbe, wäre diese Diskussion 
nicht so aufgekommen. Hier ist Platz für Gegenentwürfe.

Übrigens will ich daran erinnern, daß "Quo vadis?" mit einem 
Fragezeichen endet und 15 Fragezeichen enthält. Wenn konkrete 
Alternativen vorgeschlagen werden, stehen sie in Klammern mit dem Wort 
"Vorschlag" davor. Bitte versuchen Sie den Entwurf zu verstehen, anstatt 
an bestimmten Vorschlägen zu kleben.

Dateiformat
-----------

Ob das Dateiformat, Ihr Hauptthema, nun binär oder Text ist, ist aus 
meiner Sicht wichtig, aber nicht entscheidend. Entscheidend ist nur der 
Zugriff auf die Dateiinhalte. Es gibt Satzprogramme, die Zeilennummern 
beherrschen und in anderen Belangen dem #SATZ von TUSTEP überlegen sind: 
sie haben Text als Dateiformat, unterstützen zumindest eine 
Skriptsprache besonders und schließen keine aus. Gut 3/4 aller 
TUSTEP-Projekte laufen auf Satz hinaus. Wenn aber das Dateiformat binär 
sein muß, gehört sich eine Schnittstelle, die anderen Tools lesenden und 
schreibenden Zugriff auf TUSTEP-Dateien ermöglicht; WordPerfect-Dateien 
lassen sich doch in TUSTEP lesen und schreiben. Sollte diese 
Schnittstelle nicht machbar sein, wo doch bei TUSTEP sonst alles geht, 
dann würde ich mir wünschen, nicht auch noch zwei Programmierkonzepte 
beherrschen zu müssen, um mit TUSTEP-Dateien sinnvoll arbeiten zu 
können. Das ist eigentlich alles.

Ich fragte unter anderem:

 > Könnten Sie (Herr Schälkle) Beispielcode zur Verfügung stellen,
 > wie man TUSTEP-Dateien lesen (parsen) und schreiben kann?

Wenn es, wie Sie behaupten, keine Geheimnisse gibt, dann kann und soll 
dieser Beispielcode allgemein verfügbar gemacht werden, z.B. unter 
"Nützlichem" auf der Homepage der ITUG.

Mein pythonisches Konzept verlangt übrigens nicht einmal Open Source, 
sondern eben dokumentierte Schnittstellen; das war auch als 
Entgegenkommen gedacht. Wenn es aber zutrifft, daß die Mitarbeiter der 
TUSTEP-Abteilung den Code zum Satzprogramm noch nie gesehen haben oder 
daß ihnen verwehrt ist, sich damit zu beschäftigen: Wie sollten sie eine 
Schnittstelle oder sonstige Ergänzungen zum Satzprogramm liefern?

Sie sprechen dann Gigabyte große Dateien an, die nur binär zu 
beherrschen wären. Das ist eher verständlich, obwohl es auf dem Gebiet 
inzwischen viel mehr Nuancen existieren als bei der Schwarz-Weiß-Malerei 
von Herrn Mayer. TUSTEP nun also auch als Oracle-Ersatz hat m.W. nicht 
gerade eingeschlagen. Ich kenne Projekte, wo diese Art des 
TUSTEP-Einsatzes kategorisch abgelehnt wurde, und erinnere mich an ein 
Projekt, bei dem der Kunde doch auf eine traditionelle relationale 
Datenbank zurückruderte. Wenn Sie aber in Trier (es interessiert mich, 
wer sonst?) gigabyte-große Dateien in einem Format pflegen, das nur ein 
Programm zu lesen vermag, würde ich an Ihrer Stelle wirklich auf den 
Quellcode bestehen und dazu noch eine Versicherung mit Tübingen 
abschließen. Das wäre ein Grund mehr, auf das Dateiformat acht zu geben. 
Ihre Aufforderung das Thema ruhen zu lassen, könnte leicht mit einem 
Eigentor enden.

Workshop?
---------

Der Workshop an sich ist eine schöne Idee. Ich sehe aber wenig Sinn 
darin, wenn die TUSTEP-Verantwortlichen nicht auf TUSTEP-Fragen 
reagieren und im Vorfeld wichtige TUSTEP-Themen von der Tagesordnung 
gestrichen werden. Die bisher eingegangene Rückfragen zu Python und Ruby 
können auch ohne meinen und Herrn Derkits persönlichen Einsatz geklärt 
werden, denn hier mangelt es nicht an guter Literatur. Ansonsten, wenn 
mehr Antworten von TUSTEP-Seite da sind oder auch nur die rechtliche 
Problematik diskutiert wird, ist die Idee gut.

Herzliche Grüße,

Giorgio Giacomazzi