Engineering-Philosophie: Edsger Dijkstra, Eleganz ist nicht optional

Die wichtigsten Erkenntnisse

• Eleganz ist nicht optional. Für Dijkstra ist Einfachheit die Voraussetzung für Korrektheit, keine Belohnung, die man danach einsammelt – Sie können nicht beweisen, was Sie nicht vollständig durchdringen.
• Beweis schlägt Testen. „Testen zeigt die Anwesenheit, nicht die Abwesenheit von Fehlern.” Vertrauen in die Korrektheit entsteht aus dem Nachdenken über ein Programm, niemals aus dem Anhäufen bestandener Tests.
• Denken Sie, bevor Sie programmieren. Er entwarf seinen Kürzeste-Wege-Algorithmus ganz ohne Bleistift und Papier und zwang ihn dadurch so klein, dass er in einen einzigen Kopf passte – die Beschränkung erzeugte die Eleganz.
• Schreiben ist Denken. Die EWD-Manuskripte, von Hand mit dem Füllfederhalter verfasst, ohne Rückgängig-Funktion, ließen Argumente entweder in Tinte tragen oder scheitern – dieselbe Disziplin, angewandt auf die Prosa.

Das Prinzip

„Einfachheit ist die Voraussetzung für Zuverlässigkeit.” – Edsger W. Dijkstra, zugeschrieben (um 1975)¹

Der Satz überlebt als einzeiliger Aphorismus, fast wie eine Randnotiz, verbunden mit seinen bewusst provokanten Memos aus der Zeit um 1975. Aus seinem Zusammenhang gerissen klingt er wie ein Slogan, doch Dijkstra meinte ihn als strenge logische Behauptung. Zuverlässigkeit ist nichts, was Sie einem komplizierten System hinzufügen, indem Sie es härter testen. Ein System, das Sie nicht vollständig verstehen, ist ein System, das Sie nicht als korrekt beweisen können, und ein System, das Sie nicht als korrekt beweisen können, wird auf eine Weise versagen, die Sie nicht vorhergesehen haben. Einfachheit ist keine stilistische Vorliebe, die mit der Korrektheit konkurriert. Sie ist das, woraus Korrektheit gebaut ist. Das Zweite gibt es nicht ohne das Erste.

Das stellt die Art und Weise auf den Kopf, wie Software tatsächlich geschrieben wird. Der verbreitete Instinkt ist, die Sache zu bauen, sie zum Laufen zu bringen und dann so lange zu testen, bis die Fehler nicht mehr auftauchen – wobei die Einfachheit als Luxus behandelt wird, den man später verfolgt, falls noch Zeit bleibt. Dijkstras gesamte Laufbahn war ein Plädoyer dafür, dass diese Reihenfolge verkehrt und gefährlich ist. Sein meistzitierter Satz ist die Warnung, die unmittelbar daraus folgt: „Testen zeigt die Anwesenheit, nicht die Abwesenheit von Fehlern.”² Ein bestandener Test sagt Ihnen nichts über die Eingaben, die Sie nicht ausprobiert haben. Der einzige Weg, zu wissen, dass ein Programm keine Fehler hat, besteht darin, über es nachzudenken – und Sie können nur über das nachdenken, was einfach genug ist, um in einen einzigen menschlichen Kopf zu passen. Eleganz ist für Dijkstra „kein entbehrlicher Luxus, sondern ein Faktor, der oft über Erfolg und Misserfolg entscheidet.”³

Diese Überzeugung stellt ihn an den Ursprung dieser Reihe. Wo Linus Torvalds ein Problem so lange umformt, bis der Sonderfall verschwindet und John Carmack ein Problem auf seinen schnellen Kern reduziert, lieferte Dijkstra die zugrunde liegende Behauptung, die beide erbten: Die elegante Lösung und die korrekte Lösung sind dieselbe Lösung. Es ist das ursprüngliche Plädoyer dafür, Geschmack als technisches System zu behandeln statt als ästhetische Spielerei – und das Plädoyer für Beweis statt Plausibilität, Jahrzehnte bevor jemand ihm einen Namen gab.

Kontext

Edsger Wybe Dijkstra wurde am 11. Mai 1930 in Rotterdam in den Niederlanden geboren und starb am 6. August 2002 in Nuenen.⁴ Sein Vater war Chemiker und Präsident der Niederländischen Chemischen Gesellschaft; seine Mutter war Mathematikerin mit, nach seinen eigenen Worten, einem ungewöhnlich klaren Gespür dafür, wann ein mathematisches Argument elegant war und wann es bloß funktionierte. Er studierte Mathematik und theoretische Physik in Leiden und nahm dann 1952 eine Stelle als Programmierer am Mathematischen Zentrum in Amsterdam an – zu einem Zeitpunkt, als „Programmierer” noch kein anerkannter Beruf war. Als er ihn 1957 als seine Tätigkeit auf seiner Heiratsurkunde eintragen wollte, hätten die niederländischen Behörden ihn Berichten zufolge nicht akzeptiert, weil ein solcher Beruf offiziell nicht existierte; er musste stattdessen „theoretischer Physiker” schreiben.⁴

Dieses Detail ist keine Belanglosigkeit. Dijkstra verbrachte den Rest seines Lebens mit dem Beharren darauf, dass Programmieren eine strenge intellektuelle Disziplin sei und kein bürokratisches Handwerk, und das Beharren begann, bevor die Disziplin einen Namen hatte. Er hatte eine Stelle am Mathematischen Zentrum inne, wurde dann 1962 Professor an der Technischen Universität Eindhoven, verbrachte die 1970er Jahre als Forschungsstipendiat bei der Burroughs Corporation und übernahm 1984 den Schlumberger Centennial Chair in Computer Sciences an der University of Texas at Austin, wo er bis zu seinem Ruhestand 1999 blieb.⁴

1972 erhielt er den ACM Turing Award. Die Begründung ist es wert, vollständig gelesen zu werden, denn sie benennt das Prinzip besser als jede Zusammenfassung: „Für grundlegende Beiträge zur Programmierung als hohe, intellektuelle Herausforderung; für das eloquente Beharren und die praktische Demonstration, dass Programme korrekt komponiert und nicht erst zur Korrektheit debuggt werden sollten; für die erhellende Wahrnehmung von Problemen an den Grundlagen des Programmentwurfs.”⁵ Korrekt komponiert, nicht erst zur Korrektheit debuggt. Dieser Satz ist der ganze Mann.

Das Werk

Der Kürzeste-Wege-Algorithmus (1956, veröffentlicht 1959)

1956 wurde Dijkstra gebeten, ein Problem zu finden, das den neuen ARMAC-Computer bei seiner offiziellen Einweihung zur Geltung bringen würde – etwas, dem ein nichttechnisches Publikum folgen konnte. Er wählte die kürzeste Route zwischen zwei von 64 niederländischen Städten, weil jeder die Frage verstehen und die Antwort überprüfen konnte. Die Lösung kam ihm auf eine Weise in den Sinn, die er nie müde wurde zu erzählen: „Eines Morgens war ich mit meiner jungen Verlobten in Amsterdam einkaufen, und müde setzten wir uns auf die Caféterrasse, um eine Tasse Kaffee zu trinken, und ich dachte gerade darüber nach, ob ich dies tun könnte, und da entwarf ich den Algorithmus für den kürzesten Weg.”⁶ Es dauerte etwa zwanzig Minuten.

Die Methode, mit der er ihn fand, ist die Lehre. „Einer der Gründe, warum er so schön ist”, sagte er später, „war, dass ich ihn ohne Bleistift und Papier entworfen habe. Ich lernte später, dass einer der Vorteile des Entwerfens ohne Bleistift und Papier darin besteht, dass man fast gezwungen ist, alle vermeidbaren Komplexitäten zu vermeiden.”⁶ Er konnte sich nicht auf Notizen stützen, also musste die Idee klein genug sein, um sie vollständig im Kopf zu behalten. Die Beschränkung erzeugte die Eleganz. Er veröffentlichte ihn drei Jahre lang nicht – die Arbeit „A Note on Two Problems in Connexion with Graphs” von 1959 in der Numerische Mathematik umfasst kaum mehr als eine Seite –, weil, wie er es ausdrückte, das Programmieren noch nicht als seriös genug galt, um darüber zu schreiben.⁶

Der Algorithmus ist gierig: Er expandiert immer zuerst den nächstgelegenen noch nicht besuchten Knoten, eine sich ausbreitende Wellenfront, die jeden Punkt der Reihe nach über seine kürzeste Distanz erreicht. Er ist einfach genug, um ihn an einem Cafétisch zu erklären, und er ist beweisbar optimal – sobald die Wellenfront das Ziel zum ersten Mal berührt, kann dieser Weg nicht übertroffen werden. Einfach und korrekt stehen hier nicht im Widerspruch. Sie sind dieselbe Tatsache.

„Go To Statement Considered Harmful” und strukturierte Programmierung (1968)

1968 reichte Dijkstra einen Brief bei Communications of the ACM unter dem Titel „A Case Against the Goto Statement” ein. Der Herausgeber Niklaus Wirth gab ihm den neuen Titel „Go To Statement Considered Harmful” – eine Formulierung, die ein ganzes Genre von Nachahmungen hervorbrachte und heute bekannter ist als alles im Brief selbst.⁷ Dijkstras Argument war kein Stilratgeber. Es war erkenntnistheoretisch. Uneingeschränktes goto lässt die Steuerung überallhin springen, was bedeutet, dass Sie, um zu verstehen, was ein Programm an einer bestimmten Zeile tut, möglicherweise jeden Pfad nachverfolgen müssen, der dorthin geführt haben könnte. Der Programmtext und das Verhalten des Programms gehen auseinander. Mit strukturierter Steuerung – Sequenz, Auswahl und Schleifen – bleiben Text und Ausführung in Übereinstimmung, und Sie können über einen Block nachdenken, indem Sie den Block lesen.

Das Argument ist dasselbe Prinzip wie die Kürzeste-Wege-Beschränkung, angewandt auf den Sprachentwurf: Halten Sie die Sache klein genug, um darüber nachdenken zu können. Bei der strukturierten Programmierung ging es nicht darum, ein Schlüsselwort zu verbieten. Es ging darum, die Fähigkeit des Menschen zu bewahren, durch Lesen zu beweisen, dass das Programm korrekt ist. Die Aufzählung seines Vokabulars in der Turing-Begründung – „deadly embrace”, „semaphore”, „go-to-less programming”, „structured programming” – ist ein Zeugnis dafür, wie gründlich er die Sprache umformte, in der Programmierer denken.⁵

Seine Arbeit an Betriebssystemen trug dieselbe DNA in sich. Das THE-Multiprogramming-System (1968) wurde als streng geschichtete Abstraktionsebenen gebaut, von denen jede für sich allein verifizierbar war. Um nebenläufige Prozesse zu koordinieren, erfand er den Semaphor und seine P- und V-Operationen, und er formulierte das Problem der speisenden Philosophen als lehrhafte Verdichtung von Verklemmung und Verhungern – eine schwierige Nebenläufigkeitsfrage, klein genug gemacht, um sie im Kopf zu behalten.⁴⁵ Später kamen die Selbststabilisierung und, in A Discipline of Programming (1976), der Kalkül der Prädikatentransformer / der schwächsten Vorbedingung hinzu: eine Methode, um ein Programm und seinen Korrektheitsbeweis gemeinsam, Hand in Hand, herzuleiten, anstatt Code zu schreiben und zu hoffen, ihn hinterher zu verifizieren.⁴⁵

Der demütige Programmierer: Beweis statt Testen (1972)

Dijkstras Turing-Award-Vortrag „The Humble Programmer” (EWD340) ist die klarste Aussage darüber, warum Einfachheit ein moralisches und nicht bloß praktisches Anliegen ist. Seine zentrale Behauptung handelt von der Größe des menschlichen Geistes. „Der kompetente Programmierer ist sich der streng begrenzten Größe seines eigenen Schädels voll bewusst; deshalb geht er die Programmieraufgabe in voller Demut an und meidet unter anderem clevere Tricks wie die Pest.”⁸ Cleverness ist keine Tugend. Sie ist eine Wette darauf, dass Sie mehr in Ihrem Kopf behalten können, als Sie es vermögen, und die Wette wird in der Produktion entschieden, gegen Sie.

Der Vortrag mündet in eine Verschreibung, die sich wie die Gründungsurkunde der korrekt-durch-Konstruktion-Software liest: „Wir werden eine viel bessere Programmierarbeit leisten, vorausgesetzt, wir gehen die Aufgabe mit voller Würdigung ihrer enormen Schwierigkeit an, vorausgesetzt, wir halten an bescheidenen und eleganten Programmiersprachen fest, vorausgesetzt, wir respektieren die intrinsischen Grenzen des menschlichen Geistes und gehen die Aufgabe als sehr demütige Programmierer an.”⁸ Testen ist in diesem Rahmen grundlegend unzureichend – nicht weil Testen nutzlos wäre, sondern weil es immer nur eine Stichprobe des Eingaberaums nehmen kann. Die kanonische längere Form seiner Warnung aus den „Notes on Structured Programming” ist unmissverständlich: „Programmtesten kann verwendet werden, um die Anwesenheit von Fehlern zu zeigen, aber niemals, um ihre Abwesenheit zu zeigen!”⁹ Wenn Sie die Abwesenheit von Fehlern wollen, müssen Sie sie beweisen, und Sie können nur das beweisen, was Sie durchdringen können.

Die EWD-Manuskripte als Praxis (1960er–2002)

Rund vierzig Jahre lang schrieb Dijkstra eine nummerierte Reihe von Manuskripten – Memos, Beweise, Reiseberichte, Essays und Argumente –, denen er seine Initialen „EWD” voranstellte. Die Reihe reicht bis EWD1318, mit über tausend tatsächlichen Dokumenten; die Zahlen übersteigen die Dokumente, weil er eine Nummer vergab, sobald er ein Stück begann, und nicht jedes Stück wurde fertiggestellt.⁴¹⁰ Die meisten wurden von Hand verfasst, in einer berühmt präzisen Handschrift, mit einem Füllfederhalter. Er entwarf nicht am Computer. Er schrieb ein Manuskript, fotokopierte es und schickte es per Post an einen kleinen Kreis von Kollegen, die es kopierten und weiterleiteten – ein Samisdat aus der Zeit vor dem Internet, der den EWDs einen übergroßen Einfluss verlieh, gemessen daran, dass fast keines davon formell veröffentlicht wurde.⁴¹⁰ Die vollständige Reihe ist inzwischen gescannt und im E.W. Dijkstra Archive an der UT Austin frei zugänglich.¹⁰

Die Praxis war untrennbar von der Philosophie. Langsam von Hand zu schreiben, ohne Rückgängig-Funktion, erzwingt dieselbe Disziplin wie das Entwerfen ohne Bleistift und Papier: Sie können sich nicht hinter Umfang oder Überarbeitung verstecken. Ein Argument trägt oder es trägt nicht, und Sie verpflichten sich ihm in Tinte. Die EWDs sind das, was es aussieht, wenn ein Ingenieur das Schreiben selbst als Werkzeug für klares Denken behandelt und Klarheit als den ganzen Sinn der Sache.

Die Methode

Die Methode ist eine einzige Überzeugung, unerbittlich über vierzig Jahre hinweg angewandt.

Machen Sie es klein genug, um darüber nachdenken zu können. Der Café-Algorithmus, der strukturierte Kontrollfluss, das geschichtete THE-System, die Verdichtung der speisenden Philosophen – jedes ist ein Akt des Schrumpfens eines Problems, bis ein menschlicher Geist das Ganze davon erfassen und überprüfen kann. Komplexität, die Sie nicht überblicken können, ist Komplexität, der Sie nicht trauen können.

Beweisen Sie, testen Sie nicht. Testen nimmt Stichproben; Beweis zertifiziert. Dijkstras Kalkül der Prädikatentransformer existiert, damit der Beweis und das Programm gemeinsam hergeleitet werden, nicht damit das eine geschrieben und das andere drangeschraubt wird. „Korrekt komponiert, nicht erst zur Korrektheit debuggt” ist die Methode in fünf Worten.⁵

Behandeln Sie Eleganz als Beweismittel, nicht als Dekoration. Wenn eine Lösung hässlich ist, ist diese Hässlichkeit meist ein Signal dafür, dass das Problem nicht verstanden wurde. Eleganz „entscheidet über Erfolg und Misserfolg”, weil die elegante Form diejenige mit den wenigsten Stellen ist, an denen etwas falsch sein kann.³

Schreiben Sie, um zu denken. Die EWDs waren keine Dokumentation, die nach der Arbeit entstand. Sie waren die Arbeit – sichtbar gemachtes Denken, in einem Medium, das das Herumreden bestrafte. Ohne Bleistift und Papier zu entwerfen und das Ergebnis dann dem Füllfederhalter anzuvertrauen, ist dieselbe Disziplin zweimal.

Einflusskette

Wer ihn prägte

Seine Mutter, die Mathematikerin. Dijkstra schrieb ihr sein Gespür für mathematische Eleganz zu – den geschulten Instinkt dafür, wann ein Beweis nicht nur gültig, sondern sauber ist. Diese Unterscheidung zwischen einem Argument, das funktioniert, und einem Argument, das schön ist, wurde zur Achse seiner gesamten Laufbahn. (Prägender Einfluss)

Das Algol-60-Vorhaben. Dijkstra baute einen der ersten Algol-60-Compiler mit, und die Blockstruktur und Rekursion der Sprache gaben ihm das Rohmaterial für die strukturierte Programmierung. Algol war der Beweis, dass eine Programmiersprache für Klarheit entworfen statt aus Bequemlichkeit zusammengewachsen sein konnte. (Direkter Einfluss)

Die mathematische Tradition des Beweisens. Als Mathematiker und Physiker ausgebildet, bevor es die „Informatik” gab, importierte Dijkstra den Maßstab des Beweises in seiner Gesamtheit. Für ihn war ein Programm ein mathematisches Objekt, und die Frage war nie „scheint es zu funktionieren?”, sondern „können Sie zeigen, dass es funktionieren muss?” (Prägender Einfluss)

Wen er prägte

Jeder Programmierer, der strukturierten Code schreibt. Das Verschwinden von goto aus dem alltäglichen Programmieren, die Allgegenwart von Sequenz/Auswahl/Iteration und das gesamte Vokabular der Nebenläufigkeit – Semaphore, Verklemmung, gegenseitiger Ausschluss – sind sein Vermächtnis, das unsichtbar in jeder seither geschriebenen Codebasis wirkt.

Formale Methoden und Programmverifikation. Der Kalkül der Prädikatentransformer und das Ideal der Korrektheit durch Konstruktion sind die direkten Vorfahren der modernen Verifikation, des Model Checking und des beweistragenden Codes. Die gegenwärtige Wiederbelebung formal verifizierter Systemsoftware ist Dijkstras Argument, das endlich auf Hardware trifft, die schnell genug ist, um es auszuführen.

Das Selbstbild der Disziplin. Mehr als jedes einzelne Artefakt etablierte Dijkstra die Idee, dass Programmieren ein Zweig der angewandten Mathematik ist, der Strenge verdient – und kein Gewerbe, das man durch Versuch und Irrtum erlernt. Das Gewissen des Fachs spricht, im Guten wie im Schlechten, noch immer in seiner Kadenz.

Der rote Faden

Dijkstra ist die Quelle, aus der der Rest dieser Reihe fließt. Linus Torvalds’ „guter Geschmack” – die Umschreibung, bei der der Sonderfall verschwindet – ist Dijkstras Einfachheit-als-Korrektheit im Idiom eines Kernel-Hackers: weniger Verzweigungen bedeuten weniger Stellen, an denen etwas falsch sein kann. John Carmacks schneller, einfacher Kern ist dieselbe Subtraktion, gerichtet auf die Hardware-Decke statt auf den Beweis. Und Andrej Karpathys Beharren darauf, ein System von Grund auf neu zu bauen, um es wirklich zu verstehen, ist Dijkstras „Entwerfen ohne Bleistift und Papier” mit Deep-Learning-Hut. Die vier sind sich über fast alles uneinig, außer über das eine, worauf es ankommt: Die elegante Struktur wird nicht oben auf die korrekte Lösung aufgesetzt. Sie ist die korrekte Lösung. (Reihenbrücke)

Was ich daraus mitnehme

Der Satz, zu dem ich zurückkehre, ist die Umkehrung: Einfachheit ist die Voraussetzung für Zuverlässigkeit, keine Belohnung, die Sie einsammeln, nachdem Sie sie erreicht haben. Die meiste langsame, fragile Software ist nicht langsam und fragil, weil jemand das Testen übersprungen hätte. Sie ist langsam und fragil, weil niemand sie je klein genug machte, um sie zu verstehen, sodass niemand über sie nachdenken konnte, sodass die einzige verfügbare Qualitätsstrategie darin bestand, so lange zu testen, bis die sichtbaren Fehler aufhörten – was, wie Dijkstra sagte, nichts zertifiziert. Die Umkehrung ist derselbe Maßstab wie Qualität als einzige Variable: Die Frage ist nie „sind die Tests durchgelaufen?”, sondern „verstehe ich dies gut genug, um zu wissen, dass es korrekt ist?”

In der Welt, in der ich heute baue – KI-Agenten, Werkzeugschleifen, Systeme, die Code schneller erzeugen, als ein Mensch ihn lesen kann –, ist Dijkstras Warnung schärfer als je zuvor. Wenn ein Agent tausend Zeilen schreibt und die Tests grün sind, ist das genau die Situation, die er beschrieb: Die Anwesenheit von Fehlern wurde nicht gezeigt, und ihre Abwesenheit kann es nicht. Der Dijkstra-Zug besteht darin, sich zu weigern, das Begreifen herunterzuskalieren, während die Erzeugung hochskaliert – darauf zu bestehen, dass das System klein genug, geschichtet genug und lesbar genug bleibt, dass jemand es noch als korrekt beweisen kann. Diese Disziplin ist der Grund, warum ich die Verifikationsschicht als tragend behandle, selbst wenn kein Mensch den Code liest: Testen zeigt Anwesenheit, nicht Abwesenheit, und eine Wellenfront grüner Häkchen ist kein Beweis.

FAQ

Was ist die Ingenieursphilosophie von Edsger Dijkstra?

Dijkstra vertrat die Ansicht, dass Einfachheit die Voraussetzung für Zuverlässigkeit ist: Ein Programm muss einfach genug sein, damit ein Mensch es vollständig durchdringen kann, denn nur über ein begreifliches Programm lässt sich nachdenken und es als korrekt beweisen. Er argumentierte, dass Programme „korrekt komponiert und nicht erst zur Korrektheit debuggt” werden sollten, dass Testen die Anwesenheit von Fehlern zeigen kann, aber niemals ihre Abwesenheit, und dass Eleganz keine Dekoration ist, sondern „ein Faktor, der oft über Erfolg und Misserfolg entscheidet.” Cleverness war in seinen Augen ein Laster, weil sie die begrenzte Kapazität des menschlichen Geistes überstieg.³⁵⁸⁹

Was hat Edsger Dijkstra erfunden?

Dijkstra erfand den Kürzeste-Wege-Algorithmus, der seinen Namen trägt (konzipiert 1956, veröffentlicht 1959), führte den Semaphor und die P/V-Operationen zur Koordination nebenläufiger Prozesse ein, baute das geschichtete THE-Multiprogramming-System, formulierte das Problem der speisenden Philosophen, brachte die strukturierte Programmierung voran, begründete das Konzept der Selbststabilisierung in verteilten Systemen und entwickelte den Kalkül der Prädikatentransformer / der schwächsten Vorbedingung zur gemeinsamen Herleitung von Programmen und ihren Korrektheitsbeweisen (in A Discipline of Programming, 1976). 1972 erhielt er den ACM Turing Award.⁴⁵

Was bedeutet „Testen zeigt die Anwesenheit, nicht die Abwesenheit von Fehlern”?

Es bedeutet, dass ein Test nur zeigen kann, dass ein Fehler existiert, indem er ihn auslöst – er kann niemals zeigen, dass keine Fehler existieren, denn keine endliche Menge von Tests deckt jede mögliche Eingabe ab. Dijkstra formulierte es auf der NATO Software Engineering Conference 1969 und gab die kanonische längere Form in den „Notes on Structured Programming”: „Programmtesten kann verwendet werden, um die Anwesenheit von Fehlern zu zeigen, aber niemals, um ihre Abwesenheit zu zeigen!” Sein Schluss war, dass Vertrauen in die Korrektheit aus dem Beweis und aus dem Entwurf von Programmen kommen muss, die einfach genug sind, um über sie nachzudenken, und nicht aus dem Anhäufen bestandener Tests.²⁹

Warum schrieb Dijkstra von Hand und verbreitete die EWD-Manuskripte per Fotokopie?

Die EWDs waren eine Reihe von über tausend nummerierten Manuskripten, die Dijkstra über rund vier Jahrzehnte schrieb, die meisten von Hand mit einem Füllfederhalter, dann fotokopiert und an einen kleinen Kreis geschickt, der sie kopierte und weiterleitete. Langsam von Hand zu schreiben, ohne Rückgängig-Funktion, erzwang dieselbe Disziplin wie seine Gewohnheit, Algorithmen ohne Bleistift und Papier zu entwerfen: Es erzwang Klarheit und bestrafte das Herumreden, denn ein der Tinte anvertrautes Argument musste tatsächlich tragen. Die vollständige Reihe ist archiviert und an der University of Texas at Austin frei zugänglich.⁶¹⁰

Quellen