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

[Giorgio Giacomazzi]

Lieber Herr Seck,
liebe Listenteilnehmer,


#NU --> #KO --> K.O. --> O.K <-- #NU
====================================

 > Ich vermute auch, daß die angesprochenen Skripte eher einfache
 > Probleme lösen, wie in dem Numerierbeispiel (überträgt es veränderte
 > Nummern auch in andere Dateien, in denen die Einträge aus der
 > ersten Datei zitiert werden?).

Mir war hier nicht klar, welches komplexe numeriere-Problem gemeint ist, 
und ich bat dazu um ein TUSTEP-Beispiel. Sie kündigten allerdings ein 
kopiere-Beispiel an, sodann ein 33 KO-Beispiel, welches ich das 
K.O.-Beispiel nannte und das nun vorliegt. In diesem sehr interessanten, 
aber sehr langen und implikationsreichen Programm sehe ich zwei 
#NU-Anweisungen mit Modus MERKE und HOLE, die Sie vielleicht oben 
gemeint hatten; MERKE und HOLE hatte ich in der Tat nicht behandelt. Ich 
werde demnächst das Versäumnis nachholen, einfach um NUMERIERE gerecht 
zu werden.

Wenn aber eher der Beweis erwartet wurde, daß Skriptsprachen den 
Leistungsumfang von #KO abdecken, dann scheitert dies schon an den 
praktischen Schwierigkeiten, die Sie in der Begleitmail erkannt haben. 
Diese Fragestellung ist aus meiner Sicht auch nicht ganz richtig. Mein 
Problem mit KOPIERE war nie die Leistungsfähigkeit, sondern der 
Lernaufwand, die unübliche Denkart und das Regelwerk, die #KO verlangt. 
Beweise der Leistungsfähigkeit führen von diesem Thema ab. Dagegen paßt 
zum Ihr Aufsatz, den ich mit großem Interesse gelesen habe und nun zum 
Anlaß nehme, einige historische Betrachtungen anzustellen.


Geschichtliches
===============

Anläßlich der Lektüre von F. Secks Beitrags 'TUSTEP in der UB Tübingen' 
habe ich auch andere historische Zeugnisse unter dem Gesichtspunkt 
'TUSTEP und Skriptsprachen' durchgesehen. (Meine Sammlung ist sehr 
klein, s.u.)

Ein Hauptthema dieser Zeugnisse ist der Anfang der 70er Jahre erfolgte 
Übergang von der Programmierung in FORTRAN (am Rechenzentrum der Uni 
Tübingen) zur parametergesteuerten Ausführung fertiger Programme (durch 
Benutzer in den Fachbereichen der Uni Tübingen). Dieser Schritt war 
damals sicher ein enormer Fortschritt. Man könnte auch so weit gehen zu 
sagen, daß die damals entstandenen TUSTEP-Unterprogramme etwas wie 
'spezialisierte Skriptsprachen' innerhalb der Gesamtanwendung TUSTEP 
sind. Das ist ein durchaus moderner, damals bahnbrechender Ansatz.

Aus heutiger Sicht nicht leicht zu verstehen ist aber die Art, wie 
dieser Übergang vollzogen wurde. Wie konnte man glauben, daß immer 
länger werdende Parameterlisten, hunderte von Parameterkürzeln aus 1-2, 
max. 3 Buchstaben 'benutzerfreundlicher', 'leichter' zu verstehen wären 
als klassische Programmierkonstrukte? In TUSTEP wurden Funktionen, 
Subroutinen, Schleifen und Bedingungen für den Benutzer nicht zugelassen 
oder versteckt, dafür wurde in KOPIERE eine Sprungtabelle realisiert, 
die heute viel komplexer wirkt.

Ein Blick in die Chronik (http://www.giacomazzi.de/tustep/history.html) 
zeigt, daß TUSTEP sogar vor C und Pascal konzipiert wurde. Damit waren C 
und Pascal keine Größen, an denen sich TUSTEP orientieren konnte oder 
musste. Eher Fortran IV (1963). Wie konnte man aber in den 80er und 90er 
Jahren, wie kann man noch in diesem Jahrtausend glauben, daß diese Art 
der "parametergesteuerten Programmierung", wie man das alte 
Programmierkonzept von TUSTEP nennen könnte, benutzerfreundlicher und 
effizienter ist als das Konzept moderner Skriptsprachen? Mein Verdacht 
ist: Die Erfolgsgeschichte von TUSTEP hat den Blick für parallel 
stattfindende Entwicklungen, für den main stream, verstellt. TUSTEP ist 
immer TUSTEP geblieben. Es hat Neues entweder zu sich selbst kompatibel 
(proprietär) gemacht oder dem Neuen getrozt. Selbst die neue 
Makrosprache, die endlich echte prozedurale Programmierung in TUSTEP 
ermöglicht, scheint (bei flüchtigem Vergleich) sich eher an neuere 
Versionen von Fortran anzulehnen. Treue wird bei TUSTEP groß 
geschrieben; ihr muß sich alles unterwerfen.


Performance
===========

Die andere Seite der Medaille soll nicht verkannt werden. Die frühe 
Entstehung von TUSTEP hat gerade geschichtlich bedingte Vorteile: Sie 
zwang die Entwickler zum sparsamen Umgang mit den wenigen vorhandenen 
Hardware-Ressourcen. Das Ergebnis ist, daß TUSTEP-'Prozeduren' heute 
noch bes. bei großen Datenmengen eine höhere Ausführungsgeschwindigkeit 
haben als vergleichbare Skripte. Leider ist der Preis für die 
Ausführungsgeschwindigkeit von TUSTEP-'Prozeduren' die Langsamkeit bei 
der Entwicklung. Dieser Gesichtspunkt hat mich z.B. dazu veranlaßt, von 
Perl zu Python zu wechseln. Nur wenige TUSTEP-Profis vermögen es, die 
Ausführungsgeschwindigkeit von TUSTEP in Gewinn umzubuchen.

Wenn es gelänge, beides, Performance und ein offenes modernes Konzept 
zusammenzubringen, hätte TUSTEP eine Zukunft. Viele, die den Namen noch 
nicht gehört haben, würden neugierig auf TUSTEP schauen. Dazu müsste 
TUSTEP sich allerdings ein wenig untreu werden.

- - - - - - - - - - -

Obige Ausführungen sind etwas spekulativ, möglicherweise fehlerbehaftet. 
Schließlich fehlen noch viele Informationen. Für Korrekturen und weitere 
Informationen zur Entwicklungsgeschichte von TUSTEP bin ich sehr 
interessiert.

Ein Beitrag, der gut beim Workshop, den Herr Trauth angeregt hatte, 
Platz fände, wäre einfach, daß die Entwickler Auskunft geben, wie sie 
die technische Machbarkeit der verschiedenen ins Gespräch gebrachten 
Optionen zur Modernisierung von TUSTEP sehen und ihre Einschätzung 
technisch erläutern. Das wäre auf jeden Fall ein Gewinn, wenn man sich 
die kurze, blendend klare Mail von Herrn Schälkle über das Dateiformat 
von TUSTEP anschaut. Niemand kann verlangen, was nicht machbar ist. Aber 
was machbar ist, wüsste gerne, wer in TUSTEP investiert. Was dann 
vertretbar ist (z.B. Text als Dateiformat ja, nein, wie) kann nicht a 
priori feststehen; es kann nur das Ergebnis einer abwägenden Diskussion 
sein, die Herr Sappler zurecht angemahnt hat.

Herzliche Grüße,

Giorgio Giacomazzi