Warum wir Edsger Dijkstra etwas schuldenWhy We Owe Edsger Dijkstra
Es gibt eine merkwürdige Form von Ruhm in der Informatik.
Man kann so erfolgreich mit einer Idee werden, dass diese Idee irgendwann den Rest des eigenen Lebenswerks verdeckt.
Für Edsger Wybe Dijkstra ist diese Idee ein Algorithmus.
Wenn man Informatiker nach Dijkstra fragt, bekommt man meistens dieselbe Antwort: Shortest Path. Gewichteter Graph. Startknoten. Immer den bislang günstigsten erreichbaren Knoten wählen. Distanzen aktualisieren. Weiter.
Dijkstra.
Fertig.
Nur ist das ungefähr so, als würde man Alan Turing als den Mann beschreiben, der sich einmal Gedanken über eine Maschine gemacht hat.
Der Shortest-Path-Algorithmus ist nicht Dijkstras Vermächtnis. Er ist eher der Eingang zu einem wesentlich größeren Gebäude.
Dijkstra arbeitete an Algorithmendesign, Programmiersprachen, Betriebssystemen, verteilten Systemen, formaler Spezifikation und Programmverifikation. Das Archiv der University of Texas beschreibt ihn entsprechend als einen der einflussreichsten Vertreter der Gründergeneration der Computerwissenschaft.
Und wenn man moderne Software schreibt, ist die Wahrscheinlichkeit ziemlich hoch, dass man irgendwo in diesem Gebäude lebt.
Auch wenn man seinen Namen nie über der Tür gesehen hat.
Der Algorithmus, der zu groß für seinen Erfinder wurde
Beginnen wir trotzdem dort, wo alle beginnen.
Beim kürzesten Weg.
Die Geschichte seiner Entstehung klingt fast absichtlich konstruiert, um heutige Entwickler schlecht aussehen zu lassen.
Dijkstra erzählte später, dass er 1956 mit seiner Verlobten in Amsterdam einkaufen gewesen sei. Sie waren müde, setzten sich auf eine Caféterrasse, tranken Kaffee – und Dijkstra dachte über das Problem nach, einen kürzesten Weg zu bestimmen.
Nach seiner eigenen Erinnerung dauerte die Entwicklung der Idee ungefähr zwanzig Minuten.
Der Algorithmus wurde erst 1959 veröffentlicht.
Heute gehört er zu den Standardverfahren der Informatikausbildung. Er taucht bei Routing, Netzwerken, Wegplanung und zahllosen Graphproblemen auf.
Das Beeindruckende daran ist aber nicht nur die Laufzeit oder die Eleganz des Verfahrens.
Es ist die Art, wie Dijkstra dachte.
Er suchte nicht nach einem cleveren Trick, der irgendwie funktionierte. Er reduzierte ein Problem, bis die Struktur sichtbar wurde.
Dann baute er die Lösung aus dieser Struktur heraus.
Dieses Muster findet man später praktisch überall in seinem Werk wieder.
Als „Programmierer“ noch kein Beruf war
Dijkstra wurde 1930 geboren und begann seine wissenschaftliche Laufbahn zu einer Zeit, in der „Computer Science“ noch nicht die Selbstverständlichkeit war, die sie heute ist. Sein Weg führte vom Interesse an Physik in die damals noch junge Welt des Programmierens.
Wie jung diese Welt war, zeigt eine seiner bekanntesten autobiografischen Geschichten: Als er heiratete und bei den Behörden „Programmierer“ als Beruf angab, soll diese Berufsbezeichnung zunächst nicht akzeptiert worden sein.
Es gab diesen Beruf offiziell praktisch noch nicht.
Das ist eine interessante Ausgangsposition für einen Mann, der später mithelfen sollte zu definieren, was dieser Beruf überhaupt bedeutet.
In den späten 1950er- und frühen 1960er-Jahren arbeitete Dijkstra außerdem an ALGOL und an einem Compiler für die Electrologica X1. ALGOL wurde zu einer der wichtigen frühen Hochsprachen und beeinflusste die Gestaltung späterer Programmiersprachen erheblich.
Aber Dijkstra interessierte nicht nur, wie man einer Maschine Befehle gibt.
Ihn interessierte etwas viel Grundsätzlicheres:
Wie müssen wir Programme formulieren, damit Menschen noch über sie nachdenken können?
Diese Frage zieht sich durch fast alles, was danach kam.
Der Mann hinter dem Semaphore
Wenn du heute mehrere Threads koordinierst, einen Mutex verwendest oder über Race Conditions nachdenkst, bewegst du dich in einem Gebiet, dessen frühes Vokabular Dijkstra entscheidend geprägt hat.
Während seiner Arbeit an Multiprogramming-Systemen beschäftigte er sich intensiv damit, wie mehrere Prozesse kooperieren können, ohne sich gegenseitig das System zu zerstören.
Eine der Antworten darauf war der Semaphore.
Das Konzept ist heute so normal, dass es leicht unspektakulär wirkt.
Mehrere Ausführungseinheiten wollen auf eine Ressource zugreifen. Ein Zähler kontrolliert, wie viele gleichzeitig hinein dürfen. Ist die verfügbare Kapazität erschöpft, müssen weitere Prozesse warten.
Bei einem binären Semaphore nähert man sich dem Prinzip an, das Entwickler heute von Mutual Exclusion kennen.
Die University of Texas zählt Betriebssysteme und Distributed Processing ausdrücklich zu den Gebieten, in denen Dijkstras Beiträge fundamental waren.
Das ist wichtig, weil Concurrency heute gern wie ein modernes Problem behandelt wird.
Threads. Async. Goroutines. Actors. Distributed Locks.
Die Syntax ändert sich.
Das Problem nicht.
Mehrere unabhängige Prozesse teilen Ressourcen, und plötzlich reicht lineares Denken nicht mehr aus.
Dijkstra arbeitete an diesem Problem, bevor die meisten heutigen Programmiersprachen überhaupt existierten.
The Deadly Embrace
Und natürlich gab Dijkstra einem der unangenehmsten Fehler konkurrierender Systeme einen wesentlich besseren Namen als wir heute.
The deadly embrace.
Heute sagen wir: Deadlock.
Prozess A besitzt Ressource 1 und wartet auf Ressource 2.
Prozess B besitzt Ressource 2 und wartet auf Ressource 1.
Beide warten.
Für immer.
Das Programm ist nicht abgestürzt. Nichts muss segfaulten. Es kann vollkommen gesund aussehen.
Es tut nur nichts mehr.
Dijkstras Archiv enthält sogar ein frühes Manuskript mit dem niederländischen Titel Een algorithme ter voorkoming van de dodelijke omarming – ein Algorithmus zur Vermeidung dieser „tödlichen Umarmung“.
Wenn Betriebssystemkurse heute Mutual Exclusion, Semaphore und Deadlocks behandeln, lernen Studenten also nicht bloß historische Kuriositäten.
Sie bewegen sich durch Probleme, deren grundlegende Sprache Dijkstra mitgeformt hat.
Der Krieg gegen GOTO
Dann kam GOTO.
1968 erschien Dijkstras berühmter Text unter dem Titel “Go To Statement Considered Harmful.”
Interessanterweise war das nicht sein ursprünglicher Titel.
Dijkstra hatte seinen Text A Case Against the Go To Statement genannt. Der Herausgeber Niklaus Wirth änderte ihn für die Veröffentlichung.
Damit entstand vermutlich eine der langlebigsten Formulierungen der Programmiergeschichte.
Heute ist die Debatte fast schwer nachzuempfinden.
Wir schreiben:
if
else
for
while
Funktionen.
Blöcke.
Scopes.
Strukturen.
Damals war die Möglichkeit, den Kontrollfluss mit GOTO praktisch beliebig durch ein Programm springen zu lassen, wesentlich normaler.
Dijkstras Einwand war nicht einfach: „Diese Syntax ist hässlich.“
Er hatte ein tieferes Problem damit.
Je beliebiger der Kontrollfluss eines Programms wird, desto schwieriger wird es für einen Menschen, dessen Zustand nachzuvollziehen.
Und wenn wir den Zustand nicht mehr nachvollziehen können, verlieren wir die Fähigkeit, vernünftig über die Korrektheit des Programms zu argumentieren.
Robert C. Martin beschreibt Dijkstras Argument treffend: Strukturierte Konstrukte wie Sequenz, Auswahl und Iteration begrenzen den Kontrollfluss und machen Programme dadurch analysierbarer.
Das klingt heute banal.
Das ist das höchste Kompliment, das man einer fundamentalen Idee machen kann.
Sie hat gewonnen.
Der eigentliche Punkt war nie GOTO
Es wäre trotzdem falsch, Dijkstras Beitrag auf „der Typ, der GOTO abgeschafft hat“ zu reduzieren.
Das wäre nur die nächste verkürzte Version seiner Geschichte.
Sein eigentliches Thema war Komplexität.
Computer wurden schneller.
Speicher wurde größer.
Programme wurden umfangreicher.
Aber das menschliche Gehirn bekam kein Upgrade.
Das war für Dijkstra das zentrale Problem der Softwareentwicklung.
Wir können Maschinen bauen, die Millionen oder Milliarden Operationen durchführen. Aber wir müssen trotzdem Programme erzeugen, über die ein Mensch reasoning betreiben kann.
Strukturierte Programmierung war deshalb keine Stilfrage.
Sie war eine Methode, den möglichen mentalen Zustandsraum eines Programms zu begrenzen.
Und damit kommen wir zu dem Teil von Dijkstra, der heute vielleicht relevanter ist als sein Algorithmus.
Correct by construction
Dijkstra hielt wenig von der Vorstellung, Software einfach so lange zu testen und zu debuggen, bis sie irgendwann korrekt aussieht.
Einer seiner berühmtesten Sätze bringt das auf den Punkt:
“Program testing can be used to show the presence of bugs, but never to show their absence.”
Tests können Bugs finden.
Was sie nicht beweisen können, ist, dass keine Bugs mehr existieren.
Das klingt zunächst wie akademische Pedanterie.
Bis man Software baut, auf der Geld, Infrastruktur, medizinische Geräte oder Millionen Nutzer hängen.
Dijkstras Ideal ging deshalb weiter.
Programme sollten nicht zuerst geschrieben und anschließend in Richtung Korrektheit geprügelt werden.
Man sollte sie so entwickeln, dass ihre Korrektheit aus ihrer Konstruktion heraus nachvollziehbar wird.
Seine Turing-Award-Lecture von 1972 trug nicht zufällig den Titel “The Humble Programmer”; das Dijkstra-Archiv führt sie als EWD340 und als Veröffentlichung in Communications of the ACM.
Die Demut im Titel ist entscheidend.
Nicht weil Dijkstra selbst für sprachliche Zurückhaltung bekannt gewesen wäre.
Sondern weil gute Programmierer akzeptieren müssen, dass ihre Fähigkeit, Komplexität im Kopf zu behalten, begrenzt ist.
Der Computer ist nicht das schwache Glied.
Wir sind es.
Dijkstra und die LLM-Ära
Und damit landen wir ausgerechnet bei 2026.
Wir können heute einem Modell auf Englisch erklären, dass wir eine API, einen Parser oder einen React-Component brauchen, und Sekunden später existiert Code.
Das ist erstaunlich.
Es ist auch nahezu perfekt darauf ausgelegt, Dijkstra nervös zu machen.
Denn die Frage hat sich verschoben.
Früher mussten wir fragen:
Kann ich dieses Programm schreiben?
Heute lautet sie immer häufiger:
Kann ich verstehen und verantworten, was gerade für mich geschrieben wurde?
Ein LLM kann hundert Zeilen Code schneller erzeugen, als ein Mensch sie sorgfältig lesen kann.
Mit Agenten werden daraus tausend.
Dann zehntausend.
Dijkstras Warnung vor unbeherrschbarer Komplexität wird dadurch nicht veraltet.
Sie wird unangenehm aktuell.
Wir könnten mehr Code produzieren als jemals zuvor und gleichzeitig weniger davon verstehen.
Dijkstra würde sich vermutlich weniger dafür interessieren, ob der Code von einem Menschen oder einem Modell stammt.
Seine Frage wäre wahrscheinlich dieselbe:
Warum glaubst du, dass dieses Programm korrekt ist?
„Die Tests sind grün“ hätte ihn kaum zufriedengestellt.
Seine EWDs waren Blogs vor dem Web
Dijkstra veröffentlichte nicht nur Papers.
Über Jahrzehnte schrieb er nummerierte Manuskripte, Notizen, Reiseberichte, technische Überlegungen und Kommentare: die berühmten EWDs.
Die University of Texas beschreibt, wie er diese Texte an Kollegen verschickte und wie manche über Fotokopien schließlich eine große informelle Verbreitung erreichten. Heute archiviert die Universität mehr als tausend dieser Manuskripte.
Es ist schwer, darin nicht eine frühe Form des technischen Bloggens zu sehen.
EWD249.
EWD268.
EWD340.
Ein Entwickler des 21. Jahrhunderts hätte dafür vielleicht eine persönliche Website, einen RSS-Feed und einen unglaublich minimalistischen Static-Site-Generator.
Dijkstra hatte Papier.
Die Technologie ist verschieden.
Der Impuls ist derselbe: Eine Idee ausarbeiten, sie präzise formulieren und sie anderen Menschen geben, damit sie darüber nachdenken können.
Der unbequeme Programmierer
Dijkstra war dabei nicht gerade bekannt dafür, seine Urteile weich einzupacken.
APL?
Eine Katastrophe, brillant bis zur Perfektion ausgeführt.
BASIC?
Seiner Ansicht nach pädagogisch beinahe irreparabel.
COBOL?
Auch nicht gerade ein Favorit.
Eine Sammlung der University of Scranton dokumentiert einige dieser berüchtigten Aussagen.
Man muss diese Polemik nicht übernehmen.
Man sollte aber verstehen, was dahinterstand.
Dijkstra glaubte, dass Programmiersprachen unser Denken formen.
Eine schlechte Abstraktion verursacht deshalb für ihn nicht nur hässlichen Code.
Sie trainiert schlechte Denkgewohnheiten.
Das erklärt auch, warum er Structured Programming so ernst nahm.
Warum er formale Methoden ernst nahm.
Warum er Verständlichkeit ernst nahm.
Für Dijkstra war Programmieren keine Tätigkeit, bei der wir der Maschine irgendwie verständlich machen, was sie tun soll.
Es war die Kunst, unsere Gedanken so weit zu ordnen, dass ein Programm überhaupt sicher daraus entstehen kann.
Was wir Dijkstra wirklich schulden
Natürlich schulden wir ihm den Shortest-Path-Algorithmus.
Wir schulden ihm auch Semaphore.
Frühe Arbeit an Multiprogramming.
Wesentliche Beiträge zum Denken über Deadlocks.
Structured Programming.
Arbeit an ALGOL.
Formale Methoden.
Ein Vokabular, mit dem Generationen von Informatikern über Programme sprechen konnten. Das Dijkstra-Archiv nennt entsprechend fundamentale Beiträge von Algorithmendesign bis zu formaler Verifikation.
Aber selbst diese Liste verfehlt den interessantesten Punkt.
Dijkstras größte Leistung war vielleicht keine einzelne Erfindung.
Sie war eine Haltung.
Software ist kein magischer Text, den wir schreiben und anschließend ausprobieren.
Ein Programm ist ein formales Objekt.
Wir können über seine Struktur nachdenken.
Wir können unnötige Zustände entfernen.
Wir können seinen Kontrollfluss begrenzen.
Wir können Abstraktionen wählen, die unseren Kopf entlasten.
Wir können versuchen, Korrektheit nicht erst am Ende hineinzutesten, sondern von Anfang an mitzudenken.
Fast alles an moderner Softwareentwicklung widerspricht diesem Ideal gelegentlich.
Unsere Systeme sind gigantisch.
Unsere Dependency Trees sind absurd.
Unsere verteilten Systeme haben Fehlerzustände, die kein einzelner Mensch vollständig überblickt.
Und inzwischen können Maschinen schneller Code erzeugen, als wir ihn verstehen können.
Genau deshalb lohnt es sich, Dijkstra wieder zu lesen.
Nicht aus Nostalgie.
Aus Notwehr.
FAQ zu Edsger Dijkstra
Wer war Edsger W. Dijkstra?
Edsger Wybe Dijkstra war ein niederländischer Informatiker und einer der einflussreichsten Vertreter der frühen Computerwissenschaft. Seine Arbeit umfasste Algorithmen, Programmiersprachen, Betriebssysteme, verteilte Systeme sowie formale Spezifikation und Verifikation.
Wofür ist Dijkstra am bekanntesten?
Am bekanntesten ist er heute für Dijkstras Algorithmus zur Bestimmung kürzester Wege in gewichteten Graphen. Sein wissenschaftliches Werk ging jedoch erheblich darüber hinaus.
Hat Dijkstra den Semaphore erfunden?
Dijkstra führte den Semaphore als grundlegende Synchronisationsidee im Kontext kooperierender Prozesse ein. Seine Arbeiten zu Mutual Exclusion und Multiprogramming gehören zu den Grundlagen der frühen Concurrency-Forschung.
Was bedeutet „Go To Statement Considered Harmful“?
Der 1968 veröffentlichte Text argumentierte gegen unkontrollierte GOTO-Sprünge, weil sie Programme schwieriger nachvollziehbar und damit schwieriger korrekt analysierbar machen. Der ursprüngliche Titel lautete A Case Against the Go To Statement; Niklaus Wirth änderte ihn für die Veröffentlichung.
Hat Dijkstra Structured Programming erfunden?
Structured Programming entstand aus mehreren theoretischen und praktischen Entwicklungen. Dijkstra wurde jedoch zu einem ihrer wichtigsten und einflussreichsten Fürsprecher und entwickelte seine Vorstellungen dazu in mehreren Arbeiten weiter.
Was meinte Dijkstra mit „Testing kann nur die Anwesenheit von Bugs zeigen“?
Er meinte damit, dass ein erfolgreicher Test nur zeigt, dass ein bestimmter getesteter Fall funktioniert. Selbst sehr viele erfolgreiche Tests beweisen nicht allgemein, dass ein Programm keine unentdeckten Fehler enthält.
Was sind die EWDs?
Die EWDs sind Dijkstras fortlaufend nummerierte Manuskripte, darunter technische Notizen, Essays, Reiseberichte und Kommentare. Mehr als tausend dieser Dokumente werden heute von der University of Texas archiviert.
Warum ist Dijkstra für heutige Entwickler noch relevant?
Weil sich sein zentrales Problem nicht verändert hat: Software wächst schneller, als Menschen Komplexität beherrschen können. Struktur, verständliche Abstraktionen, kontrollierter Programmfluss und begründbare Korrektheit sind deshalb auch bei Cloud-Systemen, Concurrency und KI-generiertem Code relevant.
Schluss: Danke, Dijkstra
Es gibt Menschen in der Geschichte der Informatik, deren Namen wir verwenden, ohne noch über die Menschen nachzudenken.
Wir sagen Dijkstra.
Wir meinen einen Algorithmus.
Vielleicht sollten wir damit aufhören.
Vielleicht sollten wir bei diesem Namen an Semaphore denken. An Deadlocks. An Structured Programming. An formale Korrektheit. An ALGOL. An die EWD-Manuskripte. An die beinahe obsessive Forderung, dass ein Programm nicht nur laufen, sondern verständlich sein sollte.
Dijkstra gab uns nicht einfach eine Methode, den kürzesten Weg durch einen Graphen zu finden.
Er verbrachte einen großen Teil seines Lebens damit, nach einem kürzeren Weg durch die Komplexität des Programmierens zu suchen.
Wir haben ihn noch nicht vollständig gefunden.
Aber ein erstaunlich großer Teil der Wegweiser trägt seinen Namen.
Dafür schulden wir ihm etwas.
Mindestens ein Danke.
Und vielleicht, bevor wir den nächsten Pull Request mergen, noch einen zweiten Gedanken darüber, ob wir eigentlich beweisen können, dass das Ding funktioniert.
Weiterführende Quellen
- Edsger W. Dijkstra: „Go To Statement Considered Harmful“ – der Originaltext von 1968
- „The Humble Programmer“ (EWD340) – Dijkstras Turing-Award-Vorlesung von 1972
- Das EWD-Archiv der University of Texas at Austin – mehr als tausend von Dijkstras Manuskripten
- Dijkstras Kürzeste-Wege-Algorithmus – Cornell-CS-Tutorial – eine zugängliche Einführung
- Memorable Quotes from Edsger Dijkstra – University of Scranton – einschließlich seiner polemischen Bemerkungen zu APL, BASIC und COBOL
There is a strange kind of fame in computer science.
You can become so successful with one idea that it eventually obscures the rest of your life's work.
For Edsger Wybe Dijkstra, that idea is an algorithm.
Ask computer scientists about Dijkstra and you usually get the same answer: shortest path. Weighted graph. Starting node. Always choose the cheapest reachable node so far. Update distances. Continue.
Dijkstra.
Done.
But that is roughly like describing Alan Turing as the man who once thought about a machine.
The shortest-path algorithm is not Dijkstra's legacy. It is more like the entrance to a much larger building.
Dijkstra worked on algorithm design, programming languages, operating systems, distributed systems, formal specification, and program verification. The University of Texas archive accordingly describes him as one of the most influential members of computer science's founding generation.
And when you write modern software, there is a good chance that you live somewhere in that building.
Even if you have never seen his name above the door.
The algorithm that became too large for its inventor
Let us nevertheless begin where everyone begins.
With the shortest path.
The story of its origin almost sounds designed to make modern developers look bad.
Dijkstra later said that in 1956 he had been shopping in Amsterdam with his fiancée. They were tired, sat down at a café terrace, drank coffee—and Dijkstra thought about the problem of finding a shortest path.
By his own recollection, developing the idea took about twenty minutes.
The algorithm was not published until 1959.
Today it is standard material in computer-science education. It appears in routing, networks, route planning, and countless graph problems.
What is impressive is not only its runtime or elegance.
It is the way Dijkstra thought.
He did not look for a clever trick that somehow worked. He reduced a problem until its structure became visible.
Then he built the solution out of that structure.
You find this pattern again almost everywhere in his work.
When “programmer” was not yet a profession
Dijkstra was born in 1930 and began his academic career at a time when computer science was not yet the obvious discipline it is today. His path led from an interest in physics into the then-young world of programming.
One of his best-known autobiographical stories shows just how young that world was: when he married and listed “programmer” as his occupation with the authorities, the designation was reportedly not accepted at first.
Officially, that profession barely existed yet.
That is an interesting starting point for a man who would later help define what the profession meant at all.
In the late 1950s and early 1960s, Dijkstra also worked on ALGOL and a compiler for the Electrologica X1. ALGOL became one of the important early high-level languages and significantly influenced the design of later programming languages.
But Dijkstra was not interested only in how to give a machine instructions.
He was interested in something far more fundamental:
How must we formulate programs so that humans can still think about them?
That question runs through almost everything that followed.
The man behind the semaphore
When you coordinate several threads today, use a mutex, or think about race conditions, you are working in an area whose early vocabulary Dijkstra decisively shaped.
While working on multiprogramming systems, he studied how multiple processes could cooperate without destroying the system for one another.
One answer was the semaphore.
The idea is so ordinary today that it can seem unremarkable.
Several units of execution want to access a resource. A counter controls how many may enter at once. When available capacity is exhausted, further processes must wait.
A binary semaphore approaches the principle developers now know as mutual exclusion.
The University of Texas explicitly lists operating systems and distributed processing among the fields in which Dijkstra's contributions were fundamental.
That matters because concurrency is often treated as a modern problem.
Threads. Async. Goroutines. Actors. Distributed locks.
The syntax changes.
The problem does not.
Several independent processes share resources, and suddenly linear thinking is no longer enough.
Dijkstra worked on this problem before most of today's programming languages even existed.
The Deadly Embrace
And of course Dijkstra gave one of the most unpleasant errors in concurrent systems a much better name than the one we use today.
The deadly embrace.
Today we say: deadlock.
Process A owns resource 1 and waits for resource 2.
Process B owns resource 2 and waits for resource 1.
Both wait.
Forever.
The program has not crashed. Nothing needs to segfault. It can look perfectly healthy.
It simply no longer does anything.
Dijkstra's archive even contains an early manuscript with the Dutch title Een algorithme ter voorkoming van de dodelijke omarming—an algorithm for avoiding this “deadly embrace.”
When operating-systems courses teach mutual exclusion, semaphores, and deadlocks today, students are not merely learning historical curiosities.
They are moving through problems whose basic language Dijkstra helped shape.
The war against GOTO
Then came GOTO.
In 1968, Dijkstra's famous text appeared under the title “Go To Statement Considered Harmful.”
Interestingly, that was not its original title.
Dijkstra had called the text A Case Against the Go To Statement. The editor Niklaus Wirth changed it for publication.
That likely produced one of the most enduring phrases in programming history.
Today the debate is almost hard to imagine.
We write:
if
else
for
while
Functions.
Blocks.
Scopes.
Structures.
At the time, being able to make control flow jump almost arbitrarily through a program with GOTO was far more normal.
Dijkstra's objection was not simply, “This syntax is ugly.”
He had a deeper problem with it.
The more arbitrary a program's control flow becomes, the harder it is for a person to follow its state.
And when we can no longer follow that state, we lose the ability to reason sensibly about the program's correctness.
Robert C. Martin aptly describes Dijkstra's argument: structured constructs such as sequence, selection, and iteration limit control flow and thereby make programs more analyzable.
That sounds banal today.
That is the highest compliment one can pay a fundamental idea.
It won.
The real point was never GOTO
It would still be wrong to reduce Dijkstra's contribution to “the guy who got rid of GOTO.”
That would only be the next abbreviated version of his story.
His actual subject was complexity.
Computers became faster.
Memory became larger.
Programs became more extensive.
But the human brain did not get an upgrade.
For Dijkstra, that was the central problem of software development.
We can build machines that perform millions or billions of operations. Yet we must still create programs that a human can reason about.
Structured programming was therefore not a matter of style.
It was a method for limiting the possible mental state space of a program.
And that brings us to the part of Dijkstra that may be more relevant today than his algorithm.
Correct by construction
Dijkstra had little patience for the idea of simply testing and debugging software until it eventually looked correct.
One of his best-known sentences puts it plainly:
“Program testing can be used to show the presence of bugs, but never to show their absence.”
Tests can find bugs.
What they cannot prove is that no bugs remain.
At first, that sounds like academic pedantry.
Until you build software on which money, infrastructure, medical devices, or millions of users depend.
Dijkstra's ideal went further.
Programs should not first be written and then beaten into correctness.
They should be developed so that their correctness can be understood from their construction.
His 1972 Turing Award lecture was not accidentally titled “The Humble Programmer”; the Dijkstra archive lists it as EWD340 and as a publication in Communications of the ACM.
The humility in that title is crucial.
Not because Dijkstra himself was known for verbal restraint.
But because good programmers must accept that their capacity to hold complexity in their minds is limited.
The computer is not the weak link.
We are.
Dijkstra and the LLM era
And that brings us, of all places, to 2026.
Today we can tell a model in English that we need an API, a parser, or a React component, and seconds later code exists.
That is remarkable.
It is also almost perfectly designed to make Dijkstra nervous.
Because the question has shifted.
We used to ask:
Can I write this program?
Increasingly, the question now is:
Can I understand and take responsibility for what has just been written for me?
An LLM can generate a hundred lines of code faster than a person can read them carefully.
With agents, that becomes a thousand.
Then ten thousand.
Dijkstra's warning about unmanageable complexity does not become outdated as a result.
It becomes uncomfortably current.
We could produce more code than ever before while understanding less of it at the same time.
Dijkstra would probably care less about whether the code came from a human or a model.
His question would likely be the same:
Why do you believe this program is correct?
“The tests are green” would hardly have satisfied him.
His EWDs were blogs before the web
Dijkstra did not publish only papers.
For decades he wrote numbered manuscripts, notes, travel reports, technical reflections, and comments: the famous EWDs.
The University of Texas describes how he sent these texts to colleagues and how some eventually gained wide informal circulation through photocopies. Today, the university archives more than a thousand of these manuscripts.
It is hard not to see an early form of technical blogging in them.
EWD249.
EWD268.
EWD340.
A twenty-first-century developer might have used a personal website, an RSS feed, and an incredibly minimalist static-site generator for this.
Dijkstra had paper.
The technology is different.
The impulse is the same: develop an idea, formulate it precisely, and give it to other people so they can think about it.
The inconvenient programmer
Dijkstra was not exactly known for wrapping his judgments gently.
APL?
A catastrophe, brilliantly executed to perfection.
BASIC?
In his view, pedagogically almost irreparable.
COBOL?
Not a favorite either.
A collection at the University of Scranton documents some of these notorious statements.
We need not adopt this polemic.
But we should understand what stood behind it.
Dijkstra believed programming languages shape our thinking.
For him, a poor abstraction therefore did not merely produce ugly code.
It trained bad habits of thought.
That also explains why he took structured programming so seriously.
Why he took formal methods seriously.
Why he took comprehensibility seriously.
For Dijkstra, programming was not an activity in which we somehow make a machine understand what it should do.
It was the art of ordering our thoughts far enough that a program could safely emerge from them at all.
What we really owe Dijkstra
Of course, we owe him the shortest-path algorithm.
We also owe him semaphores.
Early work on multiprogramming.
Essential contributions to thinking about deadlocks.
Structured programming.
Work on ALGOL.
Formal methods.
A vocabulary with which generations of computer scientists could speak about programs. The Dijkstra archive accordingly names fundamental contributions from algorithm design to formal verification.
But even this list misses the most interesting point.
Dijkstra's greatest achievement may not have been any individual invention.
It was an attitude.
Software is not magical text that we write and then try out.
A program is a formal object.
We can think about its structure.
We can remove unnecessary states.
We can limit its control flow.
We can choose abstractions that ease the burden on our minds.
We can try not to test correctness into it only at the end, but to consider it from the beginning.
Almost everything about modern software development occasionally contradicts that ideal.
Our systems are gigantic.
Our dependency trees are absurd.
Our distributed systems have failure states that no one person can fully see.
And machines can now generate code faster than we can understand it.
That is precisely why it is worth reading Dijkstra again.
Not out of nostalgia.
Out of self-defense.
FAQ about Edsger Dijkstra
Who was Edsger W. Dijkstra?
Edsger Wybe Dijkstra was a Dutch computer scientist and one of the most influential members of early computer science. His work included algorithms, programming languages, operating systems, distributed systems, and formal specification and verification.
What is Dijkstra best known for?
He is best known today for Dijkstra's algorithm for finding shortest paths in weighted graphs. His scientific work went far beyond that, however.
Did Dijkstra invent the semaphore?
Dijkstra introduced the semaphore as a fundamental synchronization idea in the context of cooperating processes. His work on mutual exclusion and multiprogramming is among the foundations of early concurrency research.
What does “Go To Statement Considered Harmful” mean?
The text published in 1968 argued against uncontrolled GOTO jumps because they make programs harder to follow and therefore harder to analyze correctly. Its original title was A Case Against the Go To Statement; Niklaus Wirth changed it for publication.
Did Dijkstra invent structured programming?
Structured programming emerged from several theoretical and practical developments. Dijkstra became one of its most important and influential advocates, however, and developed his ideas about it further in several works.
What did Dijkstra mean when he said testing can only show the presence of bugs?
He meant that a successful test shows only that one tested case works. Even a great many successful tests do not generally prove that a program contains no undiscovered errors.
What are the EWDs?
The EWDs are Dijkstra's consecutively numbered manuscripts, including technical notes, essays, travel reports, and comments. More than a thousand of these documents are now archived by the University of Texas.
Why is Dijkstra still relevant to developers today?
Because his central problem has not changed: software grows faster than humans can manage complexity. Structure, comprehensible abstractions, controlled program flow, and justifiable correctness therefore remain relevant for cloud systems, concurrency, and AI-generated code.
Conclusion: Thank you, Dijkstra
There are people in the history of computer science whose names we use without thinking about the people any longer.
We say Dijkstra.
We mean an algorithm.
Perhaps we should stop doing that.
Perhaps, when we hear that name, we should think of semaphores. Of deadlocks. Of structured programming. Of formal correctness. Of ALGOL. Of the EWD manuscripts. Of the almost obsessive demand that a program should not merely run, but be understandable.
Dijkstra did not simply give us a way to find the shortest path through a graph.
He spent much of his life looking for a shorter path through the complexity of programming.
We have not found it completely yet.
But a surprising number of signposts bear his name.
For that, we owe him something.
At least a thank-you.
And perhaps, before we merge the next pull request, a second thought about whether we can actually prove that the thing works.
Further reading
- Edsger W. Dijkstra: “Go To Statement Considered Harmful” – the original 1968 text
- “The Humble Programmer” (EWD340) – Dijkstra’s 1972 Turing Award lecture
- The EWD Archive at the University of Texas at Austin – more than a thousand of Dijkstra’s manuscripts
- Dijkstra’s Shortest-Path algorithm – Cornell CS tutorial – an accessible introduction
- Memorable Quotes from Edsger Dijkstra – University of Scranton – including his polemical remarks on APL, BASIC, and COBOL