Mailüfterl, Algorithmen, Formale Definition und Semiotik...#

Von

Heinz Zemanek (2008)

1. Die älteste Generation#

Die Programmierung hat sich derartig vielfältig und verflochten entwickelt, daß jeder Betrachter ein anderes Bild und ein anderes Zentralthema finden kann. Was er findet, hängt natürlich von dem Standpunkt ab, von dem aus er sucht, und von den Gewichten, welche die verschiedenen Aspekte für ihn haben. Und das kann sich im Laufe eines Lebens sehr ändern.

Das Mailüfterl im Technischen Museum Wien. Bild dem Austria-Forum freundlicher Weise zur Verfügung gestellt

Trotz meines Alters bin ich einer der Jüngsten unter den Computerpionieren und das heißt auch, daß ich der Software näher bin als die Hardware-Heroen. Das Mailüfterl[38] wurde bereits in Hinblick auf die Programmierungsvielfalt konzipiert und meine Interessensschwerpunkte haben sich immer weiter ins Abstrakte verschoben.

Was ist das eigentlich, ein Computer? Die allgemeinste Antwort lautet wohl: ein Modell für die Programmierung von Modellen. Daß er heute vorwiegend als speichernde Schreibmaschine angesehen und verwendet wird, macht nur einen Teilgebrauch von seinen Möglichkeiten und das ist auch schon in Änderung begriffen. Viele andere Benützungsarten sind bereits im Kommen und es würde hier viel zu weit führen und unabsehbare Zeit verlangen, die Informationstechnik auch nur in vager Form zu beschreiben. Der Computer ist Regler und Organisator. Inventarverwalter und Sprachübersetzer, Zeichner und Komponist. Statistiker und Architekt, Tagebuch und Archiv, Fernschreiber und Suchmaschine, Lexikon und Weltlandkarte. Manchmal rechnet er auch, möchte man hinzufügen.

Die Teilung in Hardware und Software bedeutet grob gesprochen die Teilung in Universalgerät und Spezialprogramm. Die Hardware kann alles, die Software spezialisiert diese Hardware schrittweise auf die Anwendung. Wer hätte vor 100 Jahren geträumt, daß es Derartiges eines Tages geben könnte? Und dann die Schnelligkeit, mit der alles kam: im zweiten Viertel des 20. Jahrhunderts die Vorversuche, im dritten die Ausbildung des Computers und im vierten der PC und die Vernetzung. In Zahlen ausgedrückt: eine Verbesserung der Hauptparameter um 1000 alle 20 Jahre.

Eine Grundfrage scheint mir zu sein: warum sind Hardware und Software so verschieden verläßlich, wo sie doch beide auf der soliden und fehlerresistenten zweiwertigen Aussagenlogik beruhen. Daher kommt ja der Erfolg unseres Handwerks: wir vermögen Milliarden von Binärereignissen fehlerfrei abzuwickeln. Ich sitze mitunter immer noch staunend vor dem Computer und versuche, dies zu verstehen. Das gelingt mir nicht und das kann mir nicht gelingen, weil weder die Mikrosekunde noch die Datenmenge bei einem Datei-Aufruf vorstellbar sind. Als ich im letzten Kriegsjahr eine Mikrosekunde[1] (für nachrichtentechnische Zwecke) herstellte, sah ich sie am Oszillographen - aber nicht wirklich. Ich sah einen etwa 1 cm breiten Zapfen. Daß das eine Mikrosekunde war, eins nur aus der Einstellung des Schwingungsgenerators auf 100 kHz hervor und aus der Division von 10cm durch 10. Die heutige Hardware trägt man mit der Hand (beim Mailüfterl waren noch Tieflader und Kran erforderlich) die Software ist unsichtbar, außer durch ihre Dokumentation und durch sie wird sie noch unsichtbarer. Bis zu einem gewissen Grad ist das Ganze so schlimm, weil am Anfang das Programmieren in den Köpfen der Mathematiker stattfand und diese in den Ingenieurtugenden schwach sind. Und wenn in einer Kunst einmal ein bestimmter Geist drinsteckt, bringt man ihn nur teilweise und jedenfalls schwer heraus.

Es geht auch um Sprachkultur, und nicht nur Kultur der Formalen Sprachen, sondern auch der natürlichen Sprachen, deutsch englisch und alle andern [39]. Bei niedergehender Sprachkultur entsteht ein doppeltes Sprachproblem. Erstens: wie erklärt man dieses unsichtbare Unvorstellbare? Und zweitens: mit den Programmiersprachen kam die Aufgabe der Zurichtung der Algebra auf die Hardware hinzu, die rechte Gestaltung der Programmiersprache und die Erklärung der Programmiersprache für den Benutzer, der ja kein Computerfachmann sein muß.

Wir haben mindestens zwei Niederlagen der Softwaretechnik miterlebt. Erstens gelang es weder der IBM noch den Universitäten, eine einheitliche Programmiersprache zu erreichen. Die Zahl der Programmiersprachen ist Legion. Man stelle sich vor, die Zahl der Algebras und Algebra-Notationen wäre Legion. Darin waren die Mathematiker also mehr als vorbildlich. Wenn es nun zweitens wenigstens gelungen wäre, eine einheitliche Metasprache für diese Legion von Programmiersprachen einzuführen. VDL2 war ein Ansatz dazu. Bei allem Respekt und Ruhm, den wir für unsern Einsatz bekamen: das Richtungweisende an VDL wurde weder von der IBM noch von den Universitäten begriffen.

Das Chaos blüht und gedeiht.

2. Erste Programmiersprachen#

FORTRAN war ursprünglich nicht ein geplantes IBM-Produkt, sondern eine auf den Arbeitsplätzen entstandene Selbsthilfe, die jahrelang nur von Arbeitsplatz zu Arbeitsplatz weitergegeben wurde, ehe Chance und Notwendigkeit der „Produktbehandlung" offenbar wurde.

PL/I war dann schon von Beginn an als Produkt konzipiert, aber für seinen Entwurf wurden weder die (in der IBM sehr aufwendig betriebene, aber nicht auf die Programmierung hingerichtete) Forschung bemüht noch die Entwicklungsabteilung (Development Division, der übrigens das Wiener IBM Laboratorium angehörte), sondern drei Leute aus der IBM und drei Leute aus Benutzerorganisation kamen etliche Wochenenden zusammen und produzierten PL/I, in der Hoffnung, es allen recht machen zu können. Die Aufgabe war, die drei Sprachen FORTRAN, ALGOL und COBOL durch eine einzige zu ersetzen, und dementsprechend viel wurde in dieses Neugebilde hineingefüllt. Überdies war inzwischen der Bedarf für eine derartige Universalität gestorben: Wissenschaftler und Kaufleute konnten sich (bei Firmen interessanter Größe) bereits getrennte Computer leisten und zogen es auch vor das zu tun, anstatt der jeweils anderen Seite viel Rücksicht einzuräumen. Also waren getrennte, auf die beiden Bedürfnisarten ausgerichtete Sprachen die bessere Lösung. Und kaum war die Implementierung von PL/I so richtig im Gang, mußte sie erhebliche Teile von Budget und Man-Power abgeben, damit die IBM bei COBOL II konkurrenzfähig bleiben konnte.

Prof. Zemanek berichtet über die älteste Generation an der JKU 2008
Foto: JKU

Aber abgesehen von diesen historischen Realitäten: was ist die Natur der Differenz zwischen Hardware und Software? Denn an Unvorstellbarkeit mangelt es der Hardware ja auch nicht: was man sieht, ist der Kasten: wo der „Rechenmaschinen-Chip" ist, weiß der Benutzer nicht und braucht es nicht zu wissen, und was darin vorgeht, kann sich niemand mehr vorstellen. Sie kennen meinen Spruch: beim Mailüfterl wußten fünf bis sieben Mann alle Einzelheiten. Wenn man alle Leute beisammenhaben will, die alle Einzelheiten eines Laptops (samt Software) kennen, muß man ein Stadion mieten, wird aber davon abgehalten, weil die Adreßliste hoffnungslos unaufstellbar ist.

Die Verbesserung der Hardware-Parameter um 1000 alle 20 Jahre ist eine mörderische Realität und nur beim Computer-Chip möglich. Man muß versuchen, sich eine Auto-Industrie vorzustellen, welche dieses unmögliche Wunder vollbrächte. Mit dieser sausenden Verbesserung muß aber die Software Schritt halten und damit die Computer-Industrie. Wenn sie ein Modell auf den Markt bringt, ist es nicht nur bereits überholt: es konnte gar nicht auf optimalen Stand gebracht werden, da fehlen Zeit und Geld.

Ein Pfusch überholt den andern.

Die Rasanz der Hardware hat bei der Software weniger Geschwindigkeitsfolgen (obwohl natürlich immer mehr immer schneller läuft) als Sorgfältigkeitsfolgen. Es ist wichtiger geworden, das allerletzte Modell zu haben als ein mit Liebe durchüberlegtes.

Vor dem imperfekten Hintergrund, den man nicht mehr vermeiden kann, bleibt nur übrig, die Situation noch ein bißchen weiter zu erklären. Eine Verbesserung ist nur in sehr kleinen, persönlichen Schritten denkbar, die nach ausreichender Zeit die Normen zwingt, besser zu werden. Eine harte Sache.

Würde man die Software so niederschreiben, wie sie dann tatsächlich stattfindet, nämlich als Folge von Maschinenbefehlen, wäre der eigentliche Vorgang kaum erkennbar. Man muß sich einfach in Richtung auf eine Programmiersprache bewegen.

Ein ganzes Geflecht von Transformationen bleibt dann unbekannt. Aber auch die in höherer Form niedergeschriebene Ablaufvorschrift zeigt nur die Statik und nicht die Dynamik, die fast das Wichtigere ist. So einfach die Grundvorgänge sind, so kompliziert ist der Ablauf eines nichttrivialen Programms. Und damit erkennt man auch die Intransparenz der Hardware: denn für sie gilt das Gleiche.

Wir haben mit all unserem Wissen das Kunststück fertig gebracht, all diese Komplikation einfach hervorzurufen, für uns arbeiten zu lassen und eine Fehlerfreiheit zu erzielen, an die man nicht glauben würde, hätte man sie nicht in Betrieb. So weit wäre also der Computer in lauten Tönen zu loben.

Der Ingenieur glaubt zwar an das, was funktioniert. Wenn er aber nicht mehr weiß, warum es so gut funktioniert, wird er mißtrauisch: das muß Schwächen bedeuten und enthalten, auch Schwächen, die ihm entgehen, von denen er nichts weiß. Tatsächlich wird in der Software-Entwicklung unvollständiges Wissen über unvollständiges Wissen gehäuft. Die Industrie hat keine Zeit, darin Verbesserung anstreben und die akademische Welt sieht darin kein wissenschaftliches Ziel. Es fließt also im gleichbleibenden Stil weiter und die schönsten Publikationen vermögen daran nichts zu ändern.

Noch einen meiner in Vorlesungen oft verwendeten Slogans: ehe man einen Computer in einem Unternehmen für mehr verwendet als strikte Buchhaltung und reine Numerik, müßte man eine formale Definition der Unternehmung haben, um die beiden recht aneinander anzupassen. Der unvermeidliche Graben ist nicht nur Ursache für viele Unzulänglichkeiten und Fehler, sondern auch eine Einladung zu sorglosem Gebrauch des Computers - nicht nur in Unternehmen, sondern etwa auch zu Hause.

Das Dickicht ist hoffnungslos.

3. Computerarchitektur#

Es geht um den gekonnten und gepflegten Entwurf sowohl bei Systemprogrammen wie bei Anwendungsprogrammen. Architektonisch: das heißt Entwurf vom Ganzen ausgehend, die Einzelheiten aus der Gesamtfunktion ableitend und nicht die Lösung aus Vorgefundenem und Improvisiertem „zusammenkleben". Ich habe darüber viele Jahre eine Semestervorlesung gehalten.

Meine Gedanken gehen von Vitruvius[40] aus, einem Baumeister des Caesar und des Augustus, der selbst wahrscheinlich nichts berühmt Gewordenes gebaut hat, der aber durch seine Bücher durch Jahrhunderte Bauqualität geliefert hat. Seine Beschreibung, was gute Architektur ist und was ein guter Architekt studiert haben sollte, läßt sich erstaunlich leicht auf den Computer, auf die Informationstechnik übersetzen. Und wenn man dies tut, merkt man, wie sehr auch die Software Architektur besitzt und daß diese fast in allen Fällen gründliche Verbesserung nötig hätte. Sie bedürfte des planenden, entwerfenden Architekten. Ich glaube, daß die Trennung Ausführungswesen und Architektur, wie sie heute nur im Bauwesen realisiert ist, in der Informationstechnik möglichst bald kommen sollte: nur müßte vorher eine richtungsweisende Theorie des Systementwurfs ernst genommen werden.

Der Ingenieur neigt ja zur Meinung, daß die Kenntnis der Technik für den guten Entwurf ausreicht. Aber ohne zielstrebig angewandte Systemarchitektur bleibt er ein Baumeister, der lediglich die Angebote eines Lieferkatalogs, höchstens mit ein bißchen „trial and error" zu einem „Bauwerk" kombiniert, statt von einer Gesamtidee, von einer Ganzheit auszugehen und die Teile als Funktion des Ganzen zu sehen.

Lesen Sie Vitruvius (es gibt gute deutsche Übersetzungen [5]) und meine beiden Arbeiten, die auf den Computer orientierte [3] und die zweite [4], die zwar für ein Autopublikum bestimmt war, aber doch auch für die Informationstechnik instruktiv ist: in einem Schema dort habe ich die Lenkung vergessen, ein gutes Beispiel für Fehler, die man macht.

Der Programmierung fehlt eine Reihe von Ingenieurtugenden. Ich wage zu behaupten, daß daran die Mathematiker die Hauptschuld tragen, die am Anfang die Hauptverantwortung trugen. Zwar gab es unter ihnen hervorragend architektonisch denkende Pioniere, vor allem Howard H. Aiken und John von Neumann, und so lange die Anwendungen vorwiegend numerische Charakter hatten (so daß die Mathematiker Wächter für das rechte Vorsehen waren), reichte das aus.

Mit dem Übergang zur nicht-numerischen Benützung (ausgelöst durch den alphanumerischen Code, den die Nachrichtentechnik einbrachte) wurde dies ungenügend und die Linguisten haben in der Informationstechnik nie die Rolle von Wächtern gespielt. Sie sehen sich offenbar als Beobachtungswissenschaftler: wenn eine sprachliche Dummheit oft genug vorkommt, wird sie in den Duden aufgenommen.

Zurück zur Unsichtbarkeit der Software: sie ist deswegen gravierender, weil die Hardware ja nur ein allgemeines Spielfeld für die Programmierung bereitstellt. Dabei kann nicht viel passieren. Und wenn etwas passiert, merkt es der Programmierer und lernt damit zu leben oder verlangt Korrektur. Die Software wird in die Anwendung geliefert, aber ohne kundenfreundliche Beschreibung, und es lohnt nicht, sich mit Vorschlägen für Korrekturen und Verbesserungen zu plagen, ehe der erforderliche Kreis geschlossen ist, trifft bereits die nächste Version ein. Und wo diese Abfolge nicht so leicht möglich ist, wo man bei einer Version bleiben muß, haben Korrekturen und Verbesserungen a priori keine Aussicht. Da müßte die erste Version perfekt sein.

Übrigens: ein Beweis für die Unsichtbarkeit der Software ist ihre Museumsunfähigkeit. Alle Versuche, Software in einem Museum oder in einer Ausstellung dem Besucher nahezubringen, sind gescheitert. Computer-Museen sind daher Ehrengräber nicht mehr benutzter Hardware, mit wenig Wirkung für das Verständnis unseres Faches. Nichts ist so staubig wie ein Dutzend im Museum ausgestellter Computer.

Was kann man tun, um die Software sichtbarer zu machen?

4. Die Programmierung des Mailüfterls#

Ein Blick zurück auf die Anfänge der Programmierung ist gar nicht so leicht, zu viel ist seitdem passiert, zu viel hat sich auf ungeordnete Weise verändert. Aber an den eigenen Weg kann man sich natürlich erinnern und so werde ich den Schwerpunkt meiner Ausführungen auf das Mailüfterl legen. Und dieses war ja ein Modellfall für Anfänge.

Programmieren baut auf den Maschinencode auf und so war die erste Frage natürlich, welchen Code erteilen wir unserer Maschine und dies hing wieder mit der Frage zusammen, welche Struktur erteilen wir ihr. Es war ein Kompromiß zu suchen zwischen kühner Unternehmung und gefährlicher Selbstüberschätzung. So entschlossen wir uns zu einer Dezimalmaschine, kamen später aber darauf, daß sie ohne wilden Aufwand auch binär organisiert werden kann und bauten sie für beide Möglichkeiten aus.

Wir wußten von Maurice Wilkes und seiner Mikro-Programmierung [6], aber diese auch noch zu verdauen und anzuwenden, das schien uns doch zu viel. Hingegen übernahmen wir von van der Poel (mit dem ich dann in der IFIP oft zu tun hatte einen halben Schritt in diese Richtung: das Funktionelle Bit, eine Anzahl von Bits im Befehlswort, die gesetzt werden konnten oder nicht und damit einen Vorgang befahlen (oder nicht), der auch ein wenig komplizierter sein konnte als einer der Grundbefehle [7].

Damit hatte das Mailüfterl einen einzigartigen Maschinenbefehlsreichtum: 15 Grundbefehle. 7 Zusatzbefehle und 9 Funktionelle Bits [8]. Nimmt man noch die Anwendungsmöglichkeiten der Index-Stellen dazu (es waren 501 so ergibt sich eine unglaubliche Anzahl von verschiedenen Befehlen. Darauf waren wir so lange unendlich stolz, bis wir realisierten, daß eine zehnmal so schnelle Maschine mit den klassischen 32 Befehlen das Gleiche kann. Die Computertechnik ist voller Überraschungen.

Ich hätte lieber die praxisorientierte IBM-Sprache FORTRAN auf das Mailüfterl geholt, aber weder unsere Bitten um Geld noch unsere Bitten um Unterstützung beim Computerbau wurden von der IBM beantwortet. Damals wußten wir noch nicht, daß man dergleichen nicht an die IBM Österreich richtet, sondern nach Amerika.

Ein paar Jahre später konnten wir auch auf diesem Klavier spielen (wenn dabei auch nicht nur schöne Melodien herauskamen, aber die weniger schönen Melodien sind eine andere Geschichte, die nicht zur Programmierung gehört).

5. ALGOL#

Über die IFIP kam ich mit der ALGOL-Gruppe in näheren Kontakt, und bald war unser Thema ALGOL. Die ALGOL-Gruppe bestand ursprünglich aus zwei Teams, aus einem deutschen und einem amerikanischen. Als sie merkten, daß sie auf das gleiche Ziel hinarbeiteten, verbanden sie sich. Dann aber, von den finanzierenden Vereinen unmißverständlich gestoßen, suchten sie einen internationalen „Regenschirm" und dieser ergab sich durch die IFIP. Um aber die deutsch-amerikanische Dominanz politisch abzufangen, wurde das „Technische Komitee" erfunden, eine Instanz zwischen der arbeitenden Gruppe und der IFIP. wo jede Mitgliedsnation nur einen Vertreter entsandte. Um auf dieser Ebene den Frieden zwischen den beteiligten „Genies" zu gewährleisten. bedurfte es eines „Rudolfs von Habsburg" der Programmierung, eines „kleineren Grafen", der das Gleichgewicht zwischen den "mächtigen Fürsten" zu lächeln versprach. Und da fiel die Wahl auf mich. Ich wurde zum TC 2 Chairman ernannt: TC 2 ist das IFIP Technische Komitee für Programmiersprachen[9]. Ich arbeitete mich in ALGOL ein und als Produkt konnte ich eine Übersetzung des ALGOL-Vokabulars auf Deutsch verfassen, die in den „Elektronischen Rechenanlagen" [10] erschien.

Für das Mailüfterl wurde uns von den Münchnern dann ein genereller Computer versprochen, der sich „leicht auf das Mailüfterl umschreiben" lassen sollte. Das war mehr als übertrieben. Das Mailüfterl-Team stellte sich auf das Übersetzer-Entwerfen um und publizierte Grundsatz-Arbeiten, von denen die wichtigste 1962 auch wieder in den „Elektronischen Rechenanlagen" erschien [11].

Von dort aus war bald zu sehen, daß ein formales Werkzeug für die Definition von Programmiersprachen (nicht nur der Syntax, sondern auch der Semantik) sehr wünschenswert wäre. Das hing auch mit der Vielzahl von Programmierungssprachen zusammen, die sich entgegen der Hoffnung auf Einheitlichkeit als praktisch erwiesen. Wenn das wirklich erforderlich war: ich glaube bis heute, daß eine einzige Programmierungssprache für alle Computer und alle Anwendungen möglich gewesen wäre, hätte man gemeinsam die entsprechende Anstrengung aufgebracht. Andererseits aber waren die Bedürfnisse verschiedener Benützerkategorien doch so verschieden, daß die Praxis die Vielfalt der Sprachen vorzog. Überdies wurde es fast zur Regel, daß jeder Informatiker einmal eine Programmiersprache entwickelte, und so manche fand dann mehr als einen Benutzer.

Hier müßte man schildern wie FORTRAN begann, zuerst firmenintern und dann für die IBM-Kunden. Die Universitätsprofessoren entwarfen ALGOL, das im Unterschied zum compilerdefinierten FORTRAN dokumentdefiniert war. Und die kommerziellen Anwender schufen sich COBOL, dessen Komitee bemerkenswert viele Frauen aufwies [12]. Die IBM wollte diese Dreigleisigkeit abstellen und kreierte die Sprache PL/I [13], welche das Tripel ablösen sollte.

PL/I samt seiner Semantik (also nicht nur die korrekte Schreibung seiner Zeilen) zu definieren, war am Beginn ein äußerst gewagtes Abenteuer: es gab kein geeignetes Beschreibungsverfahren. Auch die (akademischen) ALGOL-Väter beschränkten sich auf die Syntax und ließen die Semantik informell. Daß wir es in Wien geschafft haben, den Koloß PL/I mit einer einzigen Methodik zu beschreiben (die dann von J.A.N. Lee den Namen „Vienna Definition Language" (VDL) erhielt [14] - in der IBM war der Name unverbindlich Universal Language Document, kurz ULD) - war ein österreichisches Wunder. Man vergleiche VDL [15] mit der Axiomatischen Methodik [16]: gut für Dissertationen, aber von wenig praktischem Wert - die Geometrie hat eben der Liebe Gott erschaffen, da geht's mit Axiomen. Der Computer ist ein höchst menschliches Gebilde, voller Kompromisse, da sind Axiome ein Wunschtraum.

Die IBM Development Division hatte ehrgeizige Pläne, dem System /360 ein Super-System nachfolgen zu lassen, aber daraus wurde nichts. Die Firma kehrte zu klassischen Systemen zurück und unser Traum, eine Sprache hervorzubringen, die von der Definitionsmethodik her veredelt wurde, löste sich ins Nichts auf, so wie später das Wiener IBM-Laboratorium. Aus dem System /360 wurde das Svstem /370, weil die Namensgeber nicht einmal bedachten, daß sich die Zahl /360 auf den vollen Kreis bezog.

6. Entwicklung von Programmiersprachen in der IFIP#

Noch einige Worte zu der Entwicklung von Programmiersprachen in der IFIP zur „Working Group 2.1". In seinen Zügen war ALGOL 60 ja fertig, als die ALGOL-Väter in die IFIP übersiedelten, sehr zum Ärger von Peter Naur, der gerne seine Rolle des ALGOL-Organisators und ALGOL-Bulletin-Herausgebers weitergespielt hätte.

In der ersten Zeit stellte WG 2.1 auf Wunsch von ISO einen Subset von ALGOL fertig und führte ein Kapitel über Ein- und Ausgabe hinzu. Dann kam die Diskussion: nächstes Projekt ALGOL-Nachfolger oder ein Meta-ALGOL? Man konnte sich nicht recht einigen und dann setzte eine menschliche und technische Entwicklung ein, die dem Gegenstand nicht recht dienlich war. Menschlich gaben viele Mitglieder die Zusammenarbeit auf, entweder traten sie aus oder sie schalteten auf passiv um. Und technisch wurde unser Fach immer breiter, ohne seine Ganzheit ausreichend kultivieren zu können. Wieder ein Vorlesungsspruch von mir: ein Computerfachmann muß ein Computer-Universalist sein. Um ein solcher werden zu können, sollte er aber vorher ein Spezialist für eine Reihe von Feldern werden, wozu ein Menschenleben nicht ausreicht.

In der IFIP WG2 blieben van Wiingaarden und sein Kreis allein über. Und dieser nahm technisch einen seltsamen Kurs, den van Wiingaarden erst 1973 in Urgench [20] voll aussprach: nämlich die Programmierung von Programmier-Sprachen unabhängig zu machen (Languagefree Programming). Zunächst peilte er mit ALGOL 68 [18] eine Sprache an, welche sich an das Problem anpassen können sollte - ohne zu bedenken, daß damit die Übertragung eines Programms von einem Problem auf ein anderes arg erschwert wird. Aber wem es Spaß macht, für jedes Problem eine eigene Programmiersprache zu entwickeln, der findet in van Wiinsaardens Arbeiten reichlich Material.

Das Vorwort zum IFIP Dokument für ALGOL 68 [19] beweist, daß Tom Steel und ich die falsche Richtung erkannt hatten, aber es wäre nicht klug und IFIP-politisch nicht zu empfehlen gewesen, van Wiingaarden in aller Deutlichkeit zu desavouieren.

Von Wien aus - und ich verlasse nun die Geschichte von WG 2.1 - sah die Welt natürlich nicht nach ALGOL 68 aus. Die Zahl der Programmiersprachen wuchs und wuchs: auch die aus WG 2.1 ausgetretenen Fachleute beteiligten sich an einschlägigen Projekten oder schufen selbst neue Sprachen und vergrößerten die Sprachverwirrung - die Mitgliedsorganisationen der IFIP ließen sich eine große Chance entgegen, aber man könnte den Firmen genau so vorwerfen, die Chancen der IFIP nicht begriffen zu haben: gegen diese Verwirrung gab es und gibt es kein Mittel. Wird das also je anders werden? Und wer denkt darüber nach?

7. Verlässlichkeit von Software und Hardware#

All meine Betrachtungen boten Ausschnitte aus der Entwicklung der Programmiersprachen. aber nur wenig Antwort auf die Frage, warum Hardware und Software so unterschiedliche Verläßlichkeit haben, obwohl beide auf der absolut soliden Aussagenlogik (zweiwertigen Logik") beruhen und obwohl in beide so viel mühsame Denkarbeit investiert wurde und gut aussehende Lösungsversuche gemacht wurden.

Die Antwort liegt nach all diesen Überlegungen weniger im Technischen als im Menschlichen. Und wenn man vom Menschen aus überlegt, sieht man bald, daß das Unbetastbare (Unbegreifliche) an der Software doch ärgere Folgen hat, als man zunächst annehmen würde. Auch wenn die angreifbare Realität des Hardware-Kastens zum Verständnis nicht viel beiträgt: man entwickelt zu ihm eine andere innere Einstellung als zum "Luftgebilde" Software.

Software ist schwer überprüfbar. Der eher scheinbare Ausweg der Korrektheitsbeweise täuscht eine Macht vor. die sich vor der Realität geradezu in Nichts auflöst.

Und es ist zu bedenken, daß der Korrektheitsbeweis nicht korrekt sein muß, so daß dieser Beweis selbst wieder des Korrektheitsbeweises bedarf, und dieser ist schwieriger und umfangreicher als der erste und er eröffnet eigentlich eine unendliche Reihe. In die gleiche Richtung gehen axiomatische Überlegungen. Aber die Geometrie hat der Liebe Gott vorerfunden, während die Programmierung auf dem vom Menschen mit vielen Unebenheiten konzipierten Computer laufen soll. Wieder ein Thema für den akademischen Betrieb, aber wenig Hilfe für den technischen Alltag.

Software ist nicht industriell „ausreifbar". Denn die nächste Hardware-Verbesserung kommt oder droht, ehe das Software-Paket ausreichend überprüft ist. Das führt zum Ignorieren von Warnsignalen und zu anscheinend geringfügiger Nachlässigkeit, die sich dann bis zu den Ansätzen vorarbeitet. Man sitzt heute vor einem Computer, in welchem zwischen dem Bit-Verarbeitungsgeschehen und dem Bildschirm viele Transformationen stattfinden, die man nicht mehr durchschauen kann.

Es gibt keinen John von Neumann für all diese Diskrepanzen. Und man kommt auf den Verdacht, daß es für sie einen John von Neumann, einen Ordnung schaffenden Geist, überhaupt nicht geben kann.

Das ist ein unbefriedigender Abschluß. Aber ich habe ja das Glück, das Thema an die drei nächsten Generationen weitergeben zu können.

8. Post Scriptum - KYBERNETIK#

Die Kybernetik gehört nicht zum Thema der Veranstaltung und ich habe auch nicht gesprochen über sie. Aber zwei Diplomanten aus den 50er Jahren haben mir die Freude gemacht zu diesem Abend zu kommen, und ihnen zu Ehren seien ein paar Bemerkungen als Post Scriptum angefügt.

Professor Ernst Felix Petritsch war der Alte Herr der Nachrichtentechnik in den Jahren nach dem Krieg und ich war am Ende sein besonderer Assistent. Eine ganze Reihe von Absolventen, die nach 1938 das Land hatten verlassen müssen, kamen nach Wien und suchten ihre Technische Hochschule auf, die Nachrichtentechniker (Fernmeldetechniker") besuchten Prof. Petritsch und brachten Sonderdrucke oder Bücher mit. Und darunter war auch das Buch „Cybernetics" von Norbert Wiener [21].

Der Chef übergab mir am 15 JAN 1952 (mit einer Widmung) die damalige Rarität: es wäre eher etwas für mich als für ihn. Aber auch für mich war es eigentlich nichts - die darin vorgebrachte Mathematik war weit jenseits meiner Kenntnisse. Der einführende historische Rückblick, immerhin 30 Seiten, erregte mein Interesse für die Kybernetik und eine (nicht ganz leichte) Literatursuche zeigte mir bald eine Seite der Kybernetik, die mir sehr wohl zugänglich war, nämlich die Serie der kybernetischen Modelle, deren Anschaulichkeit viel mehr erreichte als Wieners (wie ich herausfand: aus seinen anderen Publikationen übernommene) Mathematik.

Also schritt ich an die Nachbildung und Weiterführung dieser Modelle, und ich bin, so viel ich weiß, der Einzige auf der Welt, der alle drei Arten wiederholte: den Automaten für den Bedingten Reflex, die Automatische Orientierung im Labyrinth und den Homöostaten: dazu kam noch wenigstens ein Spielautomat für ein vereinfachtes Mühlespiel: der Versuch, auf dem Mailüfterl ein Schachprogramm laufend zu machen, scheiterte, weil sich die ausführende Programmiererin nicht auf mein bescheidenes Ziel beschränken ließ, nur das Endspiel-Programm (Automat: König und Turm. Mensch: König) anzugehen, wie es der Spanische Automatenbauer Leonardo Torres v Ouevedo im Jahre 1912 mit rein mechanischen Mitteln realisiert hatte. Sie plagte sich um ein vollständiges Schachspiel-Programm und das war nicht zu machen.

Zwei der kybernetischen Modelle haben wir auf dem Mailüfterl programmiert und zu meinem Erstaunen waren diese Programme nicht schneller als die doch eher mechanischen Geräte. Aber das ist Schnee von gestern.

Schrifttum#

[1] ZEMANEK: Über die Erzeugung periodischer kurzer Impulse aus einer gegebenen Sinusschwingung.- Diolomarbeit. TH Wien 1944: 70pp
[2] H. ZEMANEK: Die Sprache des Ingenieurs und des Programmierers.- e&i 115 (1998) H.9. 434-437. H. ZEMANEK: Abkzgn. (Ein ernster Scherz), e&i 116 (1999) H.l. 4-6
[3] H. ZEMANEK: Abstract Architecture General Concepts for Systems Design.- In: Abstract Software Specifications. 1979. Copenhagen Winter School Proceedings (D. Biörner. Ed.) Lecture Notes in Computer Science 86. 1980: 554-563
[4] H. ZEMANEK: Gedanken zum Systementwurf. Ein von Gebäude und Computer generalisierter Architekturbegriff, der auch für Fahrzeuge und Verkehrssysteme nützlich sein könnte.- In: Zeugen des Wissens. 100 Jahre Automobil 1886-1986 Daimler-Benz AG (H. Maier-Leibnitz. Hrsg.) v. Hase & Koehler Verlag. Mainz 1986. XIX+1043DD. Pp 99-125
[5] VITRUV: Zehn Bücher über Architektur.- (C.V. Fensterbusch. Übers.) (das erste Buch ist ausreichend) Wissenschaftliche Buchgesellschaft. Darmstadt 1981. 585pp
[6] M. V. WILKES: Microprogramming and the Design of the Control Circuits in an Electronic Digital Computer.- Proc. Cambridge Phil. Soc. 49 (1953) 230-238
[7] W. L. van der POEL: The logical principles of some simple computers.- Dissertation. Univ of Amsterdam. 1956
[8] H. ZEMANEK: Mailüfterl, ein dezimaler Volltransistor-Rechenautomat.- Elektrotechnik und Maschinenbau 75 (1958) 453-463 H. ZEMANEK et al: Mailüfterl.- Digital Computer Newsletter 10 (1958) 37-49. H. ZEMANEK: Das Mailüfterl - ein österreichischer Aufbruch ins Computerzeitalter.- In: Patente. Marken. Muster. Märkte. Der gewerbliche Rechtschutz international (O. Raffeiner. Hrsg.). Manz'sche Verlagsbuchhandlung. Wien 1993: 197pp. p. 142-160 H. ZEMANEK: Mailüfterl - eine Retrospektive.- Elektronische Rechenanlagen 25 (1983) 6. 91-99
[9] I.L. AUERBACH: IFIP - The Early Years: 1960-1971.- p.81 In: A Ouarter Century of IFIP (H. Zemanek. Ed.) North Holland. Amsterdam 1986: 895+117pp. W.L. van der POEL: Some Notes on the History of ALGOL.- In: A Ouarter Century of IFIP (R. Zemanek. Ed.) Eisevier (North Holland). Amsterdam 1986: p 373-392
[10] H. ZEMANEK: Die algorithmische Formelsprache ALGOL.- Elektronische Rechenanlagen l (1959) 2. 72-79: 3 140-143. [11] P. LUCAS: Die Strukturanalyse von Formelübersetzern.- Elektronische Rechenanlagen 3 (1961)159-167
[12] COBOL, aber auch andere Sprachen wie FORTRAN etc.: R. L. WEXELBLAT: History of Programming Languages.- Academic Press. NY etc. 1981: 758pp
[13] P. LUCAS. K. WALK: On the Formal Definition of PL/L- Annual Review of Automatic Programming 6 (1969). 3. 105-133 [14] J.A.N. LEE: The Vienna Definition Language. A Generalization of Instruction Definitions.- SIGPLAN Symposium on Programming Language Definition. San Francisco. Aueust 1969
[15] P. WEGENER: The Vienna Definition Language.- Computing Surveys 4 (1972) 5-63
[16] P. LUCAS: Formal Semantics of Programming Languages: VOL.- IBM Journal of R&D 25(1981) 549-561
[17] C.A.R. HOARE: An Axiomatic Basis for Computer Programming.- Comm ACM 12 (1969)
[18] Revised Report on the Algorithmic Language ALGOL 68.- Acta Informatica 5 (1975)
[19] A. van WIJNGAARDEN: Generalized ALGOL.- In: Symbolic Languages in Data Processing. Proceedings of the ICC Symposium. Rome. 26-31 March 1962. Gordon & Breach. NY 1962: 275-283
[20] A. van WIJNGAARDEN: Languageless Programming-(Summary) In: Algorithms in Modern Mathematics and Computer Science. Proceedings Urgench Symposium 16-22 SEP
1979. 0.459. Lecturenotes m Computer Science. Vol. 122. Spinger Verlag Berlin 1981: 4870D Schrifttum zur Kybernetik
[21] N. WIENER: Cybernetics or Control and Communication in the Animal and in the Machine.- Technology Press. Cambridge. J. Wilev NY and Hermann & Cie. Paris 1948. N. WIENER: Kybernetik oder Regelung und Nachrichtenübertragung im Lebewesen und in der Maschine.- Econ Verlag. Düsseldorf 1963: 287pp
[22] H. ZEMANEK: Kybernetik.- Elektronische Rechenanlagen 6 (1964) H.4. 169-177

Bedingter Reflex (Künstliche Schildkröte)#

Während das erste Wiener Modell eine getreue Nachbildung von Walters „turtle" war, hat uns A.J. Anevan, ein Neurologe und Psychiater aus Ungarn, geholfen, das Modell auf zwei bedingte Reflexe, ihr Zusammenspiel und einige andere Zusätze (wie Schlaf- und Wachzustand) auszuweiten. Es wurden zwei Geräte gebaut, von denen eines dem finanzierenden Rockland Hospital NY übersandt wurde, und dann noch zwei transistorisierte Geräte, von denen eines auf der Weltausstellung 1967 in Montreal zu sehen war.

[23] LP. PAWLOW: Conditioned Reflexes - fG.V. Anreo. Transit. Dover Publications. NY 1960:43000
[24] W.G. WALTER: The Living Brain.- Duckworth. London 1953: 216pp
[25] E. EICHLER: Ein umweltabhängiger Automat.- Staatsprüfungsarbeit TU Wien 1954. E. EICHLER: Die Künstliche Schildkröte.- Radio Technik 31 (1955) No. 5/6. 173-179
[26] H. ZEMANEK. H KRETZ. A.J. ANGYAN: A Model for Neurological Functions.- In: Fourth London Symposium on Information Theory (C. Cherry. Ed.) Butterworth. London 1961:270-284

Orientierung im Labyrinth (Maus im Labvrinth)#

Das Wiener Modell hat 6x6 statt 5x5 Felder und fügt dem Originalmodell einen (codierten Ariadnefaden hinzu, mit dem die „Maus" im Labyrinth auch den Weg zurück findet.

[27] C.E. SHANNON: Presentation of a Maze Solving Machine.- Cybernetics. Transactions of the Eighth Conference on Cybernetics TMacv Foundation. H v Foerster. Ed.) NY 1951: 173-180
[28] R. EIER. H. ZEMANEK: Automatische Orientierung im Labyrinth.- Elektronische Rechenanlagen 2 (I960) No. 1. 23-31

Homöostase (Homöostat)#

Das Wiener Modell fügte zwei Demonstrationsbeispiele hinzu, ein Modellgesicht mit Mienenspiel und einen Zwei-Licht-Punkt Bildschirm, mit dem man auf „Katze und Maus" oder auf „zwei Boxer" einstellen kann.

[29] W.B. CANNON: The Wisdom of the Body (darin: HomeostasisY- London 1932
[30] W.R. ASHBY: Design for a Brain. The Origin of Adaptive Behaviour.- Chaoman&Hall. London 1952. 1960: 286pp. W.R. ASHBY: An Introduction to Cvbernetics.- Chaoman&Hall. London 1956: 295pp
[31] W.R. ASHBY: Einführung in die Kybernetik.- J.A. Huber. Übers. Suhrkamp Taschenbuch stw 34. Frankfurt 1974: 416pp
[32] A. HAUENSCHILD: Der Homöostat.- Staatsprüfungsarbeit an der TH Wien 1957: 63pp

Spiele#

[33] A.M. TURING: Digital Computers applied to Games.- In: Faster than Thought (E.V. BOWDEN: Ed.) Pitman & Sons. London 1953. 304-310
[34] H. ZEMANEK: Automaten und Denkprozesse.- In: Digitale Informationswandler (W. Hoffmann. Hrsg.Vieweg. Braunschweig 1962: 1-66
[35] H. ZEMANEK: (Der Schachspieler von Wolfgang von Kempelen.- Geschichte der Automaten IV. Elektronische Rechenanlagen 8 (1966) 2. 61-62
[36] H. SONNTAG : Relaisprogrammierung für ein einfaches Spiel.- Staatsprüfungsarbeit TU Wien 1957: 52opp+4pp Diaer&Abb
[37] ZEMANEK: Eine formale Sprache aus dem Jahre 1907 von Leonard Torres v Ouevedo zur Beschreibung von Maschinen. Elektronische Rechenanlagen 10 (1968). 2. 5-6

---

Austria-Forum Beiträge in ähnlichen Gebieten

• https://austria-forum.org/af/Wissenssammlungen/Essays/Kulturwandel_durch_Technik/Was_passiert_mit_unserer_Sprache_im_digitalen_Zeitalter
• https://austria-forum.org/af/Wissenssammlungen/Essays/Kulturwandel_durch_Technik/Da_gibts_kein_Dort