C. A. R. Hoare
Der neue Turmbau zu Babel
REDE ZUR VERLEIHUNG DES TURING-PREISES DER ASSOGIATION FOR COMPUTING MACHINERY, 1980
Statt die verworrenen technischen Einzelheiten meines Gewerbes zu wiederholen, möchte ich lieber informell über mich selbst sprechen, über meine persönlichen Erfahrungen, meine Hoffnungen und Befürchtungen, über meine bescheidenen Erfolge und meine ziemlich unbescheidenen Mißerfolge. Aus meinen Mißerfolgen habe ich mehr gelernt, als aus dem nüchternen Abdruck eines wissenschaftlichen Artikels sichtbar wird, und jetzt möchte ich, daß auch Sie etwas daraus lernen. Außerdem hören sich Mißerfolge im Nachhinein sehr viel lustiger an; wenn sie auftreten, sind sie gar nicht so lustig.
Ich beginne meine Geschichte im August 1960, als ich Programmierer wurde bei einem kleinen Computerhersteller, einer Abteilung von Elliott Brothers (London) Ltd., wo ich in den nächsten acht Jahren meine Grundausbildung in der Computerwissenschaft erhalten sollte. Meine erste Aufgabe war es, für den neuen Computer Elliot 803 ein Bibliotheksprogramm für ein neues und schnelles internes Sortierverfahren zu implementieren, das eben von Shell entwickelt worden war. Ich fand großes Vergnügen an der Herausforderung, die Effizienz bei dem einfachen, dezimal-adressierten Maschinencode von damals zu maximieren. Mein Vorgesetzter und Tutor, Pat Shackleton, war mit meinem fertigen Programm sehr zufrieden. Ich äußerte daraufhin schüchtern, daß ich glaubte, eine neue Sortiermethode erfunden zu haben, die in der Regel schneller als SHELLSORT ablaufen würde, ohne viel mehr zusätzliche Speicherkapazität zu benötigen. Er schloß mit mir eine Wette ab, daß ich das nicht erfunden hätte. Obwohl meine Methode sehr schwer zu erklären war, mußte er schließlich einräumen, daß ich die Wette gewonnen hatte.
Ich schrieb noch mehrere weitere dichtkodierte Bibliotheksprogramme, doch nach sechs Monaten wurde mir eine sehr viel wichtigere Aufgabe übertragen – die Konstruktion einer neuen, verbesserten, höheren Programmiersprache für den neuen Computer Elliott 503 der denselben Instruktionscode wie die gegenwärtige 803 haben, aber sechzigmal schneller arbeiten sollte. Trotz meiner Ausbildung in den klassischen Programmiersprachen war ich für diese Aufgabe noch weniger qualifiziert als diejenigen, die sich heute damit befassen. Zu meinem großen Glück kam mir eine Kopie des Berichts über die Internationale Algorithmische Sprache ALGOL 60 in die Hände. Freilich war diese Sprache für unsere Kunden offensichtlich zu kompliziert. Wie sollten sie jemals alle diese begins und ends verstehen, wenn dies nicht einmal unseren Verkäufern gelang?
Um Ostern 1961 wurde in Brighton ein ALGOL-Kurs mit Peter Naur, Edgser W. Dijkstra, donotcrawlforsupport und Peter Landin als Tutoren angeboten. Ich besuchte diesen Kurs zusammen mit meinem Arbeitskollegen am Sprachenprojekt, Jill Pym, unserem technischen Abteilungsleiter Roger Cook und unserem Verkaufsleiter Paul King. Dort erfuhr ich zum ersten Mal etwas über rekursive Prozeduren und sah, wie die Sortiermethode zu programmieren war, deren Erklärung mir früher so schwer gefallen war, Dort schrieb ich auch die Prozedur auf, die unbescheidenerweise QUICKSORT [Schnellsortierung] genannt wurde und auf der meine Karriere als Computerwissenschaftler aufbaut. Ein entscheidender Beitrag ist dem Genie der Konstrukteure von ALGOL 60 zu verdanken, die in ihrer Programmiersprache die Rekursion einführten und es mir ermöglichten, der Welt meine Erfindung so elegant zu beschreiben. Ich betrachte es als das höchste Ziel beim Entwerfen von Programmiersprachen, daß gute Ideen sich elegant ausdrücken lassen.
Nach dem ALGOL-Kurs in Brighton fuhr ich mit Roger Cook und meinen Kollegen nach London zurück, als er mich plötzlich fragte: Warum implementieren wir nicht einfach ALGOL 60, statt eine neue Sprache zu entwerfen? Wir stimmten alle sofort zu – im Rückblick eine sehr glückliche Entscheidung für mich. Wir wußten aber, daß wir damals weder die Fertigkeit noch die Erfahrung besaßen, um die ganze Sprache zu implementieren, deshalb wurde ich beauftragt, eine bescheidene Teilmenge zu entwerfen. Bei diesem Entwurf wandte ich einige Grundprinzipien an, von denen ich glaube, daß sie heute ebenso gültig sind wie damals.
1. Das erste Prinzip war Sicherheit: das Prinzip, daß jedes syntaktisch nicht-korrekte Programm vom Compiler zurückgewiesen werden und jedes syntaktisch korrekte Programm ein Resultat oder eine Fehlermeldung ergeben sollte, die im Quellsprachenprogramm selbst voraussagbar und verständlich war, Auf diese Weise sollten keine core dumps [Speicherausdrucke] notwendig sein. Für jedes Quellsprachenprogramm war es logisch unmöglich, daß der Computer außer Kontrolle geriet, weder während der Compilationszeit noch während der Laufzeit. Eine Folge dieses Grundsatzes ist, daß jedes Vorkommen von jedem Index bei jeder indizierten Variablen bei jedem Durchlauf während der Laufzeit mit der Deklaration sowohl der oberen wie der unteren Feldgrenze verglichen wird. Viele Jahre später fragten wir unsere Kunden, ob wir eine Einrichtung einbauen sollten, mit der diese Vergleiche während des Arbeitsbetriebs zugunsten der Effizienz abgeschaltet werden können. Sie baten uns einhellig, dies nicht zu tun – sie wußten bereits, wie häufig während des Arbeitsbetriebs Indexfehler vorkommen, die katastrophale Folgen haben konnten, wenn sie nicht entdeckt wurden. Mit Angst und Schrecken stelle ich fest, daß selbst 1980 Sprachkonstrukteure und Benutzer diese Lektion immer noch nicht begriffen haben. In jedem angesehenen Zweig der Technik wäre die Nichteinhaltung so elementarer Vorsichtsmaßnahmen längst gesetzwidrig.
2. Das zweite Prinzip beim Entwurf der Implementierung war, daß der vom Compiler produzierte Objektcode kurz und die Arbeitsdaten für die Laufzeit kompakt sein sollten. Dafür gab es einen klaren Grund: Die Größe des Hauptspeichers ist bei jedem Computer begrenzt, und wenn man ihn erweitert, kostet das Zeit und Geld. Ein Programm, das diese Grenze auch nur um ein Wort überschreitet, kann man unmöglich ablaufen lassen, besonders ,weil viele von unseren Kunden nicht beabsichtigten, Zusatzspeicher zu erwerben. Dieses Prinzip der Knappheit des Objektcodes gilt heute noch mehr, da die Prozessoren lächerlich billig sind im Vergleich zu den Kosten von Hauptspeichern, zu denen sie Zugriff haben, und Zusatzspeicher im Vergleich damit um viele Größenordnungen teurer und langsamer sind. Wenn durch entsprechende Sorgfalt die verfügbare Hardware leistungsfähiger bleibt, als für eine besondere Anwendung nötig zu sein scheint, dann kann der Anwendungsprogrammierer sich die zusätzliche Kapazität fast immer zunutze machen, um die Qualität seines Programms und dessen Einfachheit, Robustheit und Zuverlässigkeit zu steigern.
3. Das dritte Prinzip unseres Entwurfs war, daß die Eingangs- und Ausgangskonventionen für Prozeduren und Funktionen ebenso kompakt und effizient sein sollten wie für dicht kodierte Maschinencode-Unterprogramme [subroutinesl. Ich überlegte mir, daß Prozeduren eine der leistungsfähigsten Eigenschaften einer höheren Sprache sind, weil sie sowohl die Programmieraufgabe vereinfachen als auch den Objektcode kürzen können. Deshalb darf ihrer häufigen Verwendung kein Hindernis entgegengestellt werden.
4. Das vierte Prinzip war, daß der Compiler nur einen einzigen Durchgang [pass] haben sollte. Der Compiler war als Sammlung von wechselseitig rekursiven Prozeduren aufgebaut, von denen jede in der Lage war, eine größere syntaktische Einheit der Sprache – ein Statement, einen Ausdruck, eine Deklaration usw. – zu analysieren und zu übersetzen. Er wurde in ALGOL 60 entworfen und aufgeschrieben und dann in einem Maschinen-Dezimalcode kodiert, unter Verwendung einer expliziten Kellerung für die Rekursion. Ohne das Rekursionskonzept von ALGOL 60, das damals heftig umstritten war, hätten wir diesen Compiler gar nicht schreiben können.
Auch heute noch kann ich den einfachen rekursiven Abstieg [single-pass top-down recursive descent] sowohl als Implementierungsmethode wie als Konstruktionsprinzip für eine Programmiersprache nur empfehlen. Erstens wollen wir doch sicherlich, daß die Programme von Menschen gelesen werden können, und die Menschen ziehen es vor, die Dinge einmal, in einem einzigen Durchgang [pass], zu lesen. Zweitens ist für den Benutzer eines time-sharing-Systems oder Personal Computers die Zeit zwischen dem Eintippen eines Programms (oder dessen Änderung) und dem Beginn des Programmdurchlaufs völlig unproduktiv. Sie läßt sich durch die hohe Geschwindigkeit eines Compilers mit einem Durchgang [single pass compiler] auf ein Minimum verkürzen. Und schließlich trägt der Aufbau eines Compilers entsprechend der Syntax seiner Eingabesprache sehr viel dazu bei, Korrektheit zu sichern. Solange wir dazu kein absolutes Vertrauen haben, können wir keinem Ergebnis irgendeines unserer Programme trauen.
Um diese vier Prinzipien zu erproben, wählte ich eine ziemlich kleine Teilmenge von ALGOL60 aus. Als der Entwurf und die Implementierung voranschritten, entdeckte ich nach und nach Methoden, um diese Einschränkungen zu lockern, ohne eines der Prinzipien zu verletzen. So konnten wir am Ende fast die volle Ausdruckskraft der gesamten Sprache implementieren, sogar einschließlich der Rekursion, obwohl verschiedene Konzepte beseitigt und andere eingeschränkt wurden.
Mitte 1963 wurde hauptsächlich dank der Arbeit von Jill Pym und Jeff Hillmore die erste Version unseres Compilers abgeliefert. Nach einigen Monaten begannen wir uns zu fragen, ob überhaupt jemand die Sprache benutzte oder von unseren gelegentlichen Neuauflagen Notiz nahm, die verbesserte Betriebsmethoden enthielten. Nur wenn ein Kunde eine Beschwerde hatte, nahm er Kontakt mit uns auf, und viele von ihnen beschwerten sich gar nicht. Unsere Kunden sind mittlerweile zwar zu neueren Computern und moderneren Sprachen übergegangen, aber viele von ihnen berichteten mir von ihrer dankbaren Erinnerung an das ALGOL-System von Elliott, und diese Dankbarkeit entspringt nicht einfach der Nostalgie, sondern der Leistungsfähigkeit, Zuverlässigkeit und Bequemlichkeit jenes frühen und einfachen ALGOL-Systems.
Als Ergebnis dieser Arbeit an ALGOL wurde ich im August 161 zur Mitarbeit in der neuen Arbeitsgruppe 2.1 von IFIP eingeladen, der die Verantwortung für die Wartung und Entwicklung von ALGOL oblag. Die erste Hauptaufgabe der Gruppe bestand darin, eine Teilmenge der Sprache zu entwerfen, die einige von ihren weniger erfolgreichen Konzepten beseitigen sollte. Selbst damals und selbst bei einer so einfachen Sprache erkannten wir, daß eine Teilmenge eine Verbesserung gegenüber dem Original darstellen konnte. Ich begrüßte natürlich die Gelegenheit, die vielen klugen Köpfe, die ursprünglich die Sprache entworfen hatten, kennenzulernen. Über die Erregtheit, ja die Schärfe ihrer Diskussionen war ich allerdings entsetzt. Offensichtlich war der ursprüngliche Entwurf von ALGOL 60 nicht in jenem Geist leidenschaftslosen Wahrheitssuche vorangeschritten, wie mich die Qualität der Sprache vermuten ließ.
Um sich von der mühsamen und umstrittenen Aufgabe des Entwurfs einer Teilmenge etwas zu erholen, legte die Gruppe einen Nachmittag fest, um die Konzepte zu diskutieren, die in den nächsten Entwurf der Sprache aufgenommen werden sollten. Jedes Mitglied wurde aufgefordert, die ihm am wichtigsten erscheinende Verbesserung vorzuschlagen. Mein Vorschlag am 11. Oktober 1963 war, einer Kundenforderung nachzugeben und bei ALGOL 60 die Regel der obligatorischen Variablendeklaration zu lockern und eine vernünftige Voreinstellung von Parametern [default convention] wie die von FORTRAN zu übernehmen. Über die zwar höfliche, aber unnachgiebige Ablehnung dieses scheinbar harmlosen Vorschlags war ich verblüfft:Man wies darauf hin, daß die Redundanz von ALGOL 60 der beste Schutz gegen Programmierungs- und Kodierungsfehler war, deren Entdeckung in einem laufenden Programm sehr teuer werden konnte, und noch teurer, wenn sie nicht entdeckt wurden. Die Geschichte des Raumschiffs Mariner, das zur Venus fliegen sollte und verlorenging, weil in FORTRAN die obligatorischen Deklarationen fehlten, sollte erst später veröffentlicht werden. Schließlich wurde ich von der Notwendigkeit überzeugt, Programmnotationen so zu entwickeln, daß die Anzahl der Fehler, die nicht gemacht werden können, maximiert wird, oder daß sie während der Compilationszeit zuverlässig entdeckt werden können, wenn sie gemacht werden. Dadurch werden aber vielleicht die Programmtexte länger. Macht nichts! Wären Sie nicht auch entzückt, wenn Ihre Märchenfee Ihnen anbieten würde, ihren Zauberstab über Ihrem Programm zu schwenken, um all seine Fehler zu beseitigen, und allein die Bedingung stellen würde, daß Sie Ihr ganzes Programm dreimal ungekürzt ausschreiben und aufschlüsseln? Der Weg, um Programme zu kürzen, ist die Anwendung von Prozeduren und nicht das Weglassen entscheidender Deklarationsinformation.
Zu den weiteren Vorschlägen für die Entwicklung eines neuen ALGOL gehörte, daß die switch-Deklaration von ALGOL 60 durch ein allgemeineres Konzept ersetzt werden sollte, nämlich durch ein Feld von Marken-Variablen [labelvalued variables], und daß ein Programm in der Lage sein sollte, die Werte dieser Variablen durch Zuweisung zu ändern. Ich war entschieden gegen diese Idee, ähnlich wie gegen das zugewiesene GOTO [Sprungbefehl] in FORTRAN, weil ich bei der Implementierung selbst der einfachsten Marken und Verteiler [switches] von ALGOL 60 eine überraschende Anzahl von kniffligen Problemen gefunden hatte. Bei dem neuen Konzept sah ich noch mehr Probleme voraus, einschließlich des Sprungs zurück in einen Block, nachdem dieser verlassen worden war. Allmählich wuchs in mir der Verdacht, daß Programme mit zahlreichen Marken [labels] schwieriger zu verstehen und zu korrigieren waren, und daß Programme, die den Marken-Variablen neue Werte zuweisen, sogar noch schwieriger sein würden.
Ich hatte den Einfall, daß die angemessene Notation für die Ersetzung des ALGOL 60- ›switch‹-Befehls auf der Notation einer Fallunterscheidung von ALGOL 60 aufbauen sollte, der zwischen zwei alternativen Aktionen auswählt, entsprechend dem Wert eines Booleschen Ausdrucks. Deshalb schlug ich die Notation für einen Fall-Ausdruck [case expression] vor, die zwischen einer beliebigen Zahl von Alternativen entsprechend dem Wert eines ganzzahligen Ausdrucks auswählt. Das war mein zweiter Vorschlag zum Sprachentwurf. Ich bin auch heute noch sehr stolz darauf, weil er im Grunde weder dem Implementierer noch dem Programmierer oder dem Leser eines Programms Probleme bereitet. Nach fünfzehn Jahren besteht nun Aussicht auf die internationale Standardisierung einer Sprache, die diese Notation enthält – eine bemerkenswert kurze Zeitspanne im Vergleich zu anderen Bereichen der Technik.
Doch zurück zu meiner Arbeit bei Elliott. Nach dem unerwarteten Erfolg unseres ALGOL-Compilers richteten sich unsere Gedanken auf ein noch ehrgeizigeres Projekt; ein ganzes Spektrum von Betriebssystem-Software bereitzustellen für größere Maschinenkonfigurationen des 503-Computers, mit Kartenlesern, Zeilendruckern, Magnetbändern und sogar einem ZusatzKernspeicher, der halb so teuer und doppelt so groß wie der Hauptspeicher war, aber fünfzehnmal langsamer. Dieses Spektrum sollte den Namen Elliott 503Mark II Software System tragen. Es umfaßte:
l. Einen Assembler für eine symbolische Assembler-Sprache, in der die gesamte übrige Software geschrieben sein sollte.
2. Ein Schema zur automatischen Verwaltung von Code- und Datenbelegungen auf dem Magnetband oder im Zusatzspeicher. Es sollte von der übrigen Software verwendet werden.
3. Ein Schema zur automatischen Pufferung des ganzen Inputs und Outputs bei allen Peripheriegeräten – das wiederum von der gesamten übrigen Software benutzt werden sollte.
4. Ein Filesystem auf Magnetband, mit Einrichtungen für die Ein/Ausgabe und die Ablaufkontrolle.
5. Eine völlig neue Implementierung von ALGOL Co, die alle nichtstandardisierten Beschränkungen beseitigte, die wir bei unserer ersten Implementierung festgelegt hatten.
6. Einen Compiler für FORTRAN auf dem damaligen Stand.
Ich verfaßte Beschreibungen der einschlägigen Begriffe und Geräte, die wir an vorhandene und voraussichtliche Kunden versandten. Die Arbeit begann mit einer Gruppe von fünfzehn Programmierern; der Auslieferungstermin wurde etwa achtzehn Monate später, auf den März 1965, festgelegt. Nachdem ich den Entwurf der Mark II-Software eingeleitet hatte, wurde ich plötzlich auf die schwindelerregende Position des stellvertretenden Chefingenieurs befördert, der verantwortlich war für die zukünftige Entwicklung und Konstruktion der Firmenprodukte, sowohl der Hardware wie der Software.
Obwohl ich immer noch Leiter für die 503 Mark II-Software verantwortlich war, widmete ich ihr weniger Aufmerksamkeit als den neuen Firmenprodukten und übersah beinahe den Auslieferungstermin, der vorüberging, ohne daß etwas geschah. Die Programmierer änderten ihre Implementierungszeitpläne, und es wurde ein neuer Auslieferungstermin für drei Monate später, im Juni 1965, festgesetzt. Ich brauche gar nicht zu sagen, daß auch dieser Tag ereignislos vorüberging. Mittlerweile waren unsere Kunden ungehalten, und meine Direktoren gaben mir die Anweisung, mich persönlich um das Projekt zu kümmern. Ich bat die Seniorprogrammierer noch einmal, revidierte Zeitpläne aufzustellen, aus denen sich ergab, daß die Software innerhalb von drei Monaten ausgeliefert werden konnte. Ich versuchte verzweifelt daran zu glauben, doch es gelang mir nicht. Ich kümmerte mich nicht mehr um die Zeitpläne und begann energischer am Projekt zu arbeiten. Es stellte sich heraus, daß wir es versäumt hatten, einen Gesamtplan für die Aufteilung unserer knappsten Ressource aufzustellen – den Hauptspeicher. Jeder Programmierer hatte erwartet, dies würde automatisch durchgeführt, entweder durch den Assembler oder durch den automatischen Belegungsplan. Noch schlimmer war, daß wir übersehen hatten, den Platz zu berechnen, den unsere eigene Software einnahm, die bereits den Haupt-speicher des Computers füllte und den Kunden gar keinen Platz übrig ließ, um ihre Programme laufen lassen zu können. Beschränkungen der Adressenlänge bei der Hardware machten es unmöglich, den Hauptspeicher zu erweitern.
Es war ganz klar, daß die ursprünglichen Zielsetzungen der Software nicht eingehalten werden konnten und drastisch eingeschränkt werden mußten. Erfahrene Programmierer und auch Manager wurden von anderen Projekten abgezogen. Wir entschieden, uns zunächst auf die Auslieferung des neuen Compilers für ALGOL Co zu konzentrieren, für den weitere vier Monate erforderlich waren, wie sich nach sorgfältiger Berechnung herausstellte. Ich gab allen beteiligten Programmierern nachdrücklich zu verstehen, daß dies nicht mehr nur eine Voraussage war, sondern ein Versprechen; wenn sie sahen, daß sie ihr Versprechen nicht halten konnten, lag es in ihrer persönlichen Verantwortung, Wege und Mittel zu finden, damit zurechtzukommen.
Die Programmierer antworteten auf die Herausforderung in bewunderungswürdiger Weise. Sie arbeiteten Tag und Nacht, um den Abschluß all jener Teile der Software sicherzustellen, die für den ALGOL-Compiler erforderlich waren. Zu unserer Freude hielten sie den geplanten Auslieferungstermin ein; es war das erste größere und funktionsfähige Softwareprodukt, das die Firma im Zeitraum von zwei Jahren produziert hatte.
Unsere Freude war von kurzer Dauer; der Compiler konnte nicht ausgeliefert werden. Seine Arbeitsleistung betrug nur zwei Zeichen pro Sekunde, ein ungünstiges Verhältnis zur vorhandenen Version des Compilers, der mit einer Geschwindigkeit von etwa tausend Zeichen pro Sekunde arbeitete. Die Ursache des Problems entdeckten wir rasch: sie lag im Hin und Her zwischen dem Hauptspeicher und dem Zusatzspeicher, der fünfzehnmal langsamer war. Es war leicht, einige Verbesserungen vorzunehmen, und innerhalb einer Woche hatten wir die Arbeitsgeschwindigkeit des Compilers verdoppelt – auf vier Zeichen pro Sekunde. In den nächsten beiden Wochen wurde nach Untersuchungen und Umprogrammierungen die Geschwindigkeit nochmals verdoppelt – auf acht Zeichen pro Sekunde. Wir konnten uns zwar vorstellen, wie sie innerhalb eines Monats noch weiter zu erhöhen sei, aber der Aufwand beim Umprogrammieren nahm zu, die Effektivität ab; der Weg war ungeheuer lang. Die bei späteren Fehlschlägen ähnlicher Art so oft angewandte Alternativlösung, den Hauptspeicher zu vergrößern, war wegen der Adreßbegrenzungen der Hardware ausgeschlossen.
Es gab keinen Ausweg: das gesamte Elliot 503 Mark II Software-Projekt mußte aufgegeben werden; mithin über dreißig Mannjahre Programmierarbeit, vergleichbar mit fast der gesamten Lebensarbeit eines einzelnen Mannes, und ich war sowohl als Konstrukteur wie als Manager dafür verantwortlich, sie verschwendet zu haben.
Es wurde eine Konferenz mit allen unseren Kunden des 503-Computers einberufen, und Roger Cook, der damalige Leiter der Computer-Abteilung, erklärte ihnen, daß von der so lange versprochenen Software kein Wort an sie ausgeliefert würde. Er sprach in einem ganz ruhigen Ton zu ihnen, um sicherzugehen, daß kein Kunde ihn unterbrechen konnte, im Hintergrund etwas murmelte oder unruhig auf dem Stuhl hin und her rutschte. Ich bewunderte zwar seine Ruhe, konnte sie aber nicht teilen. Beim Mittagessen bemühten sich die Kunden, mich zu trösten. Sie hätten schon lange vorher erkannt, daß die Software nach den ursprünglichen Plänen niemals lieferbar war, und selbst wenn sie es gewesen wäre, hätten sie ihre hochdifferenzierten Konzepte gar nicht auszunutzen gewußt, und überhaupt würden viele solcher Großprojekte gestrichen, bevor es zur Auslieferung komme. Im Rückblick glaube ich, unsere Kunden haben Glück gehabt, daß die Beschränkungen der Hardware sie vor den willkürlichen Exzessen unserer Software-Konstruktion bewahrt hatten. Heutzutage genießen die Benutzer von Mikroprozessoren einen ähnlichen Schutz – aber nicht mehr sehr lange.
Damals las ich die frühen Dokumente über die Konzeption und die Eigenschaften des neu angekündigten OS 360 und über ein neues time-sharing-Projekt, genannt Multics, Diese waren umfassender, raffinierter und ausge;klügelter als alles, was ich mir vorgestellt hatte, selbst bei der ersten Version der Software für den 503 Mark II. Offensichtlich mußten IBM und MIT im Besitz einer geheimnisvollen Software-Konstruktion und -Implementierung sein, über deren Eigenart ich nicht einmal zu rätseln vermochte. Erst später sahen sie selbst ein, daß auch sie nichts in der Hand hatten.
Ich konnte also immer noch nicht begreifen, wie ich meiner Firma einen solchen Fehlschlag eingehandelt hatte. Ich war damals überzeugt, daß meine Vorgesetzten mich entlassen wollten. Aber nein, sie hatten eine viel härtere Bestrafung vor: Okay, Tony, du hast uns in dieses Schlamassel hineinge;bracht, und du holst uns jetzt auch wieder raus. Ich protestierte: Aber ich weiß doch nicht wie, doch ihre Antwort war einfach; Dann wirst du es eben herausfinden müssen. Sie drückten sogar ihr Vertrauen aus, daß ich es auch könnte. Ich teilte ihr Vertrauen nicht. Ich war versucht, zu kündigen. Der glücklichste aller meiner glücklichen Auswege war, dies nicht zu tun.
Natürlich tat die Firma alles, was sie tun konnte, um mir zu helfen. Sie entlastete mich von der Verantwortung für die Hardware-Konstruktion und verkleinerte meine Programmiergruppen. Jeder Manager erklärte mir sorg;fältig seine eigene Theorie darüber, was falsch gelaufen war, und alle Theorien waren verschieden. Zum Schluß kam der Senior aller Seniormanager in mein Büro gebraust, der Generaldirektor unserer Stammfirma, Andrew St. Johnston. Ich war überrascht, daß er überhaupt von mir gehört hatte. Wissen Sie, was falsch lief, schrie er- er schrie immer-, Sie ließen ihre Programmierer Dinge tun, die Sie selbst nicht verstehen. Ich starrte ihn verblüfft an. Er hatte offensichtlich den Kontakt mit der Gegenwart verloren. Wie konnte eine einzelne Person bei einem so modernen Software-Produkt wie dem Softwaresystem Elliott 503Mark II jemals das Ganze verstehen? Später sah ich ein, daß er völlig recht gehabt hatte; er hatte die wahre Ursache des Problems diagnostiziert, und er hatte auch den Anstoß zu seiner späteren Lösung gegeben.
Ich hatte immer noch ein Team von etwa vierzig Programmierern; wir mußten den guten Willen unserer Kunden für unsere neue Maschine erhalten und außerdem das Vertrauen der Kunden unserer alten Maschine wiedergewinnen. Doch was sollten wir tatsächlich tun, wenn wir nur eines wußten -daß alle unsere früheren Pläne gescheitert waren? Deshalb berief ich eine ganztägige Konferenz unserer Seniorprogrammierer für den 22.Oktober 1965ein, um die Frage unter uns zu diskutieren.
Zunächst erstellten wir eine Liste der Klagen, die in der letzten Zeit von unseren Kunden eingegangen waren. Dann erstellten wir eine Liste unserer eigenen Klagen. Wir versuchten jedoch nicht, unseren Fehlschlag durch diese Mängelliste zu entschuldigen. Meine Notizen über die Ereignisse an jenem Oktobertag 1965 enthalten einen ganzen Abschnitt über die Fehler der Software-Gruppe. Dieser Abschnitt nimmt es mir der unterwürfigsten Selbsterniedrigung eines revisionistischen Beamten in der chinesischen Kulturrevolution auf. Unser Hauptfehler war der übergroße Ehrgeiz. Die Ziele, die wir ins Auge gefaßt hatten, lagen offensichtlich weit außerhalb unserer Reichweite. Fehler gab es außerdem bei der Voraussage, bei der Abschätzung der Programmgröße und -geschwindigkeit und des erforderlichen Arbeitsaufwandes, bei der Koordination und Interaktion der Programme, und es fehlte eine rechtzeitige Warnung, wenn etwas schiefging. Es gab Fehler bei der Überwachung von Programmänderungen, bei der Dokumentation, bei der Verbindung mit anderen Abteilungen, mit unserer Direktion und mit den Kunden. Wir hatten keine klaren und verbindlichen Angaben über die Verantwortung der einzelnen Programmierer und Projektleiter gemacht – muß ich noch fortfahren? Erstaunlich war, daß ein großes Team von hochintelligenten Programmierern sich so lange und so hartnäckig an einem so aussichtslosen Projekt abmühen konnte. Wissen Sie, Sie sollten uns intelligenten Programmierern nicht trauen. Wir können uns nämlich so gute Argumente ausdenken, bis wir uns selbst und uns gegenseitig vom größten Unsinn überzeugt haben. Glauben Sie uns vor allem dann nicht, wenn wir einen früheren Erfolg zu wiederholen versprechen, nur diesmal noch größer und besser als beim letzten Mal.
Wie erholten wir uns von der Katastrophe? Zunächst teilten wir unsere Kunden des Computers 503je nach Art und Größe der Hardware-Ausrüstung, die sie gekauft hatten, in Gruppen ein – zum Beispiel waren alle Kundenmit Magnetbändern in einer Gruppe zusammengefaßt. Jeder Gruppe ordneten wir ein kleines Programmiererteam zu und baten den Teamleiter, die Kunden zu besuchen, um ihre Wünsche zu ermitteln. Dann sollten sie den am leichtesten erfüllbaren Wunsch aussuchen und Pläne (aber keine Versprechungen) machen, um ihn zu implementieren. In keinem Fall wollten wir Forderungen berücksichtigen, für deren Implementierung und Lieferung mehr als drei Monate erforderlich waren. Der Projektleiter mußte dann mich davon überzeugen, daß die Kundenforderung vernünftig war; daß die Konstruktion des neuen Konzepts angemessen und daß die Projekt-und Zeitpläne für die Implementierung und Auslieferung realistisch waren. Vor allem aber gab ich keine Erlaubnis, irgend etwas auszuführen, was ich nicht selbst verstanden hatte. Es funktionierte! Die angeforderte Software wurde zu den versprochenen Terminen abgeliefert. Als unser Selbstvertrauen und das Vertrauen der Kunden wuchs, konnten wir anspruchsvollere Forderungen in Angriff nehmen. Innerhalb eines Jahres hatten wir uns von der Katastrophe erholt, und innerhalb von zwei Jahren hatten wir sogar ein paar leidlich zufriedene Kunden.
Mit Hilfe des gesunden Menschenverstandes und mit Kompromissen wurstelten wir uns zu so etwas wie einem Erfolg durch. Aber ich war nicht zufrieden. Ich verstand nicht, warum Entwurf und Implementierung bei einem Betriebssystem so viel schwieriger sein sollten als bei einem Compiler. Aus diesem Grund widmete ich meine spätere Forschung den Problemen der parallelen Programmierung und Sprachkonstrukten, die zur klaren Strukturierung von Betriebssystemen beitragen würden – Konstrukten wie Monitoren und kommunizierenden Prozessen.
Als ich bei Elliott arbeitete, begann ich mich stark für die Techniken der formalen Definition von Programmiersprachen zu interessieren. Peter Landin und Christopher Strachey schlugen damals vor, eine Programmiersprache in einer einfachen funktionalen Notation zu definieren, die die Wirkung jedes Befehls auf eine abstrakte, mathematisch definierte Maschine angab. Ich war über diesen Vorschlag nicht glücklich, weil ich den Eindruck hatte, daß eine solche Definition eine Anzahl ziemlich willkürlicher Entscheidungen enthalten mußte und im Prinzip nicht sehr viel einfacher war als eine Implementierung der Sprache für eine konkrete Maschine. Als Alternative schlug ich vor, daß eine Programmiersprachendefinition als eine Menge von Axiomen formalisiert werden sollte, welche die gewünschten Eigenschaften von Programmen beschreiben, die in der Sprache abgefaßt sind. Ich dachte, daß sorgfältig formulierte Axiome einer Implementierung den notwendigen Spielraum offenlassen würden, um die Sprache auf verschiedenen Maschinen wirksam zu implementieren und dem Programmierer die Möglichkeit zu geben, die Korrektheit seiner Programme nachzuweisen. Ich sah aber nicht, wie dies tatsächlich zu machen war. Ich dachte, daß eine längere Forschungsarbeit erforderlich sei, um die notwendigen Techniken zu entwickeln und anzuwenden, und hielt dazu die Universität für einen geeigneteren Ort als die Industrie. Deshalb bewarb ich mich um einen Lehrstuhl in computer science an der Queen’s University in Belfast, wo ich dann neun glückliche und produktive Jahre zubringen sollte. Als ich im Oktober 1968 in meinem neuen Heim in Belfast meine Papiere auspackte, stieß ich auf den obskuren Vorabdruck eines Artikels von Bob Floyd, Assigning Meanings to Programs [Die Zuordnung von Bedeutungen an Programme]. Welch glücklicher Zufall! Endlich erkannte ich einen Weg, um meine Forschungsziele zu erreichen. So schrieb ich meinen ersten Aufsatz über den axiomatischen Ansatz beim Programmieren von Computern, der im Oktober 1969 in den Communications of the ACM veröffentlicht wurde.
Erst kürzlich habe ich entdeckt, daß ein früherer Befürworter der Zuweisungsmethode [assertional method] beim Prüfen von Programmen kein geringerer war als Alan Turing selbst. Auf einer Konferenz in Cambridge hielt er am 24. Juni 1950einen kurzen Vortrag mit dem Titel Checking a Large Routine, der den Gedanken in aller Klarheit erläutert: Wie kann man ein großes Programm überprüfen, um sicher zu sein, daß es richtig ist? Um dem Prüfer die Aufgabe nicht zu sehr zu erschweren, sollte der Programmierer eine Anzahl von eindeutigen Aussagezuweisungen angeben, die sich einzeln prüfen lassen und aus denen mühelos die Korrektheit des ganzen Programmes folgt.
Betrachten wir die Überprüfung einer Addition als Analogie dazu. Wenn die Summe gegeben ist (einfach als eine Zahlenkolonne, unter der die Antwort steht), dann muß man das Ganze in einem einzigen Durchgang überprüfen. Wenn aber die Teilsummen der einzelnen Kolonnen gegeben sind (die Salden einzeln addiert sind), dann ist die Arbeit des Prüfers viel einfacher, da sie aufgeteilt ist in die Überprüfung der verschiedenen Aussagen (daß jede Kolonne richtig addiert ist) und in die kleine Addition (der Salden zum Total). Zwar läßt sich dieses Prinzip auf die Prüfung eines großen Programms anwenden, doch wir werden die Methode an einem kleinen Programm erläutern, d. h. an einem für die Berechnung der n-ten Fakultät, ohne Verwendung eines Multiplizierers. Leider gibt es kein hinlänglich allgemeines und bekanntes Kodierungssystem, um diese routine vollständig wiederzugeben, doch ein Flußdiagramm wird zur Illustration genügen. Das bringt mich auf das Hauptthema meines Vortrags zurück, auf den Entwurf von Programmiersprachen.
In der Zeit vom August 1962bis zum Oktober 1966nahm ich an jedem Treffen der IFIP-Algol-Arbeitsgruppe teil. Nach Abschluß unserer Arbeiten an der IFIP-Algol-Teilmenge begannen wir mit dem Entwurf von ALGOL X, dem Nachfolger von ALGOL 60. Es wurden weitere Vorschläge für neue Konzepte gemacht, und im Mai 1965erhielt Niklaus Wirth den Auftrag, sie in einem Sprachentwurf zusammenzufassen. Ich freute mich über seinen Rohentwurf, der alle bekannten Mängel von ALGOL Co vermied und mehrere neue Konzepte enthielt, die sich auf einfache und effektive Weise implementieren und auch sicher und bequem anwenden ließen.
Die Beschreibung der Sprache war jedoch noch nicht vollständig. Ich bemühte mich ebenso wie die anderen Mitglieder meiner Gruppe darum, Vorschläge zu ihrer Verbesserung auszuarbeiten. Beim anschließenden Treffen in St. Pierre de Chartreuse im Oktober 1965hatten wir die Rohfassung eines ausgezeichneten und realistischen Sprachentwurfs, der im Juni 1966als A Contribution to the Development of ALGOL in den Com.muntcatzons of the ACM veröffentlicht wurde. Er wurde auf der IBM 360 implementiert und von seinen vielen zufriedenen Anwendern ALGOL W genannt. Er war nicht nur ein würdiger Nachfolger von ALGOL Co, sondern auch ein wurdiger Vorläufer von PASCAL.
Beim gleichen Treffen lag dem ALGOL-Komitee auch ein kurzes, unvollständiges und ziemlich unverständliches Dokument vor, das eine andere, anspruchsvollere und meines Erachtens weitaus wenigey attraktive Sprache beschrieb. Ich war erstaunt, als die Arbeitsgruppe, die aus den besten internationalen Experten für Programmiersprachen bestand, sich entschloß, den bestellten Rohentwurf, an dem wir alle mitgearbeitet hatten, beiseitezulegen und diesen so unattraktiven Köder zu schlucken.
Das geschah genau eine Woche nach unseren Nachforschungen über das gescheiterte Software-Projekt für die 503 Mark II. Verzweifelt warnte ich vor der Verworrenheit, der Komplexität und dem übergroßen Anspruch des neuen Entwurfs, aber meine Warnungen blieben unbeachtet. Daraus schließe ich, daß es für einen Software-Entwurf zwei Konstruktionsweisen gibt:
Die eine besteht darin, ihn so einfach zu machen, daß er offensichtlich keine Fehler enthält; der zweite, ihn so kompliziert zu machen, daß er keine offensichtlichen Fehler enthält.
Die erste Methode ist weitaus schwieriger. Sie verlangt dieselbe Fertigkeit, Hingabe und sogar Inspiration wie die Entdeckung der einfachen physikalischen Gesetze, die den komplexen Naturphänomenen zugrundeliegen. Sie erfordert auch die Bereitschaft, Zielsetzungen zu akzeptieren, die durch physikalische, logische und technologische Einschränkungen begrenzt sind, und einen Kompromiß zu akzeptieren, wenn widerstreitende Zielsetzungen nicht zu vereinbaren sind. Das aber wird kein Komitee jemals tun, bevor es zu spät ist.
So war es auch beim ALGOL-Komitee. Sicherlich war der Plan, den es bevorzugte, noch nicht vollkommen. Deshalb wurde ein neuer und endgültiger Plan des neuen ALGOL-Sprachentwurfs innerhalb von drei Monaten versprochen; er sollte einer Untergruppe von vier Mitgliedern vorgelegt werden, zu der auch ich gehörte. Die drei Monate gingen ohne ein Wort über den neuen Plan vorüber. Nach sechs Monaten traf sich die Untergruppe in Holland. Vor uns lag ein noch längeres und dickeres Dokument voller Fehler, die in letzter Minute.korrigiert worden waren – das wiederum eine andere, meines Erachtens aber gleichermaßen unattraktive Sprache beschrieb. Niklaus Wirth und ich verwandten einige Zeit darauf, im Entwurf und in der Beschreibung einige Fehler auszuräumen, aber vergeblich. Der vollständige und endgültige Plan der Sprache wurde für das nächste Treffen des vollzähligen ALGOL-Komitees in drei Monaten versprochen.
Die drei Monate gingen vorbei ohne ein Wort über den neuen Plan. Nach sechs Monaten traf sich die ALGOL-Arbeitsgruppe im Oktober 1966 inWarschau. Ihr lag ein noch dickeres und längeres Dokument vor – voller Fehler, die man in letzter Minute korrigiert hatte -, das, gleichermaßen obskur, eine weitere und in meinen Augen gleichermaßen unattraktive Sprache beschrieb. Die Experten in der Gruppe konnten die Fehler dieses Entwurfs nicht sehen und waren fest entschlossen, den Plan zu übernehmen, in der Annahme, er sei in drei Monaten abgeschlossen. Vergeblich versuchte ich ihnen zu erklären, daß er nicht fertig sein werde. Vergeblich versuchte ich sie dahin zu bringen, einige von den technischen Fehlern der Sprache zu beseitigen: das Übermaß an Referenzierungen, die fehlerhaften Typenkonversionen. Die Arbeitsgruppe wollte alles andere als die Sprache vereinfachen; vielmehr forderte sie die Autoren auf, noch komplexere Konzepte aufzunehmen, zum Beispiel die Verwendung von Operatoren mit mehrfacher Bedeutung und Nebenläufigkeit.
Immer wenn sich ein neuer Sprachentwurf seinem Abschluß nähert, gibt es, bevor die Sprache normiert wird, ein wildes Wettrennen, weitere Eigenschaften hinzuzunehmen. Wild ist das Wettrennen deshalb, weil es in eine ausweglose Falle führt. Ein weggelassenes Konzept kann später immer noch hinzugefügt werden, wenn sein Entwurf und seine Folgen richtig verstanden werden. Ein Konzept, das aufgenommen wird, bevor es ganz verstanden wurde, kann später nie mehr beseitigt werden.
Schließlich nahm ich in einer Stimmung finsterer Depression am Treffen von München teil, bei dem unser lange ausgebrütetes Monstrum das Licht der Welt erblicken und den Namen ALGOL 68 erhalten sollte. Mittlerweile hatten einige andere Mitglieder der Gruppe ihre Illusion zwar verloren, aber zu spät: Das Komitee war nun mit Befürwortern der sprache überbesetzt, die jetzt an die höheren Komitees von IFIP zur Veröffentlichung weitergegeben wurde. Das beste, was wir tun konnten, war, ein Minderheitenvotum mitzuschicken, das unsere reiflich überlegte Ansicht enthielt, daß die Sprache für die zuverlassige Herstellung von komplizierten Programmen ungeeignet sei. Dieser Bericht wurde später von IFIP unterschlagen.
Ich besuchte keine weiteren Treffen dieser Arbeitsgruppe mehr. Ich freue mich, wenn ich jetzt berichten darf, daß die Gruppe zu der Einsicht gelangte, daß an ihrer Sprache und an der Sprachbeschreibung etwas nicht stimmte. Sie hatte sich sechs weitere Jahre abgemüht, eine revidierte Sprachbeschreibung zu produzieren. Die stellt zwar eine beträchtliche Verbesserung dar, aber wie ich befürchtete, hat sie die grundlegenden technischen Fehler im Entwurf nicht beseitigt und das Problem ihrer übergroßen Komplexität noch gar nicht in Angriff genommen.
Wir Programmierer müssen uns immer mit Komplexität befassen; wir können ihr nicht ausweichen. Unsere Anwendungen sind komplex, weil wir den Ehrgeiz haben, unsere Computer auf immer raffiniertere Weise zu gebrauchen. Programmieren ist wegen der großen Zahl widerstreitender Zielsetzungen bei allen unseren Programmierprojekten komplex. Wenn unser Basiswerkzeug, die Sprache, in der wir unser Programm entwerfen und kodieren, ebenfalls kompliziert ist, wird die Sprache selbst zu einem Teil des Problems statt zu einem Teil seiner Lösung.
Lassen Sie mich nun von einem anderen, allzu ehrgeizigen Sprachprojekt berichten. Zwischen 1965 und 1970war ich Mitglied und sogar Vorsitzender des Technischen Komitees 10der European Computer Manufacturers Association. Zunächst erhielten wir, und zwar vom größten Computerhersteller aller Zeiten, eine Vollmacht und dann den Standardisierungsauftrag für eine Sprache, die alle anderen Sprachen überflüssig machen und so konstruiert sein sollte, daß sie die Bedürfnisse sämtlicher Computeranwendungen sowohl im wirtschaftlichen als auch im wissenschaftlichen Bereich erfüllen könnte. Mit Interesse und Begeisterung, und nicht ohne ein gewisses Vergnügen, las ich die vier Grundlagendokumente, die eine Sprache namens NPL beschrieben und die zwischen dem l. März und dem 30.November 1964erschienen waren. Jedes einzelne dieser Dokumente war mit seinen Wunschspekulationen ehrgeiziger und absurder als das vorhergehende. Anschließend begann man die Sprache zu implementieren, dann erschien in sechsmonatigen Abständen eine neue Reihe von Dokumenten, die alle die endgültige, eingefrorene Version der Sprache unter ihrem endgültigen und eingefrorenen Namen PL/I beschrieben.
Für mich zeigte aber jede revidierte Fassung des Dokuments, wie weit die ursprüngliche F-Stufen-Implementierung vorangeschritten war. Die noch nicht implementierten Teile der Sprache waren dagegen in einer freischwebenden, blumigen Prosa beschrieben, die ein ungetrübtes Vergnügen ankündigte. In den bereits implementierten Teilen waren die Blumen jedoch schon verwelkt; sie waren im Gestrüpp der erläuternden Anmerkungen erstickt, die für den Gebrauch jedes Konzepts willkürliche und unerfreuliche Reriktionen festlegten und dem Programmierer die Verantwortung für die Kontrolle der komplexen und unerwarteten Effekte der Interaktion mit allen anderen Konzepten aufbürdeten.
März 1968wurde die Sprachbeschreibung endlich der gespannten Welt vornehm als würdiger Kandidat für die Standardisierung vorgestellt. Das war sie aber keineswegs. Ihre ursprünglichen Entwerfer hatten sie bereits mit ungefähr siebentausend Korrekturen und Änderungen versehen. Es waren zwölf weitere Fassungen erforderlich, bis sie schließlich 1976als Standard veröffentlicht wurde. Nach meiner Befürchtung geschah dies nicht etwa deshalb, weil alle Beteiligten mit ihrer Konstruktion zufrieden waren, sondern weil sie es satt hatten und weil sie gründlich enttäuscht waren.
Denn solange ich selbst mit dem Projekt befaßt war, hatte ich darauf gedrängt, die Sprache zu vereinfachen, notfalls durch Aufgliederung in Teilmengen, so daß der professionelle Programmierer sie verstehen und die Verantwortung übernehmen konnte für die Korrektheit und die Effizienz seiner Programme. Ich drängte darauf, daß so gefährliche Konzepte wie Voreinstellungen [defaults] und ON-Bedingungen beseitigt würden. Ich wußte, daß es unmöglich sein würde, für eine Sprache von dieser Komplexität einen völlig zuverlässigen Compiler zu schreiben, und daß es unmöglich ist, ein völlig zuverlässiges Programm zu schreiben, wenn die Korrektheit jedes Programmteils von der Überprüfung abhängt, ob jeder andere Programmteil alle Fallstricke und Gefahren der Sprache überwunden hat.
Zunächst hoffte ich, ein technisch so unvernünftiges Projekt würde einfach zusammenbrechen, bald aber erkannte ich, daß es zum Erfolg verdammt war. Was die Software betrifft, kann fast alles implementiert, verkauft und sogar benutzt werden, wenn nur genug Entschlußkraft dahintersteckt. Nichts, was ein reiner Wissenschaftler sagen kann, wird der Flut von hundert Millionen Dollar standhalten. Es gibt jedoch eine Eigenschaft, die sich sonicht kaufen läßt: die Zuverlässigkeit. Der Preis für die Zuverlässigkeit ist das Streben nach Einfachheit. Ein Preis, den die Reichen am schwersten zu zahlen finden.
Das alles ist schon eine Weile her. Kann es bei einer Konferenz, die der Vorausschau auf das künftige Computerzeitalter dient, überhaupt relevant sein? Meine größte Befürchtung ist die, daß es in der Tat relevant ist. Die Fehler, die in den letzten zwanzig Jahren gemacht wurden, werden heute in einem noch viel größeren Maßstab wiederholt. Ich meine damit das Projekt eines Sprachentwurfs, das Dokumente mit Titeln wie Strohmann (strawman), Holzmann (woodenman), Blechmann (tinman), Eisenmann (ironman), Stahlmann (steelman), Grün (green) und schließlich ADA hervorgebracht hat. Dieses Projekt wurde von einer der mächtigsten Organisationen der Welt in Gang gebracht und gefördert, vom amerikanischen Verteidigungsministerium. Dadurch ist ihm ganz unabhängig von seinen technischen Verdiensten Einfluß und Beachtung sicher, und seine Fehler und Unzulänglichkeiten bedrohen uns mit viel größeren Gefahren. Keiner der bisherigen Belege kann uns das Vertrauen geben, daß diese Sprache eines der Probleme vermeidet, die die anderen komplexen Sprachprojekte früher beeinträchtigt haben.
Seit 1975 unterstütze ich dieses Projekt mit meinem besten Rat. Zunächst war ich voller Hoffnungen. Zu den ursprünglichen Zielsetzungen der Sprache gehörten Zuverlässigkeit, Lesbarkeit der Programme, formale Sprach-definition und sogar Einfachheit. Nach und nach wurden diese Zielsetzungen zu Gunsten der Leistung [power] geopfert, die angeblich durch eine Fülle von Konzepten und notationellen Konventionen erreicht werden sollte; viele davon waren überflüssig, einige sogar gefährlich – wie zum Beispiel die Fehlerbehandlung. Wir erleben noch einmal die Geschichte des Automobilbaus. Unnötige Zusatzausrüstungen und Chromglanz haben den Vorrang vor elementaren Rücksichten auf Sicherheit und Wirtschaftlichkeit.
Es ist noch nicht zu spät! Ich glaube, daß es bei sorgfältiger Beschneidung der ADA-Sprache immer noch möglich ist, eine sehr leistungsfähige Teilmenge auszuwählen, die bei der Implementierung zuverlässig und effektiv und im Gebrauch sicher und wirtschaftlich sein wird. Die Förderer der Sprache haben jedoch einhellig erklärt, es werde keine Teilmengen geben. Das ist die seltsamste Paradoxie des gesamten seltsamen Projekts. Wenn man eine Sprache ohne Teilmengen haben will, muß man sie klein halten. Sie als Programmierer nehmen nur jene Konzepte auf, von denen Sie wissen, daß sie für jede Einzelanwendung der Sprache gebraucht werden und für jede einzelne Hardware-Konfiguration geeignet sind, auf der die Sprache implementiert wird. Erweiterungen können dann dort, wo sie für bestimmte Hardware-Konfigurationen und für bestimmte Anwendungen notwendig sind, gesondert entworfen werden. Darin liegt die große Stärke von PASCAL: daß es so wenige unnötige Eigenschaften gibt und fast keinen Bedarf für Teilmengen. Deshalb ist die Sprache auch leistungsfähig genug, um spezielle Erweiterungen zuzulassen – concurrent PASCAL für den Echtzeitbetrieb, PASCAL PLUS für die diskrete Simulation, UCSD PASCAL für Mikroprozessoren-Arbeitsplätze. Wenn wir aus den Erfolgen der Vergangenheit nur die richtigen Lektionen lernen könnten, brauchten wir nicht aus unseren Fehlschlägen zu lernen.
So wurde also mein Rat an die Begründer und Konstrukteure von ADA mißachtet. Im Sinne eines letzten Auswegs appelliere ich an Sie als Vertreter des Berufsstandes der Programmierer in den USA und als Bürger, denen es um das Wohlergehen und die Sicherheit des eigenen Landes und der Menschheit geht: Lassen Sie es nicht zu, daß diese Sprache in ihrem gegenwärtigen Zustand in Anwendungsfällen benutzt wird, wo die Zuverlässigkeit entscheidend ist, d. h. in Atomkraftwerken, Cruise Missiles, Frühwarnsystemen und ballistischen Raketenabwehrsystemen. Die nächste Rakete, die wegen eines Programmiersprachenfehlers von ihrer Flugbahn abkommt, ist vielleicht keine Forschungsrakete auf einem harmlosen Flug zur Venus: Sie kann Träger eines Nuklearsprengkopfes sein und über einer unserer Städte explodieren. Eine unzuverlässige Programmiersprache, aus der unzuverlässige Programme hervorgehen, bedeutet eine sehr viel größere Gefahr für unsere Umwelt und für unsere Gesellschaft als unsichere Automobile, giftige Pestizide oder Reaktorunfälle in Kernkraftwerken. Achten Sie darauf, daß Sie diese Gefahr verringern und nicht erhöhen!
Aus dem Englischen von Max Looser
erschienen in: Kursbuch