Ada ist attraktiv und verführerisch - aber auch unberechenbar. Und wer sich mit Ada einläßt, so sagt ein intimer Kenner dieser neu konzipierten Programmiersprache, kann ein schlimmes Desaster heraufbeschwören.
Es ist nicht irgendwer, der da so dringend vor der neuen, unter der Ägide des Pentagon heranreifenden Sprache Ada - heute eines der Top-Themen in der Computerei - warnt; der Skeptiker ist ein Mann, der zu den maßgeblichen Mitgestaltern von Pascal gehörte, schon bei den Algol-68-Geburtswehen früh die Rolle der warnenden Kassandra übernommen hatte und auch an der Ada-Gestaltung zwar seit Jahren mitarbeitet, dabei seinen anfänglichen Enthusiasmus aber zusehends schwinden sah: Professor Charles Anthony Richard Hoare, letztes Jahr mit dem angesehenen Turing Award der Association for Computing Machinery (ACM) ausgezeichnet und heute als Professor of Computation an der Universität Oxford tätig. Doch was ist nun eigentlich das Gefährliche an der so verlockend jungen Ada?
Hören wir erst Hoare selber (bei der Entgegennahme des Turing Award): "Erlaubt nicht, daß diese Sprache in Anwendungen eingesetzt wird, wo es entscheidend auf Zuverlässigkeit ankommt, also beispielsweise in Kernkraftwerken, Cruise Missiles, Frühwarnsystemen, Raketenabwehr-Systemen und so weiter. Sonst könnte schon die nächste Rakete nicht mehr wie seinerzeit, infolge eines Programmsprachenfehlers, bloß den rechten Weg zur Venus verfehlen sondern mit einem nuklearen Sprengsatz gar auf einer unserer Städte niedergehen. Eine "unzuverlässige Programmiersprache", die "unzuverlässige Programme" erzeugt, stellt für unsere Umwelt und unsere Gesellschaft eine viel größere Gefahr dar, als unsichere Autos, giftige Pestizide oder nukleare Fast-Katastrophen."
Nun ist das sicher eine eindrucksvolle Warnung, doppelt gewichtig in einer Zeit der verbreiteten, vielleicht manchmal etwas unkritischen Ada-Euphorie. Aber sind es, fachliche Qualifikation hin, langjährige Erfahrung mit "überladenen" Konzepten her, nicht doch bloß die Worte eines enttäuschten Mahners, dessen "beste Ratschläge an die Entwerfer von Ada ignoriert worden sind" (Hoare)? Warum sollte es denn unmöglich sein, in einer so aufwendig erarbeiteten Sprache wie Ada alle Programme wirklich wasserdicht zu machen?
Hoares Antwort darauf besteht aus einer vordergründigen, knappen Kritik und, hintergründig, einer ausführlichen Diskussion seiner langjährigen Erfahrungen mit dem Entwurf von Compilern, Betriebssystemen und Programmiersprachen; Erfahrungen, die massiv gegen allzu ehrgeizige übervollständige und überladene Sprachkonzepte sprechen. Doch hören wir erst, was er - übrigens sogar vom "Spiegel" registriert - konkret gegen die bisherige Ada-Entwicklung zu sagen hat.
Statt Sicherheit Zierat
Hoare ist am Projekt Ada seit 1975 beteiligt und war "am Anfang noch äußerst hoffnungsvoll", denn die ursprüngliche angepeilten Ziele umfaßten hohe Zuverlässigkeit, leichte Lesbarkeit der Programme, klar formulierte Definitionen und damals "sogar noch Einfachheit". Doch im Laufe der Zeit, so sieht es Hoare, wurden diese Ziele zugunsten größerer Leistungsfähigkeit mehr und mehr nach hinten gedrängt ("geopfert"), was inzwischen einen Wust zusätzlicher Eigenschaften und Notations-Konventionen erforderte; die meisten von ihnen "unnötig" und manche, etwa das Konzept der "Exceptions", sogar "gefährlich", wie Hoare warnt. Der renommierte Computer-Professor zieht dabei Parallelen zu manchen Autos bei deren Entwicklung es offenbar auch mehr auf Spielereien und Pracht als auf Wirtschaftlichkeit und Sicherheit ankam.
Auf der Basis seiner Erfahrungen mit der Konzeption von Algol 68 und PL/1 warnt Hoare vor jeglicher Hybris bei der Entwicklung von Software-Projekten: denn an Software könne man ja, ausreichende Entschlossenheit vorausgesetzt, so gut wie alles entwickeln, verkaufen und sogar anwenden. Und dann gebe es für einen einfachen Wissenschaftler kein Argument mehr, mit dem er gegen die Flut von 100 Millionen (bereits investierter) Dollar angehen könnte.
Dennoch könne auch noch so großer Aufwand eine wichtige Qualität nicht schaffen: Zuverlässigkeit. Denn der Preis der Zuverlässigkeit sei die Beschränkung auf äußerste Einfachheit - und gerade die Reichsten (Pentagon) fänden es schwer, diesen Preis zu zahlen.
Dem heutigen Ada-Konzept setzt Hoare die große Stärke von Pascal entgegen, überflüssige Merkmale zu vermeiden und sich mit Elementen zu begnügen, die zum Abdecken aller elementaren Ansprüche genügen. So könne diese Sprache gegebenenfalls spezielle Erweiterungen aufnehmen, während kein Bedürfnis nach "abgemagerten" Subversionen bestehe.
Ganz anders Ada: Noch könnte man sich hier auf ein mächtiges, in der Implementierung effizientes und zuverlässiges Subset beschränken, meint Hoare, die im Gebrauch dann bestimmt sicher und wirtschaftlich anzuwenden wäre. Doch wolle man offiziell ja gerade für Ada jegliche Untermengen untersagen, was nun, wie Hoare betont, wirklich das seltsamste Paradoxon darstelle. Denn gerade Sprachen, die auf Subsets verzichten sollen, müßten von vornherein klein gehalten, statt so aufwendig wie Ada konzipiert zu werden.
Hier ist nicht der Platz für eine ausführliche Darstellung der vielfältigen Erfahrungen, auf denen Hoares Abneigung kompliziert angelegten Programmiersprachen gegenüber basiert; doch schon 1962 beispielsweise, so erinnerte er bei seiner Turing-Ansprache, haben Kollegen und er bei der Weiterentwicklung von Algol 68 die Überzeugung gewonnen, daß die Reduktion selbst einer einfachen Sprache auf einen noch simpleren Subset im Grunde aber eine Verbesserung des Originals darstellen könne.
Beim Entwurf von Software, so bringt Hoare seine Erfahrungen aus jenen Tagen auf den Punkt, gibt es offenbar zwei Möglichkeiten: Man kann sie so einfach halten, daß offensichtlich keine Fehler vorhanden sind oder sie so kompliziert aufbauen, daß keine offensichtlichen Fehler mehr erkennbar werden.
Die erstgenannte Methode sei die weitaus kompliziertere, denn sie erfordere etwa die gleiche Sorgfalt, Hingabe, Einsicht und sogar Inspiration wie etwa die Entdeckung der elementaren physikalischen Gesetze, die sich hinter den vielfältigen Phänomen unserer realen Welt verbergen; außerdem müsse man gewillt sein, sich mit Zielen zu begnügen, die im Rahmen vorgegebener physikalischer, logischer und technologischer Grenzen bleiben müssen. Das bedeutet, man müsse, können konkurrierende Ziele nicht gleichzeitig erreicht werden, rechtzeitig einen guten Kompromiß akzeptieren - doch genau das werde ein (Programmsprachen-Entwurfs-) Komitee niemals tun ehe es zu spät ist.
Hoare: "Wissen Sie, Sie sollten uns intelligenten Programmierern niemals trauen. Wir können uns nämlich leicht prima Argumente ausdenken, mit denen wir uns und unseresgleichen von etwas völlig Absurdem überzeugen können. Und vor allem sollte uns niemand glauben, wenn wir versprechen, einen früheren Erfolg zu wiederholen, nur noch größer und besser."
Das Algol-68-Projekt jedenfalls so erinnerte Hoare, wurde von Entwurf immer komplexer, immer aufs Neue wurden die ursprünglichen Termine überschritte und man
konnte daran sehen, so Hoare, daß immer dann, wenn das Projekt einer neuen Sprache der Vollendung entgegengeht, ein geradezu verrückter Drang einsetze, in letzter Minute noch
schnell alle möglichen zusätzlichen Eigenschaften unterzubringen, ehe die endgültige Normung erfolgt. Dieser "Rush" sei tatsächlich verrückt, denn er führe in eine Falle, aus der es kein Entrinnen gebe. Fehlende Eigenschaften und Möglichkeiten lassen sich einer Sprache ja leicht später, wenn ihr Aufbau und ihre Verflechtungen voll verstanden werden, hinzufügen, doch ein verfrüht eingebautes Werkzeug, das noch nicht voll durchschaut worden ist, könne später nie mehr herausgenommen werden, warnte Hoare.
Und hoch eine seiner Warnungen vor überzogener Komplexität sei hier zitiert: Wir Programmierer sind immer von Komplexität umgeben und können ihr nicht entrinnen. Unsere Anwendungen sind komplex, weil wir den Ehrgeiz haben, unsere Rechner in immer anspruchsvollerer Art und Weise einzusetzen, und das Programmieren ist komplex, weil wir es bei jedem unserer Programmierprojekte mit vielerlei, einander wechselseitig tangierenden Zielen zu tun haben. Doch wenn nun auch unser elementares Werkzeug, die Sprache, in der wir unsere Programme entwerfen und kodieren, ebenfalls kompliziert ist - ja, dann wird unsere Sprache eben selber zum Teil des Problems, statt ein ??? seines Lösung zu sein.
Lit.: Communications of the ACM, Vol.24, Feb. 1981, Nr. 2, S. 75 ff.