Programmierung in absoluten Binärzahlen
Die ersten Programmierer schrieben in absoluten Binärzahlen: jede Anweisung & jede Adresse in rohen Binärziffern. Eine einzelne Anweisung könnte wie 01100101 00001010 aussehen — Anweisungscode & Speicheradresse in Binär.
Das Spaghetticode-Problem
Wenn ein Fehler das Einfügen einer neuen Anweisung erforderte, sahen sich Programmierer einem Dilemma gegenüber. Das Einfügen an Ort und Stelle bedeutete, dass jede nachfolgende Anweisungsadresse um eins verschoben wurde — was erforderte, dass der Programmierer jeden Adressenverweis im gesamten Programm aktualisiert. Katastrophal.
Die Lösung: ersetzen Sie die Anweisung unmittelbar vor der Einfügungsstelle durch einen Sprung zu leerem Speicher. An dieser leeren Position: schreiben Sie die überschriebene Anweisung, fügen Sie die neuen Anweisungen hinzu, dann springen Sie zurück. Wenn Fehler in den Korrektionen auftauchten, wenden Sie denselben Trick erneut unter Verwendung von anderem leerem Speicher an.
Ergebnis: Der Ausführungspfad durch das Programm sprang zu scheinbar zufälligen Positionen. Hamming nannte dies einen 'Behälter Spaghetti.' Der Kontrollfluss-Pfad, auf Papier gezeichnet, sah genau wie verwickelter Spaghetti aus.
Die Fluchtrouten
Zwei unmittelbare Verbesserungen: Oktalnotation (Binärziffern in Sätze von 3 gruppieren) & Hexadezimalzahlen (Gruppen von 4, mit A–F für Werte über 9). Diese reduzierten Schreibfehler, lösten aber nicht das grundlegende Adressproblem.
Symbolische Assemblierung (z. B. IBMs SAP — Symbolic Assembly Program — & SOAP — Symbolic Optimizing Assembly Program auf der IBM 650) erlaubten Programmierern, Anweisungsnamen (ADD, MOVE) & symbolische Adressetiketten statt Binär zu schreiben. Der Assembler übersetzt beim Eingeben automatisch zu Binär & verwaltete Adresszuweisungen.
SOAP führte eine zusätzliche Optimierung durch: es arrangierte Anweisungen auf der rotierenden Trommel, sodass die nächste Anweisung beim Lesekopf ankam, genau wenn die vorherige abgeschlossen wurde — Minimallatenzkodierung. SOAP kompilierte sogar sich selbst: Programm A verarbeitet als Daten, um B zu produzieren, B auf A ausgeführt, um zu messen, wie viel Selbstkompilierung es verbesserte.
Bibliotheken & Versetzbar Code
Hamming bemerkte, dass die Idee wiederverwendbarer Software (mathematische Bibliotheken) sehr früh kam — Babbage hatte sie konzipiert. Das Problem: eine Bibliothek mit absoluter Adresse erforderte, dass jede Routine jedes Mal dieselben Speicherpositionen belegte. Wenn die Gesamtbibliothek zu groß wurde, konkurrierten Programme um dieselben Adressen.
Die Lösung: versetzbar Code. Der Assembler erzeugt Anweisungen, die auf Speicher relativ verweisen — Offsets von einer Basisadresse — anstelle von absoluten Adressen. Ein Linker löst die endgültigen Adressen zur Ladezeit auf.
Von Neumanns unveröffentlichte Berichte (weit verbreitet) beschrieben die notwendigen Programmiertricks. Das erste veröffentlichte Programmierbuch (Wilkes, Wheeler & Gill, EDSAC, 1951) kodifizierte diese Techniken.
Die Sprachendesign-Abzweigung
FORTRAN (1957, IBM) & ALGOL (1958, internationales Komitee) repräsentieren zwei Designphilosophien, die radikal unterschiedliche Ergebnisse produzierten.
FORTRAN
John Backus leitete das FORTRAN (FORmula TRANslation)-Projekt bei IBM. Das Designziel: die Sprache leicht für Wissenschaftler & Ingenieure zu machen, sie zu verwenden. FORTRAN akzeptierte mathematische Notation, die sich für seine Benutzer natürlich anfühlte: A = B + C * D anstelle von ADD B, C; STORE T; MULTIPLY T, D; STORE A.
FORTRAN überlebte 60+ Jahre. Es bleibt in aktiver Verwendung in wissenschaftlichen Berechnungen, Fluiddynamik, Klimamodellierung & Rechnerphysik. Hamming zitierte diese Dauerhaftigkeit als Beweis des erfolgreichen Designs.
ALGOL
ALGOL (ALGOrithmic Language) wurde von einem Komitee von Logikern & Informatikern entworfen, die mathematische Strenge anstrebten: eine logisch saubere, formal definierbare Sprache. Die Backus-Naur-Form (BNF)-Notation zur Beschreibung von Grammatiken wurde zur Spezifikation von ALGOL erfunden.
ALGOL scheiterte in der Praxis. Trotz seiner logischen Eleganz & seines enormen Einflusses auf das nachfolgende Sprachendesign (Pascal, C, & fast jede moderne Sprache stammt von ALGOLs Grammatikkonzepten ab), wurde ALGOL selbst nie weit verbreitet. Hammings Urteil: logisch entworfen, menschlich unbrauchbar.
Die Sprachenhierarchie
Hamming beschrieb eine natürliche Hierarchie von Maschinencode bis durch Assemblierung, höherwertige Sprachen, & letztendlich eine 'problemorientierte Sprache' nahe daran, wie Praktiker über ihr Problembereich denken. Jede Ebene fügt menschliche Lesbarkeit auf Kosten der Maschineneffizienz hinzu.
Hammings vier Sprachendesign-Kriterien
Hamming destillierte die Lektion von FORTRAN vs ALGOL in vier Kriterien für eine erfolgreiche Programmiersprache:
1. Leicht zu erlernen — ein Anfänger kann schnell produktiv werden
2. Leicht zu verwenden — routinemäßige Aufgaben erfordern minimale Zeremonie
3. Leicht zu debuggen — Fehler erzeugen aussagekräftige, lokalisierbare Meldungen
4. Leicht, Subroutinen zu verwenden — Wiederverwendung & Abstraktion erfordern keinen heroischen Aufwand
Er fügte eine strukturelle Beobachtung hinzu: menschliche Sprache trägt etwa 60% Redundanz; geschriebene Sprache etwa 40%. Sprachen mit niedriger Redundanz (wie APL) produzieren elegante Einzeiler, die Experten wunderbar & Anfänger undurchschaubar finden — & die nicht erkannte Fehler enthalten, wenn ein einzelnes Zeichen die Bedeutung ändert.
Die Implikation: eine Sprache, die für logische Eleganz entworfen wurde, optimiert für den falschen Leser. Der Programmierer ist menschlich; Menschen benötigen Redundanz, um Fehler zu erkennen & Absicht zu kommunizieren.
Psychologisches vs. Logisches Sprachendesign
Hamming kehrte zum Kontrast FORTRAN/ALGOL zurück als eine Lektion in institutioneller & menschlicher Dynamik, nicht nur Sprachendesign.
FORTRAN wurde psychologisch entworfen — für die Menschen, die es verwenden würden, speziell Wissenschaftler, die in mathematischer Notation dachten. ALGOL wurde logisch entworfen — für formale Korrektheit & theoretische Eleganz.
Das Paradox, das Hamming identifizierte: eine logisch korrekte Sprache, gegen die Menschen sich wehren, scheitert; eine pragmatisch entworfene Sprache, die Menschen adoptieren, erfolgreich, auch wenn sie logisch unordentlicher ist.
Er zitierte APL als extremen Fall: logisch elegant, einzeilig ausdrückbar, mit seinem eigenen Spezialzeichensatz. Experten liebten es. Normale Programmierer fanden es unleserlich. Ein einzelner Zeichenwechsel könnte die Bedeutung eines Programms stillschweigend umwandeln. APL hat eine kleine engagierte Gemeinschaft & fast null Mainstream-Nutzung.
Das Redundanzargument des Menschen: gesprochene Sprache ist ~60% redundant (wiederholter Kontext, klärende Wörter, vorhersagbare Struktur). Geschriebene Sprache ~40% redundant. Diese Redundanz dient der Fehlererkennung — Menschen sind unzuverlässig, sodass Sprache sich entwickelte, um genug wiederholte Informationen zu tragen, um Fehler zu erkennen & zu korrigieren. Eine Sprache mit niedriger Redundanz entfernt diese Sicherheitsnetz.
Die Compiler-Hierarchie
Hamming beschrieb die Compiler-/Interpreter-Schichtung: ein Programm kann eine höherwertige Sprache lesen & in eine niedrigere übersetzen. Stapeln Sie diese Schichten — jede übersetzt eine Ebene nach unten. Oben: eine domänenspezifische Sprache, die Experten auf einem Gebiet (Biologie, Finanzen, Physik) natürlich schreiben. Unten: Maschinencode. Jeder Übergang ist ein Compiler oder Interpreter.
Vorhersage von Sprachenüberleben
Bis 1993 hatte Hamming viele Sprachen erfolgreich & erfolglos beobachtet. FORTRAN (1957) überlebte. ALGOL (1958) scheiterte. COBOL (1959) überlebte Jahrzehnte in der Geschäftsinformatik. LISP (1958) überlebte in der KI-Forschung. PL/I (1964) versuchte, alles zu vereinigen & scheiterte.
Das Wiederkehrende Muster
Hammings Softwaregeschichte-Kapitel enthält eine wiederkehrende Struktur:
1. Eine schmerzhafte Einschränkung existiert (absolute Adressen, Binärnotation, unmöglich zu wartender Code)
2. Jemand erfindet eine Abstraktionsschicht, die die Einschränkung verbirgt
3. Die Abstraktion ermöglicht neue Skalierung, die neue schmerzhafte Einschränkungen schafft
4. Wiederholen Sie
Binär → Oktal/Hex → symbolische Assemblierung → FORTRAN → strukturierte Programmierung → objektorientierte Sprachen → domänenspezifische Sprachen. Jede Schicht behebt die schmerzhafteste Einschränkung des Vorgängers, während sie eine neue Problemklasse einführt.
Das Spaghetticode-Problem (absolute Adressen) führte zu symbolischer Assemblierung. Große Assemblierungsprogramme führten zu FORTRAN. Große FORTRAN-Programme führten zu strukturierter Programmierung & dann Objektausrichtung. Hammings Vorlesung endete, bevor diese später Übergänge, aber das Muster setzt sich fort.
Seine Lektion für Ingenieure: Sie lösen immer den Schmerz, der von der vorherigen Abstraktion freigelegt wird. Das Verständnis der Schicht, auf der Sie sich derzeit befinden, erfordert das Wissen, warum die darunter liegende Schicht existiert.