[Tustep-Liste] Re: Quo vadis?

[Hans Derkits]

	Liebe Teilnehmer,

es scheint mir, da ist es nun still geworden um einige - wie ich glaube - sehr 
gute Ideen.

Weil es schade wäre, wenn die Anregungen von Herrn Giacomazzi einfach 
untergehen würden und die Entwickler ja auch auf Rückmeldungen angewiesen 
sind, hier ein paar Beobachtungen aus meiner Praxis.

Das Problem ist auch eine Frage des Kontexts: Kopiere war einmal ein 
wegweisender Fortschritt. Damals gab es aber auch Perl noch nicht, Python, 
Ruby.

Den Wunsch nach einer in Tustep integrierten, gut dokumentierten Skriptsprache 
habe ich oft verspürt - es gibt dafür auch sehr überzeugende Vorbilder: Der 
Editor "vim" (mit integriertem Python), das Bildbearbeitungsprogramm 
"gimp" (Perl), oder "FontLab" (Python), um auch ein kommerzielles Programm zu 
nennen.

Damit würden neben der Möglichkeit, die historisch bedingten Schwächen von 
Kopiere zu umgehen zugleich zeitgemäße grafische Oberflächen zur Verfügung 
stehen, Integration von Parsern, neben weiteren Vorteilen, wie sehr einfacher 
Datenbank- und Netzwerksanbindung und vielem mehr.

Es geschieht heute immer öfter, nicht nur bei verschachtelten Datenstrukturen, 
dass ich Dateien einfach im Textformat exportiere, um sie - in einen Aufruf 
von 'execute' - mit ein paar Zeilen Ruby- oder Perl-Script (mitunter 
ebenfalls aus einer Tustep-Segmentdatei exportiert) zu bearbeiten und 
anschließend für weitere Aufbereitung oder Satz wieder nach Tustep zu 
importieren.

Das klingt kompliziert, und ist durch das Dateiformat bedingt. Doch ist es, 
sogar bei vielen Routine-Aufgaben, viel einfacher zu handhaben als die 
mühsame Syntax von Kopiere. 10 sehr kurze Zeilen ersetzen dabei oft 50 oder 
mehr 'Parameterkarten'. Die zur Bearbeitung von Textmustern verwendeten 
'regular expressions' sind übersichtlicher und weit besser lesbar, besonders 
die Mengenoperationen; zugleich kann man umstandslos und beliebig 
Schleifenkonstrukte verwenden, auch XML-Daten parsen, hat alle Vorteile 
objektorientierter Programmierung. (Ruby wie auch Python haben übrigens auch 
eine interaktive Shell, in der die Auswirkung von probeweise eingegebenen 
Kommandos sofort sichtbar ist - ohne Durchlauf des gesamten Programms. Das 
reduziert die Anzahl der Testläufe erheblich.)

Von den Textveränderungen wären die meisten wohl auch mit Kopiere möglich, für 
den 'Alltagsanwender' wie mich (und ich arbeite seit 17 Jahren damit) 
allerdings nur bei extensiver Handbuchbenutzung (den Tustep-Kurs 
vorausgesetzt).

Natürlich, Tustep erlaubt auch das, 'execute' ist ein wichtiger Befehl. Ob das 
aber insgesamt tatsächlich nur *für* Tustep spricht?

Der Komfort dieser modernen Skriptsprachen (besonders von Ruby) und die 
Einfachheit ihrer Verwendung für die Textbearbeitung sind verblüffend, nicht 
nur im Vergleich zu Kopiere; und ihre Möglichkeiten gehen sehr weit über die 
Textbearbeitung hinaus. Aber: Sie gehören dem 'mainstream' an und sind weit 
von jeder Esoterik, es gelten dieselben Prinzipien, wie bei anderen 
Programmiersprachen auch: man hat zugleich viel auch für deren Verständnis 
und Verwendung gewonnen, die kurze Einarbeitung lohnt sich in mehr als einer 
Hinsicht.

Damit auch Tustep-Makros zu programmieren, ist in meinen Augen ein sehr 
überzeugendes Argument.

Es sind freie Sprachen, warum sie nicht auch innerhalb von Tustep benutzen, 
oder zumindest die Fortschritte, die sie gebracht haben, in dessen Kontext 
verwenden. Ihr Erfolg beruht darauf, dass ihre Autoren verstanden haben, dass 
die Verbreitung in großem Maß auch von der einfachen Erlernbarkeit abhängt.

Beim Satzprogramm ist es vielleicht schwieriger. Und auch hier liegt vieles am 
veränderten Kontext:

Es fehlt unter anderem (ich ergänze hier nur um meine Erfahrung) vor allem die 
Unicode-Fähigkeit, um die zuvor bearbeiteten, oft XML-kodierten Texte auch in 
ihrem ganzen Zeichenumfang entsprechend darstellen zu können.

Auch Satz war einmal wegweisend. Heute ist es mit dem derzeit (allein) 
verwendeten Mechanismus nicht möglich, viele - in Unicode-Fonts fertig 
existierende - Kombinationszeichen mit vernünftigem Aufwand auch zu drucken.

Zwar kann man viele Zeichen damit zusammensetzen, im UniCode-Font gäbe es sie 
aber ohnehin, noch abgesehen von dessen eigenen Kombinationsmöglichkeiten. 
Andererseits sind etliche der in UniCode-Fonts vorhanden Zeichen mit #Satz 
ohne Manipulation der Fontdateien nur schwer darstellbar. Machbar, wenn es 
wenige sind; sind es aber viele, kann das sehr mühsam werden. - Und man 
braucht dazu noch einen Font-Editor.

Warum also nicht, sagen wir, Python in Tustep integrieren, was neben vielem 
anderen auch die bequeme Bearbeitung von XML-Bäumen ermöglichen würde, die 
Vorzüge einer diesen Aggregatstrukturen entsprechenden objektorientierten 
Programmierung, ohne all die Umwege.

Ganz besonders im Fall von Fragen, für die Kopiere nicht konzipiert ist. Eine 
Datenbankanbindung, ein bestimmter Parser, wären bei Bedarf mit einem 
einzigen Kommando einzubinden, ganz abgesehen von der einfachen Handhabung 
zahlreicher anderer, oft sehr komplexer Module. Es wäre wie die Öffnung einer 
Burg... Und womöglich könnten sogar Nicht-'Tustepianer' ein wenig mehr damit 
anfangen.

Doch weiß ich über die Vorhaben und Entwicklungskonzepte des Tustep-Teams 
nicht Bescheid, und vielleicht irre ich mich. - Es ist mir auch klar, dass es 
leichter ist, viele Ideen und Wünsche zu haben, als sie praktisch zu 
verwirklichen.

Mit einem sehr herzlichen Gruß,

Hans Derkits

-- 
Hans Derkits 
johann.derkits at univie.ac.at