Zusammenfassung

  • Nach ihrer Rückkehr in den Dienst der U.S. Navy im Jahr 1967 half Grace Hopper dabei, Ziele der Compiler-Standardisierung in ein organisiertes Prüfverfahren zu überführen. In ihrer Oral History von 1980 schrieb sie George Baird eine wichtige Methode zu, mit der gemeinsame COBOL- und FORTRAN-Tests auf unterschiedlichen Rechnern ausgeführt werden konnten.
  • Die U.S. Navy-Tests machten ausgewählte Sprachfunktionen und ihre Ergebnisse überprüfbar. Sie bewiesen weder die vollständige Fehlerfreiheit eines Compilers noch die Abdeckung aller möglichen Kombinationen oder die unveränderte Übertragbarkeit beliebiger Anwendungen.
  • Ein Standard, der Nachweis, dass ein Compiler benannte Tests besteht, und der Beleg, dass ein konkretes Programm in einer anderen Umgebung funktioniert, sind miteinander verbunden, aber nicht dasselbe. Wer sie gleichsetzt, macht aus begrenzter Evidenz ein unbegrenztes Versprechen.

Der Standard war noch kein Prüfergebnis

Für eine Behörde, die Rechner verschiedener Hersteller beschaffte, schien eine gemeinsame Sprache eine wirtschaftliche Lösung zu versprechen: Ein Programm sollte nicht dauerhaft an die Maschine eines einzigen Anbieters gebunden sein. Doch dass zwei Angebote COBOL nannten, sagte noch nicht, ob ihre Compiler alle vorgeschriebenen Funktionen akzeptierten oder dieselben Resultate lieferten.

Der Standard beschrieb das erwartete Verhalten; er maß nicht automatisch das ausgelieferte Produkt. Beschaffer brauchten eine wiederholbare Prüfung: ein Programm, das der Compiler annehmen sollte, ein erwartetes Ergebnis, das tatsächliche Ergebnis und einen Bericht, der Abweichungen lokalisierte. Aus der Kompatibilitätsbehauptung wurde so eine betriebliche Frage.

An diesem späteren Abschnitt von Hoppers Laufbahn setzt die Geschichte an. Statt erneut die Erzählung vom ersten Compiler oder eine COBOL-Erfolgsgeschichte mit einer einzelnen Urheberin zu erzählen, geht es darum, wie aus Standardisierung eine Validierungspraxis wurde. Portierbarkeit hing von gemeinsamer Syntax ab, aber ebenso vom tatsächlichen Verhalten eines Compilers und davon, was die Tests belegen konnten.

Die technische Vorgeschichte war gemeinschaftlich. In seinem Bericht von 1972 über das COBOL-Compiler-Validierungssystem des Department of Defense beschrieb George N. Baird eine Arbeitsgruppe, die 1963 begonnen hatte. Ihre Programme sollten prüfen, ob Compiler die im Standard festgelegten Funktionen bereitstellten. Es ging weder darum, jedes Produkt zu debuggen, noch sämtliche möglichen Kombinationen durchzuspielen. Man wählte Funktionen aus, testete sie einzeln oder in ausgewählten Kombinationen und hielt die Ergebnisse fest.

Fehler sichtbar und lokalisierbar machen

Baird zufolge bauten die ersten U.S. Navy-Routinen auf dieser Vorarbeit auf und lieferten aussagekräftigere Berichte: Sie verglichen das tatsächliche mit dem erwarteten Ergebnis und zeigten, in welchem Verfahren ein Fehler auftrat. Der vorläufige Satz umfasste zwölf Programme mit ungefähr 5.000 Zeilen Quelltext.

Das verändert die Bedeutung von „kompatibel“. An die Stelle einer umfassenden Herstellerzusage trat eine begrenzte, reproduzierbare Aussage: Diese Compiler-Version akzeptierte diese Funktionen und lieferte unter diesen Testbedingungen diese Ausgaben. Andere Teams konnten den Lauf wiederholen und Ergebnisse vergleichen. Das Verfahren ersetzte kein Urteil, machte aber Teile davon überprüfbar.

Hopper baute eine Fähigkeit auf – nicht allein ein System

In ihrer Oral History von 1980 erinnerte sich Hopper daran, dass Norman Ream, ein für Datenverarbeitung zuständiger U.S. Navy-Beamter, sie 1967 um die Rückkehr in den aktiven Dienst gebeten hatte. Ihre Aufgabe sei gewesen, Prüf- und Validierungsverfahren zu entwickeln, die Sprachstandards stützten und Software portierbarer machten. Zur Erklärung verglich sie das mit Produkttests gegen eine Spezifikation.

Hopper sagte, sie habe Programmierer angefordert, statt die Arbeit allein zu erledigen. Sie nannte den zivilen Mitarbeiter Ed Ford, einen Lieutenant und zwei Sailors, darunter Baird; Arnold Johnson kam später hinzu. Ein Bericht der Datamation von 1971 beschrieb die U.S. Navy-Validierungsroutine als Entwicklung eines von Captain Hopper geleiteten Teams. Das stützt ihre Führungsrolle, nicht die Behauptung, sie habe das System allein programmiert.

Auch der Zeitstand ist wichtig. Im Januar 1971 berichtete Datamation, die U.S. Navy verlange die Validierung von COBOL-Compilern; das Department of Defense und das National Bureau of Standards hätten sich grundsätzlich auf die Entwicklung einheitlicher Routinen gegen den ANSI-Sprachstandard verständigt. „Grundsätzlich vereinbart“ bedeutete noch keinen abgeschlossenen, regierungsweiten Dienst. Der Bericht hält die institutionelle Richtung zu diesem Zeitpunkt fest, nicht den späteren Abschluss.

Die Methode, die Hopper Baird zuschrieb

Die aufschlussreichste Stelle in Hoppers Rückblick ist eine Zuschreibung, kein Anspruch auf Erfinderschaft. Baird habe, so Hopper, ein Verfahren entwickelt, das maschinenspezifische Sondernamen und Steuerkarten-Details von den gemeinsamen Tests trennte. Eine kleine Konfigurationsdatei lieferte die Unterschiede für den jeweiligen Rechner; die gemeinsame Testlogik blieb in standardisiertem COBOL.

Damit musste auch der Test selbst portierbar sein. Hätte man jede Prüfung für jeden Compiler neu schreiben müssen, wären Wartung und Vergleich aufwendiger und anfälliger für unbeabsichtigte Unterschiede geworden. Die Trennung von gemeinsamer Logik und maschinenspezifischer Konfiguration machte Wiederverwendung möglich, ohne zu behaupten, alle Rechner hätten identische Konventionen.

Hoppers Erinnerung ist rückblickend und als ihr Bericht über Entwurf und Arbeitsteilung zu lesen. Bairds Aufsatz von 1972 verankert das Validierungssystem und seine technische Struktur unabhängig davon. Zusammengenommen stützen die Quellen ein ausgewogenes Bild: Hopper half, Auftrag und Team aufzubauen; Baird lieferte einen wichtigen Mechanismus für den Betrieb auf verschiedenen Rechnern; die Standardisierungs- und Testgeschichte hatte weitere Beteiligte und Vorläufer.

Was eine bestandene Suite nicht aussagte

Ein erfolgreicher Lauf belegte, dass ein Compiler die ausgewählten Funktionen unter den Testbedingungen korrekt behandelte und die erwarteten Ergebnisse erzeugte. Er belegte nicht, dass die Suite jede zulässige Kombination, jeden denkbaren Implementierungsfehler oder jedes künftige Behördenprogramm abdeckte.

Diese Grenze galt nicht nur für COBOL. Die NIST-Darstellung eines getrennten FORTRAN-Testprojekts von Betty Holberton und Elizabeth Parker erklärt, weshalb eine endliche Testmenge die vollständige Korrektheit eines Compilers nicht beweisen kann. Es handelte sich um ein paralleles Projekt des National Bureau of Standards, nicht um Hoppers U.S. Navy-COBOL-Suite. Die Unterscheidung ist technisch und historisch wichtig: Verschiedene Teams machten Konformitätsprüfungen für verschiedene Sprachen zu einer institutionellen Praxis.

Compiler-Konformität und die Portierbarkeit einer Anwendung liegen zudem auf verschiedenen Ebenen. Ein Compiler kann ausgewählte Standardtests bestehen, während eine Anwendung von einer Herstellererweiterung, einem Betriebssystemdienst, einem Dateiformat, Laufzeitverhalten oder einer Datenrepräsentation abhängt. Das folgt aus dem begrenzten Testumfang; es ist keine Behauptung, die U.S. Navy-Suite habe jede solche Abhängigkeit untersucht. Für eine Migration braucht es weiterhin Anwendungstests und eine Beschreibung der tatsächlichen Laufzeitumgebung.

Die praktische Lehre lautet nicht, Standards oder Tests zu misstrauen. Sie lautet, die Evidenz genau zu benennen: Der Standard definiert erwartetes Verhalten. Eine Konformitätssuite prüft einen begrenzten Ausschnitt der Implementierung. Ein Migrationstest untersucht das System, das ein Käufer tatsächlich übertragen möchte. Wer alle drei schlicht „Portabilität“ nennt, verdeckt das verbleibende Risiko.

Ein messbarer Beitrag statt eines Heldenmythos

Hoppers Rolle in dieser Episode wird interessanter, wenn man sie nicht überhöht. Sie half dabei, aus einem weitreichenden Interoperabilitätsziel eine organisatorische Validierungsfähigkeit zu machen. Zugleich beschrieb sie eine Führungspraktik, die in Erzählungen über Einzelgenies leicht verschwindet: Mitarbeiter einzubinden und die technische Idee ausdrücklich der Person zuzuschreiben, die den entscheidenden Mechanismus entwickelte.

Bairds Beitrag zeigt, warum diese Zuschreibung zählt. Portierbarkeit war nicht nur ein Versprechen im Wortlaut eines Sprachstandards. Sie hing ebenso von Testdesign, Maschinenkonfiguration, Ergebnisvergleich und wiederholbarer Ausführung ab. Ohne beobachtbare Tests blieb dem Käufer eine Behauptung. Ohne klaren Geltungsbereich konnte ein bestandenes Testset ein größeres Versprechen werden als seine Evidenz. Ohne korrekt zugeordneten Beitrag blieb auch die technische Erklärung unvollständig.

Bei langlebiger Software sollte deshalb der Nachweis mit der Behauptung reisen: Welche Standardrevision, welcher Compiler-Build, welche Tests, welche maschinenspezifische Konfiguration und welche Ergebnisse? Hoppers U.S. Navy-Arbeit beseitigte keine Unterschiede zwischen Herstellern. Sie gab Institutionen eine Möglichkeit, einige davon offenzulegen, Implementierungen zu vergleichen und Beschaffungsentscheidungen auf eine belastbarere Grundlage zu stellen.

Quellen