Fwd: Re: [Tustep-Liste] Quo vadis?

Mi Mai 19 14:53:47 CEST 2004

Lieber Herr Meyer,

haben Sie vielen Dank für Ihre Antwort. Die Relativierung, die Sie in 
einigen Punkten vornehmen, ist mir aus interner TUSTEP-Sicht 
verständlich. Nur hatte ich mir erlaubt, eine andere Sicht, eine von 
außen, doch keine bloß ablehnende, zu vertreten.

In dieser anderen Sicht erscheint z.B. die Makrofunktion EXECUTE, die 
Sie zurecht ansprechen, sehr umständlich. Fast jeder zweite Texteditor 
unterstützt den Aufruf externer Programme, die Umleitung von STDOUT und 
STDERR in ein Ausgabefenster und den direkten Sprung zu einer Stelle, 
z.B. einen Fehler, im Dokumentfenster bei Doppelklick auf eine 
Fehlermeldung im Ausgabefenster. Dazu müssen weder Dateien umbenannt, 
noch Projekte eingerichtet werden. Ich muß auch nicht rätseln, ob das 
Output ausbleibt, weil "execute" ohne Dollar (meine Neigung), oder 
"$$execute" (in Anlehnung an "#kommando") oder doch richtig "$$ execute" 
eingegeben wurde, aber das ausgeführte Programm kein Output produziert. 
Von aussen gesehen spielen Umständlichkeit und Aufwand eine nicht 
unwichtige Rolle, für den Adepten weniger, für den Liebhaber eigentlich 
keine. Warum Programme von TUSTEP aus aufrufen, wenn es einfacher geht? 
In der Sache selbst ist mir allerdings unklar, wie weit der Aufruf 
fremder Programme sich mit der Integrität von TUSTEP-Dateien und der 
Datensatznummern verträgt. Das Handbuch macht seltsame Andeutungen; es 
wäre ein Punkt, den ich vertiefen müsste auch unter Linux. In Editoren, 
die mit reinen Textdateien arbeiten, braucht man sich keine Sorgen zu 
machen.

Der zentrale Punkt ist aber nicht, daß TUSTEP Fremdes integrieren 
müsste. Dies sollte zwar geschehen, wenn es Arbeit abnimmt und den 
Nutzern Vorteile bringt. Der Punkt ist, daß TUSTEP selbst sich für die 
Programme und Nutzer da draußen öffnen sollte. Die Nutzbarkeit einzelner 
Module wie VERGLEICHE "bei Bedarf" und eine leichte Integration externer 
Tools in TUSTEP sind zwei Seiten derselben Medaille. Beides setzt einen 
modularen Aufbau voraus, aber nicht nur nach innen, wie ihn der Diamant 
auf dem Handbuch versinnbildlicht, sondern nach außen modular. Es sollte 
möglich werden, einzelne TUSTEP-Module von außen anzusteuern. Doch von 
aussen betrachtet, stellt sich TUSTEP wie eine undurchdringbare black 
box dar. Man kommt sich schon komisch vor, wenn man nach den 
ausführbaren Dateien für "vergleiche" oder "rvorbereite" sucht und auf 
der Kommandzeile startet. Nein, es ist nicht vorgesehen und 
möglicherweise unerwünscht. - Es müssten an allen Spitzen des 
TUSTEP-Diamanten Verbindungslinien zur Außenwelt zuwachsen, und dem 
steht aber zunächst das Dateiformat entgegen. Vor vier Jahren hatte ich 
Herrn Ott schüchtern gefragt, ob es nicht denkbar wäre, das Dateiformat 
von TUSTEP auf XML umzustellen. Die unerwartet heftige Reaktion ist mir 
in unvergesslicher Erinnerung geblieben, doch nie völlig verständlich 
geworden; es war nicht einmal wörtlich XML gemeint, sondern überhaupt 
ein offenes Dateiformat. Die historische Berechtigung und Bedeutung des 
binären Dateiformats für die gesamte TUSTEP-Funktionalität ist mir klar. 
Inzwischen machen es uns aber alle vor, ob OpenOffice oder MS Word oder 
QuarkXPress, daß es sogar xml-komform geht.

Klar geworden ist mir allerdings, daß es nicht nur technische, sondern 
auch erhebliche politische Gründe sind, die die Richtung der 
TUSTEP-Entwicklung geprägt haben und anscheiend noch prägen. Es drängt 
sich ein Zusammenhang zwischen technischen Grundrichtung und rigiden 
Nutzungsbedingungen auf. Erst wenn beides angepackt würde, gäbe Anlaß zu 
dem Optimismus, den der Schluß Ihrer schönen Mail ausstrahlt. Aber wer 
macht das?

Herzliche Grüße,

Giorgio Giacomazzi

Thomas Meyer wrote:
> Diskussionsforum Tustep-Liste
> Weitere Informationen: www.itug.de
> ------------------------------------------------------------
> 
> Sehr verehrter Herr Giacomazzi,
> 
> zuerst sei Ihnen herzlich und aufrichtig für Ihre Offenheit und konstruktive
> Kritik gedankt. In der Tat treffen einige Ihrer Kritikpunkte m.E. völlig zu;
> andererseits wird man doch Verschiedenes relativieren wollen:
> 
> Zunächst: Warum sollte sich der Hauptentwickler von Tustep nicht von den
> Schwächen amerikanischer Konkurrenzprodukte überzeugen und zu diesem Zweck
> eine Version dieser Programme installieren? Man zündet doch auch ab und zu
> eine Kerze an und möchte dennoch nicht auf elektrisches Licht verzichten...
> 
> Die Weiterpflege der Linux-Version wird doch keineswegs "gescheut"; vielmehr
> scheint noch keine rechte Diagnose des Problems von Herrn Willjung
> vorzuliegen. Erst wenn man weiß, was kaputt ist, kann man auch reparieren. Im
> Gegenteil ist es doch gerade so, daß die Tustep-Abteilung und insbesondere
> Herr Schälkle jeden Vorschlag zur Weiterentwicklung von Tustep gerne
> aufnimmt: Hierfür ließen sich viele Details nennen, als jüngstes etwa eine
> Editorfunktion "X_MRK", über die ich an dieser Stelle aber so wenig verraten 
> will, wie über die kommenden Weihnachtsgeschenke.
> 
> Freilich mag gerade die Bereitschaft von Herrn Schälkle, auf Neuerungswünsche
> der Tustep-Nutzer einzugehen, manchmal den Eindruck erwecken, hier werde "das
> Rad neu erfunden". Aber kann man diesen "Vorwurf" (dessen vermeintlich
> negativen Klang man durchaus hinterfragen könnte) nicht umkehren: Warum
> plädieren Sie so massiv für die Integration von open-source-Programmen in
> Tustep? Hieße nicht genau das, das Rad neu zu erfinden? Oder sollten Sie die
> Makrofunktion "execute" übersehen haben?
> 
> Gerade darin liegt doch die Offenheit von Tustep: Der Satz von umfangreichen
> Tabellen ist mit #SATZ scheußlich kompliziert (für mich wenigstens!) - kein
> Problem: Unter Linux läßt sich aus Tustep heraus problemlos das Satzprogramm
> LaTeX ansteuern! Die Konvertierung von xml-Daten mit #KOP ist Ihnen zu heiß?
> Mir auch, weshalb ich "xalan" benutze. Ohne Tustep verlassen zu müssen. Sie
> wollen Python-Skripte nutzen? Nur zu! Das spricht doch nicht gegen Tustep,
> sondern dafür.
> 
> Dies kann freilich nicht über Probleme hinwegtäuschen, die Sie durchaus
> richtig akzentuiert haben: Beispielsweise läßt sich der Komplex des
> Satzprogrammes nennen, das in einem etwas maroden Zustand zu sein scheint.
> Hier - in der Gewährleistung der Funktionalität des bestehenden Systems wie
> in der Bereitstellung grundlegender neuer Funktionen - liegt wohl die
> eigentliche Kernaufgabe der Tustep-Entwickler.
> 
> Demgegenüber ist die Selbsthilfe der Anwender nicht minder wichtig, wo es um
> die Entwicklung benutzernaher Programme und Makros geht. Ist es nicht oft so,
> daß jeder "Tustepler" für sich immer wieder das "Rad neu erfindet"? Deshalb
> der Vorschlag einer gemeinsamen Programmsammlung.
> 
> In diesem Kontext läßt sich eher danach fragen, ob die derzeitige 
> Lizenzpolitik nicht einiges dazu beiträgt, Tustep an der Verbreitung über 
> einen recht kleinen Kreis von "Eingeweihten" hinaus zu behindern. Lägen die 
> Programmquellen frei verfügbar vor, wäre die Voraussetzung dafür gegeben, daß 
> auch die Grundprogramme von Tustep durch seine Anwender weiterentwickelt 
> würden. Und erst unter der Bedingung einer freien Lizenz ist überhaupt eine 
> Motivation zur Arbeit mit den Programmquellen gegeben.
> 
> Solange indessen der Entwicklungsprozeß von Tustep im wesentlichen auf eine 
> Person beschränkt bleibt und Programmiererzeit also eine äußerst kostbare 
> Ressource ist, empfiehlt es sich m.E., die Entwicklung von Tustep auf die 
> Pflege und punktuelle Weiterentwicklung der Grundprogramme zu beschränken, 
> Spezialaufgaben aber externen Programmen zu überlassen.
> 
> Jedenfalls ist Ihnen uneingeschränkt zuzustimmen, daß noch viel zu tun
> bleibt. Hinzufügen möchte man nur: Packen wir's an. Wir auch. Und nicht nur 
> "die in Tübingen".
> 
> 
> Herzliche Grüße, Ihr
> Thomas Meyer.
> 
> 
> Am Donnerstag, 13. Mai 2004 13:03 schrieb Giorgio Giacomazzi:
> 
>>Diskussionsforum Tustep-Liste
>>Weitere Informationen: www.itug.de
>>------------------------------------------------------------
>>
>>Lieber Herr Schälkle,
>>
>>ich zögere, auf Ihre Mail zum Import von Word-Dateien zu antworten, weil
>>die ausstehende Klärung bei den TUSTEP-Lizenzen und TUSTEP-Rechten für
>>mich die Voraussetzung eines neuen Engagements in der Sache ist.
>>
>>Doch schon die Mitteilung, daß ein wenn nicht der Hauptentwickler von
>>TUSTEP Word auf die Festplatte installiert hat, ist ein Ereignis, das
>>nicht ganz untergehen darf. Zumal in Verbindung mit der Mitteilung, daß
>>inzwischen der Aufwand für eine Weiterpflege der Linux-Version von
>>TUSTEP gescheut wird (nach Herrn Willjungs Mail vom 7.5.2004). Wird der
>>viel grösserer Aufwand für den Word-Import nicht gescheut? Oder wer
>>trifft hier so fragwürdige Entscheidungen?
>>
>>Ich will aber keine Einzelentscheidungen thematisieren, sondern die
>>Grundrichtung der Entwicklung von TUSTEP.
>>
>>Warum, wenn es um Word geht, setzen Sie nicht auf ein Tool, das auch
>>Sterbliche einsetzen können, sondern auf eine neue Skriptsprache, die
>>zwar wunderschön ist, aber vielleicht 10 Leute kennen und 5 produktiv
>>einsetzen? Über die es (wie bei allen wichtigen Teilen von TUSTEP) keine
>>einführende Literatur gibt? Vor allem aber eine Skriptsprache, über die
>>grundsätzliche Unklarheit herrscht, ob sie als "neues
>>Programmierkonzept" das alte KOPIERE ablöst oder zusätzlich zu KOPIERE
>>gelernt werden sollte. - Ein Exkurs am Rande. Anfang des Jahres hatte
>>Herr Trauth mehrere spannende TUSTEP-Kurse für den Sommer zur Auswahl
>>angeboten. KOPIERE fand Resonanz, die Makrosprache leider nicht. Wenn
>>die besten TUSTEP-Köpfe sich nicht artikulieren und zeigen können, wohin
>>es sich lohnt zu investieren, werden Ihre persönliche Verdienste um die
>>Makrosprache vergeblich sein. Nach meiner einzigen intensiven Erfahrung
>>mit KOPIERE und XML vor vier Jahren, mache ich jedenfalls einen breiten
>>Bogen um KOPIERE, wenn es nur geht. Es wundert mich, daß ausgerechnet
>>Sie als Schöpfer der Makrosprache es mit KOPIERE versucht haben, das von
>>Baumstrukturen nicht mal einen Schimmer hat. Allerdings meine ich echtes
>>XML, nicht das hier übliche <autor>...</autor> <titel>...</titel>
>><jahr>...</jahr>.
>>
>>Kann sich eine kleine Gemeinde zwei konkurrierende Programmierkonzepte
>>leisten? Warum anstatt immer wieder neue proprietäre Lösungen zu
>>entwicklen, integrieren Sie nicht eine weitverbreitete Skriptsprache in
>>TUSTEP? (Mein Vorschlag: python).
>>
>>Warum bietet TUSTEP nicht wie jedes vernünftige Framework und jede
>>grössere Applikation eine Programmierschnittstelle, so daß auch andere
>>Entwickler die TUSTEP-Funktionalität unkompliziert nutzen können? Sind
>>die unerwünscht?
>>
>>Warum programmieren Sie in TUSTEP einen halben XML-Parser, die Anweisung
>>zum Suchen und Prüfen von Tags im Editor, anstatt einen vollwertigen
>>Parser zu integrieren? (Mein Vorschlag: libxml)
>>
>>Wie wäre es, wenn das Dateiformat von TUSTEP so dokumentiert würde, daß
>>man TUSTEP-Dateien ohne die originelle TUSTEP-Software lesen kann?
>>Einflußreiche Professoren glauben immer noch, daß TUSTEP die Daten in
>>ASCII-Format speichert. Versuchen Sie liebe TUSTEP-Nutzer mit einem
>>normalen Editor wie Notepad eine TUSTEP-Datei zu öffnen.
>>
>>Könnten Sie Beispielcode zur Verfügung stellen, wie man TUSTEP-Dateien
>>lesen (parsen) und schreiben kann? Das böse Microsoft bietet Software
>>Development Kits für RTF, Word-XML, Excel usw. Steht dem ausgerechnet
>>bei TUSTEP etwas entgegen?
>>
>>Warum werden Interessenten an VERGLEICHE gezwungen, ein komplettes
>>TUSTEP zu lizenzieren, zu installieren, zum Import der Dateien in
>>TUSTEP, dabei zur Umbenennung auf allen Betriebssystemen legalen
>>Dateinamen gemäß völlig veralteter TUSTEP-Konventionen, anstatt daß Ihr
>>grossartiges VERGLEICHE wie jedes andere diff-Tool bei Bedarf verwendet
>>werden kann?
>>
>>Kurz: Warum programmieren Sie bei TUSTEP das Rad immer neu, und zwar in
>>einer Weise, die für den Rest der Welt kaum brauchbar ist? Der Rest der
>>Welt wird sich für TUSTEP so lange nicht interessieren, wie TUSTEP sich
>>für den Rest der Welt nicht interessiert.
>>
>>Was aber die Verbesserung der XML-Unterstützung in TUSTEP angeht, sehe
>>ich nicht, was das mit Word zu tun hat. Solche XML-Unterstützung sollte
>>in TUSTEP erst eingebaut werden, und das geht ein wenig über die
>>Unterstützung von Spitzklammermakros im Satzprogramm hinaus.
>>
>>Sie ist ebenso überfällig wie die Neuentwicklung des Satzprogramms
>>selbst, das längst an seine Grenzen gestossen ist. Eine kleine
>>anspruchslose Anregung en passant: Könnten Sie die Leerzeichenplage
>>beseitigen? Ich meine jene chronische Unklarheit darüber, ob man vor und
>>nach einer Satzanweisung ein Leerzeichen einfügen darf bzw. einfügen
>>muß, was ständig dazu zwingt das Handbuch oder die Hilfe zu konsultieren.
>>
>>Es bleibt also in TUSTEP auch ohne Word viel zu tun.
>>
>>Mit besten Grüßen,
>>
>>Giorgio Giacomazzi
>>
>>------------------------------------------------------------
>>Tustep-Liste at itug.de
>>https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste
> 
> 
> -------------------------------------------------------
> 
> ------------------------------------------------------------
> Tustep-Liste at itug.de
> https://lists.uni-wuerzburg.de/mailman/listinfo/tustep-liste
> 