Computer und Krieg: „Herr Parnas, möchten Sie die Welt retten?“

von David L. Parnas

Informatikprofessor D. Pamas, einer der aus der SDI-Forschung ausgestiegen ist, nahm an dem Internationalen Naturwissenschaftler-Kongreß in Hamburg teil. Bei dieser Gelegenheit hielt er einen Vortrag in der Betriebsversammlung der Philips GmbH Forschungslaboratorium. Wir dokumentieren Auszüge:

Vor anderthalb Jahren habe ich einen Telefonanruf bekommen und der Mann fängt so an: Dave, would you like to save the world from nuclear confrontation? Die Frage hat mich sehr überrascht. Ich habe ihn gefragt, wie das geht. Er erzählte mir weiter, das würde mit 1.000 Dollar pro Tag honoriert. Da sagte ich mir, das ist schön, die Welt retten und gleichzeitig Hypotheken abzahlen. Trotzdem bin ich zwei Monate später aus dem SDI-Ausschuß zurückgetreten und ich will erklären, warum ich (…) dieses Projekt als eine Art Betrug betrachte.

Dieses Projekt ist immer noch so vage beschrieben, daß man mit der Rede vom Präsident Reagan im März 1983 anfangen muß. Er hat von uns als Wissenschaftler verlangt, die Welt von der nuklearen Bedrohung zu befreien, dadurch daß man die Raketen im Raum vernichtet. Dieses Wort finde ich sehr schön. Wenn das möglich wäre, würde ich an nichts lieber arbeiten und bräuchte dafür auch keine 1.000 Dollar pro Tag. Ich habe auch Kinder. Aber was das Pentagon daraus gemacht hat, ist meiner Meinung nach etwas anderes. Die haben solch riesige Pläne. Hunderte von Satelliten sollen mit Waffen, Sensoren und Computern ausgestattet werden. Computer sind eine Art Klebstoff, der dieses System zusammenhält. Die Computer werden die Daten der Sensoren verarbeiten und sie werden auch die Waffen ins Ziel richten und abschießen. Wir sollten vielleicht ein bißchen mehr im Detail über die Aufgaben der Computer reden. Zwei Beispiele: Eines ist die sog. Diskriminierung der mittleren Flugstrecke. Es wird erwartet, daß ein Gegner viele, viele Attrappen in den Weltraum schickt. Zwischen diesen Attrappen gäbe es ein paar echte Sprengköpfe. Die Attrappen sind unheimlich billig. Es ist immer möglich, daß man mehr Attrappen hat, als man vernichten kann. Deswegen muß man einem intelligenten System klarmachen, was eine Attrappe und was ein echter Sprengkopf ist. Diese Entscheidung muß der Computer treffen können.

Eine andere Aufgabe ist das sog. „kill-assessment“. Wenn man ein Ziel gewählt und geschossen hat, muß man feststellen, ob der Sprengkopf vernichtet ist oder nicht. Im Fernsehen sieht man oft, wie das im Spiel aussieht. Wenn das Ding abgeschossen wird, hat man eine große Explosion und man erwartet, daß dies sehr leicht zu sehen ist. Aber das ist nicht der Fall. Mit den vorgesehenen Energie-Waffen ist es nur möglich, die kleine Uhr innerhalb der Bombe zu vernichten. Der Sprengkopf selbst fliegt weiter - fast ohne Änderung. Es ist sehr schwierig festzustellen, ob das Ding vernichtet ist. Ist es das nicht, muß man noch mal schießen. Wenn ja, sind andere Ziele wichtig. Immer muß die Software solche Entscheidungen treffen. Und alles geht sehr schnell und es ist nicht zu erwarten, daß irgendein amerikanischer Soldat das mit einer M-1 macht.

Ich bin der Meinung, daß es nicht ausreicht, nur diese Programme zu schreiben. Man muß es so machen, daß man in diese Programme Vertrauen hat. Es geht darum, daß bei einer Kriegsplanung sich beide Seiten so verhalten, als ob der schlechtestmögliche Fall einträte. Dies wäre das Überhaupt-Nicht-Funktionieren des Systems. Solange also das System nicht vertrauenswürdig ist, kann nicht erwartet werden, daß Raketen vernichtet werden. Es würde auch nicht abgerüstet, wie Reagan behauptet. Die Amerikaner müßten alle Entscheidungen so treffen, als ob das System nicht funktioniere. Auf der anderen Seite kann kein Gegner darauf bauen, daß das System völlig wirkungslos ist. Deshalb würden die Russen etwa erwarten, daß sie vielleicht 50 % von ihren Sprengköpfen verlieren und dafür im Ausgleich mehr Raketen brauchen. Deswegen würde ich sagen, wenn Vertrauen in dieses System nicht vorhanden ist, beschleunigt es das Wettrüsten.

SDI wird nur dann behilflich, man der Software vertrauen kann. Ich verlange nicht, daß das Ding perfekt ist. Außer meiner Frau gibt es nichts Perfektes. Was ich verlange ist, daß das Ding vertrauenswürdig ist. D.h. daß wir im voraus wissen, daß es eine gewisse Wirksamkeit hat; sagen wir 50 %. Das wäre vielleicht nützlich, wenn man sicher weiß, daß das wirklich 50 % sind und nicht 10 oder 0 - was ich erwarte. Warum kann eine solche Software nie vertrauenswürdig sein? Ich gehe zurück zu meiner Ausbildung als Elektroingenieur. Dort haben wir gelernt von einem Fachmann zu erwarten, daß er Validation für seine Entwürfe macht. Die Hacker können etwas entwickeln, ausprobieren und sagen, ja, es geht gut. Schluß. Von einem Ingenieur wird erwartet, daß er seinen Entwurf als richtig beweist. In unserer Ausbildung haben wir von drei Methoden gehört:

1. von einem Entwurf macht man ein mathematisches Modell und analysiert es sorgfältig;
2. wenn dies nicht ausreicht, kann man eine Fallanalyse machen;
3. wenn das nicht gelungen ist, kann man einen oder mehrere realistische Tests machen.

In der Praxis wird immer eine Kombination solcher Methoden verwendet.

Warum erkläre ich das? In jedem großen System ist Software am Anfang immer unzuverlässig. Wir wissen von militärischen und kommerziellen Anwendungen, daß die Hardware am Anfang ziemlich gut läuft, die Software aber nicht. Warum? Einige sagen, weil Programmierer nicht gut ausgebildet sind. Oder weil sie irgendwie geistig faul sind. Ich meine das nicht. Es gibt in der Software Probleme, die bei anderen Technologien nicht bestehen. Andere Technologien werden im Grunde von kontinuierlichen Funktionen beschrieben. Aber bei Software hat man diskrete Funktionen. Und die mathematischen Werkzeuge, die ich als Student gelernt habe, die sind theoretisch bei allen Funktionen anwendbar; aber theoretisch heißt „not really“. Wenn jemand sagt, ich kann das theoretisch machen, dann heißt das, er kann das nicht machen. Es ist uns bei realistischen Programmen in der Praxis nicht gelungen, mathematische Beweise für die Programme zu erbringen, weil die mathematischen Ausdrücke einfach zu kompliziert sind. Die Funktionen sind nicht kontinuierlich und deswegen nicht kompakt zu beschreiben.

Wenn man eine Fallanalyse versucht, entdeckt man, daß die Zahl der Fälle zu groß ist. Wir sprechen sehr oft von „exhausted case analysis“, bei Software ist das „exhausting“. Es dauert einfach zu lange.

Dann kommt die Frage des Testens. Kann man Software testen? Ja. Trotzdem entdeckt man immer mehr Fehler in der tatsächlichen Anwendung. Ein großer Informatiker, der Holländer Edgar Dijkstra, hat sehr oft gesagt, der Test kann nur die Anwesenheit von Fehlern zeigen, nie die Abwesenheit. Bei der ersten Anwendung kann man keiner Software vertrauen.

Ich kann jetzt einen Schritt weitergehen. Bei der SDIO-Ausschußsitzung wollte ich die folgende Frage stellen: Wie unterscheidet sich SDI von anderen Softwareprojekten? Meine Kollegen aus dem Ausschuß haben an dieser Frage kein Interesse gezeigt. Hier sind einige Eigenschaften, die meiner Meinung nach SDI von anderen Projekten unterscheiden:

1. Man weiß nicht, was die Software machen soll. Um ein Programm korrekt zu schreiben, muß man mathematisch die Aufgabe beschreiben können. Das kann man bei solchen Anwendungen, wie dem Flug eines Raumschiffes zum Mars oder zum Mond. Alle Teile sind in den USA oder in Westeuropa hergestellt oder in Japan. Wir haben alle notwendigen Daten. Bei SDI ist das nicht der Fall. Denken Sie an das Problem der Midcourse-Diskriminierung. Man muß zwischen Attrappen und Sprengköpfen unterscheiden Doch welche Eigenschaften unterscheiden die Attrappen deutlich von den Sprengköpfen? Das wissen wir nicht. Beide sind nicht in den USA hergestellt. Wir können kein Vertrauen haben, daß das System korrekt ist, wenn wir nicht die Aufgabe beschreiben können.
2. Ist diesem Computersystem inhärent ein verteiltes System; man hat keinen einzigen großen Computer, sondern auf jedem Satelliten einen oder mehrere. Diese Satelliten erzeugen eine große Menge Daten, die vor Ort verarbeitet werden müssen. Wir wissen aus der Computerwissenschaft, daß verteilte Systeme viel schwieriger zu erstellen sind als zentralisierte Systeme. Wenn verteilte Systeme zusammen eine Entscheidung treffen müssen und die Verbindungen zwischen den Computern, oder die Computer selbst, unzuverlässig sind, ist ein Algorithmus dafür unmöglich. Das kann man theoretisch beweisen und in diesem Fall stimmt es auch.

Dazu kommt, daß dies ein Echtzeitproblem ist. Beim Echtzeitproblem hat man die sog. Dead-lines: wenn etwas zu spät berechnet wird, ist es nutzlos. Genau dies gilt, wenn man mit einer Waffe zielt. Es hilft mir nichts, wenn ich sage, ich hätte 10 Mikrosekunden früher schießen sollen. Wir wissen auch von der Theorie her - wenn man eine verteilte Datenbank hat -, daß man das nicht in Echtzeit konsistent halten kann.

Ich kann eine Geschichte aus der US-Marine erzählen. Vor einigen Jahren haben sie eine Alarmbereitschaft im Mittelmeer gehabt, weil ein Admiral auf seinem Bildschirm gesehen hat, daß es bei jedem Schiff ein Schattenschiff gab; ein zweites Schiff, das in bißchen dahinter fuhr. Er hat ein wenig Angst gekriegt und Alarm gegeben. Aber die Flugzeuge haben sehr schnell festgestellt, daß keine Schattenschiffe vorhanden waren. Es war ein Computerfehler. Wie ist das passiert? Durch einen kleinen Fehler in der Synchronisation. Sie haben von jedem Schiff zwei Berichte bekommen mit unterschiedlicher Zeit. Man hat daher den Eindruck gehabt, daß zwei Schiffe bestehen.

Denken Sie jetzt noch einmal an die midcourse-Diskriminierung und ein solcher Fehler kommt vor. Wir haben im Raum vielleicht hunderttausende Objekte. Dann hat man 10.000 Sprengköpfe, 90.000 Attrappen und dazu noch hunderttausend oder zweihunderttausend Schatten.(…)

Kritisch bei diesem Softwaresystem ist, daß die Möglichkeit eines realistischen Austestens nicht vorhanden ist. Man kann die Angriffskonditionen nicht im voraus herstellen. Bei SDI würde das bedeuten, daß man 100.000 Objekte im Raum hat, daß Nuklearexplosionen stattfinden und Satelliten teilweise vernichtet sind. So etwas kann man nicht machen.

Auch bei anderen militärischen Anwendungen sind solche Tests notwendig. In Vietnam habe ich z.B. einen Lastwagen gesehen, in dem es zwei Computer gab, die zur Waffensteuerung verwendet wurden. An der Wand gab es eine ganze Menge kleiner Notizen. Es waren sog. „debugging notes“, Adressen und Befehle also. Ich habe den Offizier gefragt: Haben die Soldaten gelernt, wie man diesen Computer programmiert? Nein, hat er gesagt, wir haben dafür zwei Zivilisten im Schlachtfeld.. Warum? Weil der Hersteller erklärt hat, daß es unmöglich sei, solche Programme zu entwickeln, wenn man nicht die Anwendung in einem echten Angriff beobachten kann. Ich kann Ihnen sagen, das ist ein Job, den ich auch für 1.000 Dollar am Tag nicht akzeptieren würde.

Bei SDI spricht man von einem Angriff, der einmal passiert und der vielleicht eine Stunde dauert oder anderthalb. Das Programm dafür ist ziemlich groß; vielleicht 20 Millionen Zeilen. Ein solches Programm kann man nicht in einer halben Stunde von Fehlern bereinigen. Alle Schätzungen besagen, daß es das allergrößte Echtzeitsystem sein wird. Wir haben bisher in Echtzeitsystemen nur sehr kleine Dinge geschafft, z.B. bei dem Space Shuttle sind das etwa 50.000 Zeilen, die während des Fluges im Raum laufen und vielleicht ein paar hundert, die während des Fluges auf dem Boden laufen. In der Vorbereitung werden vielleicht 3 Millionen Zeilen verwendet. Aber nicht während des Fluges. Ich kann diese Beobachtung auch anders formulieren. Einer der bekanntesten Softwareingenieure auf der Welt heißt Fred Brooks; er hat die größten Softwaresysteme für IBM in den 60er Jahren hergestellt. Er hat ein schönes Buch geschrieben: The mythical man mouth. Er erklärt dort, welche Fehler er bei diesen Entwicklungen gemacht hat. Ein Kapitel heißt: Plan to throw one away. Das bedeutet, daß man immer einen Prototyp braucht. Bei jedem großen System, das man erstmalig erstellt, muß man erwarten, daß man es wieder von Anfang an neu schreibt. Warum? Weil man nur durch die Anwendung lernt, was man und wie man es machen soll. Wenn Sie dieses „law of prototyping“ akzeptieren, dann gibt es ein Korrelat dazu: Wenn die erste Anwendung Erfolg haben muß, ist die Aufgabe unmöglich. Nach meinem Rücktritt haben viele meiner Kritiker gesagt, der verhält sich nicht als Wissenschaftler. Er hat keine Daten, die ihn bei seinen Argumenten unterstützen. Ich habe harte Zahlen. Das ist die Zahl der Programme, die in der ersten Anwendung von einem Anwender, der nicht der Entwickler ist, richtig funktioniert haben = Null.

Ich habe Leute gebeten, mir eine Ausnahme zu nennen. Jemand hat z.B. gesagt, bei dem Flug zum Mond habe die computergesteuerte Landung funktioniert. Sonst wären die Leute tot. Es stimmt nicht. Bei der Landung haben sie zwei Computer gehabt, beide haben versagt. Das Ding ist durch einen Piloten ohne Computer gelandet. Bisher sind mir keine Ausnahmen bekannt. Wenn eine auftritt, würde ich sagen, es ist die Ausnahme, die die Regel bestätigt (…)

Ich kann jetzt vielleicht meine Stellungnahme zusammenfassen. Der Vorsitzende des SDIO-Ausschusses hat mehrmals gesagt, es gibt kein Gesetz, mit dem man beweisen kann, daß eine korrekte Anwendung beim ersten Mal unmöglich sei. Das stimmt. Es kann alles richtig klappen.

Warum? Weil es auch möglich ist, daß 10.000 Affen das Gesamtwerk Shakespeares wieder herstellen. Wenn man sagt, 10.000 Affen sind fünf Jahre am Tippen, vielleicht ist es dann möglich. Die Wahrscheinlichkeit ist nicht sehr hoch. Es ist auch möglich, daß diese 10.000 Programmierer ein korrektes Programm für SDI schreiben. Aber was ich erklären kann, ist, daß die Aufgabe der Affen leichter ist. Weil man eine Methode zur Verifikation hat. Man kann die Arbeit dieser Affen anschauen und feststellen, ob das von Shakespeare geschrieben ist oder nicht. Man kann das sogar benutzen, um den Wahrscheinlichkeitsgrad zu erhöhen. D.h., man kann jedes Wort anschauen, und wenn das bei Shakespeare vorkommt, kann man das stehen lassen, und sonst kann man es wegwerfen. Damit wird dieser Wahrscheinlichkeitsgrad erhöht, aber er bleibt immer noch sehr niedrig. Aber bei SDI, bei dieser Software ist das nicht möglich. Wir haben keine Verifikationstechnologie.

Edward Teller hat gesagt, daß die Computerfrage nicht wichtig ist, weil die Computer immer schneller und zuverlässiger werden. Das stimmt. Aber die Programmierer werden nicht schneller und zuverlässiger.

Nachdem mein Rücktritt in der Presse erschienen ist, habe ich Gegenargumente erwartet. Einige sind gekommen. Die möchte ich heute besprechen, damit Sie verstehen, warum ich immer noch SDI-Gegner bin.

Die ersten zwei sind sehr einfach. Sie haben gesagt, das ist ein Forschungsprojekt. Man kann nicht „nein“ sagen. Man weiß nie, was man dort entdeckt. Ich kann mit einer Analogie erklären, warum ich das nicht akzeptiere. Stellen Sie sich vor, daß Reagan einen anderen Traum hat. Er träumt von Raketen, die schneller als Licht fliegen. Dann würde er statt SDI eine FLIO- Fast Light Initiative Organization - bestellen. Die amerikanischen militärischen Hersteller stellen sich dort an, um Verträge zu bekommen. Einige haben jetzt vor, Forschung über eine Endphase von Raketen zu machen, d.h., wenn man das mit 15 Phasen nicht machen kann, kann man 16 probieren. Wenn es mit 16 nicht klappt, 17 usw. Das ist meiner Meinung nach eine perfekte Forschungsaufgabe fr die Verteidigungsabteilung. Man kann dem General immer zeigen, daß man Fortschritte gemacht hat, aber da gibt es immer noch Arbeit. Der Vertrag wird immer erneuert. Das ist nur ein Witz, das wird nicht passieren, weil jeder weiß, daß Einstein bewiesen hat, daß ein Flug schneller als Licht nicht möglich ist. Aber es kann sein, daß Einstein einen Fehler gemacht hat, er ist auch ein Mensch. Er hat schon Fehler gemacht. Aber was man sagen würde: Bevor man mit teurer Forschung anfängt, sollte man den Fehler finden. Man muß sagen: Hier ist der Fehler bei Einstein, hier werde ich einen Ausweg finden. Sonst würde man sagen: Nein, kein Geld. Das erwarte ich auch hier. Man hat gesagt, bisher haben wir kein solches System korrekt schreiben können, warum erwarten sie, daß das jetzt bei diesem System anders ist? Bis ich eine Antwort auf diese Frage bekomme, keine Projekte.

Andere Aussagen, die vorgekommen sind, sind z.B., daß wir das alles durch Testen machen können. Ich bin der Meinung, daß der, der das sagt, keine Erfahrung mit Computern hat.

Dann kommen gewisse Zaubereien, z.B. die sogenannte automatische Programmierung. Wenn wir das als Menschen nicht machen können, dann kann der Computer das vielleicht machen. Aber wir wissen schon, daß eine automatische Programmierung immer noch Programmierung ist. Warum? Weil der Computer nicht weiß, was wir machen wollen. Wir müssen das beschreiben. Diese Beschreibung ist selber ein Programm. Da kommen Fehler vor.

Dann kommt die sogenannte Künstliche Intelligenz. Das ist ein Gebiet, von dem ich kein Anhänger bin, weil die Behauptungen in diesem Gebiet sehr weit von den Ergebnissen entfernt sind. Es wird sehr oft behauptet, daß die sogenannten Expertensysteme schon in Anwendung sind. Das stimmt nicht. Fred Brooks hat vor dem amerikanischen Defense Science Board eine Untersuchung gemacht und dabei festgestellt, daß es in den USA nur drei solche Programme gibt, die wirklich verwandt werden. Eines ist nur einmal angewandt worden und dann nicht mehr, die anderen sind immer noch in Gebrauch, aber sie funktionieren nicht sehr gut. Bei dem einen kommen 25 Prozent Fehler vor. Das ist kein zuverlässiges System.

Andere Gegenargumente, die mir gefallen haben, sind diese: Daß ich ein Pessimist bin. Pessimisten haben vorher Fehler gemacht, z.B. der bekannte Chemiker, Lord Rutherford, hat gesagt, daß Atombomben nicht möglich seien. Der war kein Pessimist, der war Optimist. Aber auch Optimisten haben Fehler gemacht. Das ist auch kein Argument.

Es gibt Leute, die sagen, wir können vielleicht die sogenannte Programm-Verifikation verwenden. Verifikation ist ein interessantes Gebiet, denn Programme sind tatsächlich mathematische Objekte. Die Spezifikationen sind mathematische Objekte. Wir können deswegen in der Theorie diese Programme korrekt beweisen. Aber wie gesagt: In der Theorie heißt, daß man das nicht machen kann. Warum? In diesem Fall hat man keine Spezifikation, und diese Methoden sind auch auf sehr kleine Programme beschränkt. Das sind auch Programme in nicht anwendbaren Programmiersprachen wie LISP; sie sind auf diese Sprachen beschränkt. Wir können es einfach nicht machen.

Der Ausschuß, aus dem ich zurückgetreten bin, hat andere Gegenargumente vorgeschlagen. Er hat gesagt, der Herr Parnas und andere Kritiker gehen davon aus, daß man ein großes zentralisiertes Programm hat, daß man nur einen großen Computer hat. Das ist sicherlich zu schwierig. Wir können das einfach lösen: Wir machen ein sogenanntes dezentralisiertes Programm, ein verteiltes System davon. Doch das ist keine Lösung, Verteilung ist ein Problem, nicht eine Lösung. Die Programmierung bei verteilten Systemen ist schwieriger als bei zentralisierten Systemen. Sie haben auch gesagt, dadurch würden die Programme kleiner. Aber das stimmt nicht. Weil die Aufgabe jedes sogenannten kleinen Programmes dieselbe bleibt. Die Midcourse-Diskriminierung ist nötig, Kill-Assessment bleibt noch nötig.

Jetzt kommt eine schwierige Frage: Was steckt dahinter, warum gibt es so viel Hinterlist? Das ist meiner Meinung nach sehr leicht zu erkennen. Ich war z.B. in den Los Mamas National Laboratories. Beim Abendessen hat einer mir gesagt: Ich bin der Befürworter für SDI hier in Los Alamos. Ich habe ihn gefragt: Warum befürworten Sie das? Er hat mir zwei Gründe genannt.

Zuerst hat er gesagt: I like challenges. Ich mag Herausforderungen. Dann hat er auch gesagt: Bei mir gibt es einige Leute, die jetzt vorübergehend unbeschäftigt sind, weil ein anderes Projekt schiefgelaufen ist. Bei SDI kann ich Geld bekommen, um diese Leute wieder zu beschäftigen. So geht es. Leute haben mir gesagt, SDI ist für die Verteidigung ungeeignet, aber für meine Firma ist das ganz gut.

Auch bei Universitäten ist das so. Hier ist die Aussage von Richard Sayed, der Präsident der Carnegie Mellon Universität ist, einer der führenden Universitäten auf dem Computergebiet in den Staaten. Er hat einfach kraß gesagt: Wenn man nicht sagt, daß diese Forschung der nationalen Sicherheit dient, kriegt man vom Kongreß kein Geld. Deswegen müssen wir das machen. Ich bin der Meinung, gute Forschung braucht sich nicht als etwas anderes darzustellen. Wenn das gute Forschung ist, kann man Geld bekommen. Wenn das keine gute Forschung ist, braucht man falsche Behauptungen. Und das ist meine Beobachtung.

Was können wir als Wissenschaftler in diesem Gebiet machen? Wenn jeder behauptet, daß er die Rüstungsspirale nicht gerne hat - auch die SDI-Befürworter behaupten, daß man durch SDI zu einem Ende der Rüstungsspirale kommen kann -, was sollen wir machen? Erstens bin ich der Meinung, daß wir einfach bei solchen Projekten nicht mitmachen sollten. Aber dazu müssen wir noch was tun als Wissenschaftler. Wir müssen die Öffentlichkeit, die Leute, die nicht Wissenschaftler sind, besser informieren. In Amerika habe ich beobachtet, daß die Mehrheit, die Leute, die nicht mit Computern arbeiten, den Eindruck bekommen, daß alles gut läuft. Warum? Wenn wir Erfolg haben mit einem Computersystem, dann reden wir viel davon. Wenn ein Projekt schiefgelaufen ist, dann wird (…) nicht darüber geredet. Dadurch entsteht bei vielen Leuten der Eindruck, daß man viel mehr machen kann, als tatsächlich der Fall ist. D.h., wenn Sie ein Informatiker sind und mit Computern arbeiten, sollten Sie auch gelegentlich mit ihren Nachbarn reden und denen erklären, wie unzuverlässig solche Programme sind. Das ist nicht angenehm. Es macht mir viel mehr Spaß, darüber zu reden, was ich geschafft habe. Aber man muß auch darüber reden, was man nicht geschafft hat. Welche Fehler vorkommen. Und dann kommt noch eine Frage. Es sind viele hier, die keine Informatiker sind. Ich bin der Meinung, daß solche Leute gelegentlich geistig faul sind. Ich habe sehr oft beobachtet, wenn Leute von SDI hören, schalten sie einfach ab. Sie sagen, das ist zu kompliziert, ich bin kein Wissenschaftler. Aber das stimmt nicht. So kompliziert ist das nicht. Programme sind nicht bei der ersten Anwendung zuverlässig. Das ist immer der Fall. Dieses Programm ist schwieriger als alle anderen. Man kann nicht erwarten, daß das beim ersten Mal funktioniert, und beim zweiten Mal ist es schon zu spät. Mehr braucht man nicht zu verstehen. Und das kann man auch Nichtfachleuten erklären.