[Tustep-Liste] Re: Quo vadis?

[Martin Glessgen]

Lieber Herr Derkits,

         Sie haben völlig recht, dass Sie die Diskussion weiterführen; es 
ist ein wenig mühsam, da die Ideen in alle Richtungen laufen, aber 
vielleicht findet sich ja ein strukturfreudiger Geist, der die Gegenstände 
der Diskussion ordnend zusammenstellt.
         Jedenfalls finde ich Ihre Anregungen sehr wichtig und möchte dies 
durch einige kurze Anmerkungen bzw. die Bitte um Präzisierung unterstreichen:

>Das Problem ist auch eine Frage des Kontexts: Kopiere war einmal ein
>wegweisender Fortschritt. Damals gab es aber auch Perl noch nicht, Python,
>Ruby.
         Inzwischen gibt es die Makroprogrammierung in Tustep, die mit den 
genannten Skriptsprachen konkurrenzfähig sein sollte (s.u.)

>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 ist vielleicht viel verlangt, aber können Sie diese Dinge 
konkretisieren? Es ist sehr viel auf einmal und mir nur intuitiv 
nachvollziehbar.

>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'.

         Hätten Sie dafür ein Beispiel?

>Die zur Bearbeitung von Textmustern verwendeten
>'regular expressions' sind übersichtlicher und weit besser lesbar, besonders
>die Mengenoperationen;

         id.

>zugleich kann man umstandslos und beliebig
>Schleifenkonstrukte verwenden, auch XML-Daten parsen, hat alle Vorteile
>objektorientierter Programmierung.

         id.

>(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.)

         Verstehe ich leider auch nicht ganz: Ich kann doch auch bei Tustep 
Kommandos probeweise testen.

>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,

         als leidgeprüftter Tester von Fremdprogrammen hätte ich auch dafür 
gerne das eine oder andere Beispiel


>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.

         aber das geht doch, oder? (s.o. execute) Frage an Herrn Schälkle

>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:
SA spare ich aus


>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.

         s.o. (execute); nochmals dieselbe Frage an Herrn Schälkle


>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.

Könnten Sie die konkreten Operationen ein wenig spezifizieren?


>Es wäre wie die Öffnung einer
>Burg... Und womöglich könnten sogar Nicht-'Tustepianer' ein wenig mehr damit
>anfangen.

ganz klar

>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.

Dies ist jedenfalls ein vernünftiges Forum zur Diskussion von 
Entwicklungskonzepten.
Grüsse reihum
martin glessgen