Grace Hopper, Compiler und COBOL

Grace Hopper und die Compilerentwicklung stehen in dieser Lineage für eine grundlegende Verschiebung: Programme müssen nicht mehr unmittelbar in einer maschinennahen Form geschrieben werden. Sie können in einer höheren, stärker an menschlichen und fachlichen Begriffen orientierten Sprache formuliert und anschließend übersetzt werden.

Ein Compiler übernimmt diese Übersetzungsrolle. Er liest Quelltext, prüft Regeln, erkennt Strukturen und erzeugt daraus eine ausführbare oder maschinennähere Form. Dadurch entsteht eine Zwischenschicht zwischen Programmiererin und Maschine. Diese Schicht ist nicht nur bequem, sondern fachlich bedeutsam: Sie trennt Programmbeschreibung, Übersetzung und Ausführung.

Für E3 ist diese Idee zentral. Wenn Lernende Java schreiben, sprechen sie nicht direkt mit der Hardware. Sie formulieren Quelltext in einer Sprache mit Syntax, Datentypen und Regeln. Werkzeuge übersetzen, prüfen und melden Fehler. Hopper und Compiler erklären, warum diese Zwischenebene überhaupt existiert.

Compiler stehen im Kontext einer Bewegung weg von unmittelbarer Maschinennähe. Frühe Programmierung ist eng an konkrete Maschinen, Speicherstellen, Schalter, Lochkarten oder maschinennahe Befehle gebunden. Das macht Programme schwer lesbar, fehleranfällig und stark abhängig von der jeweiligen Hardware. Höhere Sprachen und Übersetzer verändern diese Situation.

Der Kontext ist nicht nur technisch, sondern auch organisatorisch. Je mehr Programme in Wissenschaft, Verwaltung, Wirtschaft und Technik eingesetzt werden, desto wichtiger wird es, dass Menschen Programme verständlich schreiben, prüfen, warten und weitergeben können. Eine Programmiersprache muss deshalb nicht nur maschinell eindeutig, sondern auch für Menschen bearbeitbar sein.

Grace Hopper und COBOL stehen für diese Öffnung der Programmierung. Programme sollen näher an fachlichen Aufgaben und organisatorischen Prozessen formuliert werden können. Damit bereiten Compiler und anwendungsnahe Sprachen den späteren Unterrichtsgedanken vor: Programmieren ist formale Problembeschreibung, nicht bloß Maschinenbedienung.

Technisch lässt sich die Compilerperspektive über drei Rollen erschließen. Quelltext ist die von Menschen geschriebene Programmbeschreibung. Syntaxregeln legen fest, welche Formen gültig sind. Der Compiler prüft und übersetzt diesen Quelltext in eine Form, die näher an der Ausführung liegt. Dabei können Fehler erkannt werden, bevor ein Programm sinnvoll ausgeführt wird.

Diese Struktur erklärt viele Erfahrungen des Programmierunterrichts. Eine fehlende Klammer, ein falscher Datentyp oder ein falsch geschriebener Bezeichner ist nicht einfach ein ästhetischer Fehler. Der Quelltext verletzt eine Regel, die das Übersetzungswerkzeug benötigt, um eine eindeutige Programmbedeutung herzustellen. Fehlermeldungen sind daher Hinweise auf die Grenze zwischen menschlicher Schreibweise und maschineller Übersetzbarkeit.

Für Java wird diese Struktur später besonders sichtbar. Java-Quelltext wird kompiliert, typischerweise in Bytecode, der von einer Laufzeitumgebung ausgeführt wird. Die genaue technische Ausgestaltung ist anders als bei frühen Compilern, aber die Grundidee bleibt: Programmiersprache, Übersetzung und Ausführung sind unterscheidbare Ebenen.

Compiler materialisieren eine neue Form von Programmierarbeit. Ein Programm wird nicht mehr nur als unmittelbare Folge maschinennaher Befehle geschrieben. Es wird in einer Sprache formuliert, gespeichert, geprüft, übersetzt und anschließend ausgeführt. Damit wird Programmieren stärker werkzeuggebunden und arbeitsteilig.

Diese Materialisierung verändert auch die Rolle von Fehlern. Ein Programmierfehler ist nicht nur ein falsches Ergebnis am Ende. Viele Fehler werden bereits in der Übersetzung sichtbar. Syntaxfehler, Typkonflikte oder unbekannte Namen zeigen, dass Quelltext nicht den Regeln der Sprache entspricht. Dadurch entsteht eine Diagnoseebene, die für Unterricht besonders wichtig ist.

COBOL und compilernahe Entwicklungen zeigen außerdem, dass Programmiersprachen auf bestimmte Einsatzfelder antworten. Wissenschaftliche Berechnung, Verwaltung, Wirtschaft oder Simulation stellen unterschiedliche Anforderungen. Programmiersprachen sind daher nicht neutral; sie modellieren, welche Probleme besonders gut ausgedrückt werden können.