[Tustep-Liste] Scripting und Satz, Teil 2

[Giorgio Giacomazzi]

Liebe tustep-Runde,

auf die Gefahr hin, die Grenzen der Hotline zu überschreiten, mische ich 
mich wieder mal auf etwas grundsätzlichere Art in die laufenden Debatten 
ein.

Ich sehe zwei Möglichkeiten, was man heute sinnvoller- und 
realistischerweise von der kleinen tustep-Mannschaft in Tübingen noch 
wollen kann. Eine vernünftige Erörtertung setzt ein minimales 
Verständnis voraus, was tustep ist und wo tustep heute steht. Dazu ein 
abstract und ein Beispiel.

Tustep ist "scripting" + satz. "Scripting" in Anführungszeichen meint 
das alte #kopiere, #tue usw., ohne Anführungszeichen die Makrosprache. 
Tustep war in den 60er/70er Jahren tatsächlich ein großer Wurf, gerade 
in der Verbindung von "scripting" und satz. Es hat sich aber auch dank 
dieser Verbindung immer mehr abgeschottet und steckt nun in einer 
Sackgasse. Tustep braucht längst modernere Programmiermittel und ein 
neues Satzprogramm.

Das folgende Beispiel führt nun mitten in die Gegenwart hinein. Vor 
einem Jahr hatte ich Herrn Trauth nach Rat gefragt, wie man die 
abschnittsweise Zeilennummerierung bei kritischen Editionen (nicht bloß 
Zeilenzähler, sondern auch Zeilennachweise) implementieren sollte und 
er, großzügig wie immer, gab mir eine auf kopiere basierende 
Blackbox-Lösung. (1) Das zeigt, wie eng die Verschränkung von 
"scripting" und satz bei tustep ist; generell ist #satz ohne "scripting" 
wertlos; wiederum laufen die meisten tustep-Projekte auf satz hinaus. 
(2) Wie ich zu meiner Schande - oder nicht - gestehen muss: In den 
mittlerweilen abgeschlossenen Satzprojekten habe ich die Blackbox-Lösung 
von Herrn Trauth nicht genutzt, sondern eine neue Lösung auf der 
Grundlage von Neuerungen in der Makrosprache, die Herr Schälkle im 
Listenbeitrag vom 30.11.2004 vorgestellt hat, entwickelt. Paradox ist, 
daß Herr Trauth mir nicht im Sinne seines Hotline-Verständnisses 
geholfen hat, sondern immens durch beiläufige Hinweise, was seine 
Blackbox tut. Ohne diese wäre meine Makrolösung nie entstanden und ich 
bin ihm deshalb zu Dank verplichtet. - Warum habe ich mir aber die 
scheinbar unnötige Arbeit gemacht? Der Grund ist, daß Blackbox-Lösungen 
auf kopiere-Basis nur in unmittelbarer Nähe ihres Urhebers 
funktionieren. Es genügt die kleinste neue Anforderung und die Blackbox 
ist wertlos. Hierzu resümierte Herr Trauth am 19.4.2005:

 > Innerhalb Triers funktioniert das auch ganz gut, ausserhalb und
 > auf lange Distanz schon deutlich schlechter - aber in jedem Fall
 > gilt, dass dieses Verfahren zu meinem allergroessten Bedauern
 > in der Regel unmuendige Benutzer heranzieht, die nur noch
 > rudimentaer verstehen, was denn ueberhaupt an welcher Stelle der
 > Prozedur passiert.

Wie wahr! Und für mündige Benutzer gilt, daß sie die eigenen 
kopiere-Lösungen, wie Herr Leicht sagte, nach einem Jahr auch nicht mehr 
verstehen.

Hier geht es nicht bloß um Technik, sondern um die Denk- und 
Arbeitsweisen, die eine Technik fördert oder nicht. Eine Alternative 
hatte ich vor einem Jahr umrissen; "Kleines NUMMERIERE in Python, den 
TUSTEP-Benutzern und -Entwicklern gewidmet" schildert ein Kontinuum von 
der kleinsten Aufgabe bis hin zur Möglichkeit, mit python auch ein 
ganzes tustep-Modul zu implementieren. Solches Kontinuum ermöglicht 
Mündigkeit, über sich Hinauswachsen, sein Fehlen schafft Abhängigkeit. 
Eine Anekdote mag das verdeutlichen. Meiner Tochter fiel beim 
Lesenlernen einmal der Blick auf das tustep-Handbuch, und sie sagte: 
"Handbuch ... warum?" Nach dem ersten Schock fand ich die Antwort: 
Tustep ist keine Sprache, in der man sich frei ausdrücken kann, keine 
"High Level Language" (oder gar VHLL) wie Python und Ruby, die mit 
wenigen Sprachkonstrukten es ermöglichen, auch komplexe Zusammenhänge 
selbstständig auszudrücken. Bei tustep muss man vor dem Sprechen 
nachschlagen, deshalb Handbuch. Heutige Programmierer sprechen aber 
meistens ohne Handbuch, wie Kinder.

Angesicht der faktischen Lage wäre ich dafür, die Kräfte auf wenige 
zukunftsfähige Felder zu konzentrieren. Ich sehe dazu entsprechend 
meinem tustep-Verständnis zwei sinnvolle Möglichkeiten:

1. Scripting: Vollendung der Makrosprache als Alternative zu #kopiere, 
ferner zu anderen tustep-Programmen, wo der Aufwand in keinem Verhältnis 
zum Problem steht; letzteres ermöglicht eben eine Hochsprache. Die 
Makrossprache sollte erstmal das leisten, was sie nach Herrn Schälkle 
leisten soll. Darüberhinaus sollte sie an heutige syntaktische 
Konventionen weiter angepaßt werden, damit wer von außen kommt nicht hin 
und wieder in Sonderregel stolpert. - Alternativ bzw. ergänzend zur 
Makrosprache könnte eine externe Skriptsprache integriert werden oder 
für externe Skriptpsrachen ein einfacherer Zugang zu tustep-Funktionen 
und -Daten geschaffen werden, wie vor einem Jahr gefordert. Aber findet 
dieser Vorschlag außer bei mir und Herrn Derkits so viel Zustimmung, daß 
er auch realistisch genannt werden kann?

2. Satz: Wenn (und nur wenn) der Ausbau von #formatiere zu einem neuen 
#satz-Programm führt, unterstütze ich das neue #formatiere. Letzteres 
hatte ich im selben Sinne schon beim ersten Vorschlag in Blaubeuren 
unterstützt, aber mit einer anderen als die orthodoxe Argumentation: 
Nicht wegen #formatiere braucht man sich bei tustep zu "genieren" (es 
gäbe schon bessere Gründe, s. Konsortialvertrag). Sondern: Weil 
#formatiere ein üppig ausgestattetes 'formatter' ist, das Fußnoten 
bereits beherrscht, erscheint dessen Ausbau zu einem 'typesetter' als 
denkbar. Formatiere hat noch niemanden "geschadet". Ein Progrämmchen 
aber, das nur proportionale Schriften und Windows-Drucker unterstützt, 
brauchen selbst die meisten seiner Befürworter nach eigener Aussage nicht.

Wenn nur ein neuse formatiere und Makrosprache zur Wahl stünden, hätte 
ich keine Zweifel: Makrosprache vorantreiben, weil sie den weitesten 
Aktionsradius hat. Ich kann mir vorstellen auch ein neues AUMBRUCH damit 
hinzukriegen.

Nachdem nun die Parteien sich vor allem dank Herrn Schälkles stillen 
Beitrag und zuletzt dank Herrn Derkits mehr angenährt haben als es 
vielleicht den Anschein hat, wäre auch ein Treffen von 
tustep-Entwicklern und an der tustep-Entwicklung Interessierten, welches 
Herr Trauth vor einem Jahr vorgeschlagen hatte, denkbar.

Mit besten Grüßen,

Giorgio Giacomazzi