Compiler & Interpreter

1957 brachte ein IBM-Team unter John Backus FORTRAN heraus und entschied damit einen Streit, den die meisten Programmierer für unentscheidbar hielten. Wer bis dahin einen Rechner schnell haben wollte, schrieb dessen rohe Befehle von Hand; dass eine Maschine menschenfreundliche Formeln in ebenso dichten Code übersetzen könne wie ein geübter Mensch, galt vielen als Hirngespinst. Drei Jahre brauchte Backus' Gruppe, um das Gegenteil zu zeigen, und das Ergebnis kam handgeschriebenem Assembler so nahe, dass der Einwand einfach in sich zusammenfiel. Danach war das Programmieren ein anderes: Man schrieb, was man meinte — eine mathematische Formel —, und überließ die Seite der Maschine einem Programm, dem Compiler. Sieben Jahrzehnte später verrichtet jeder Compiler unter aller Raffinesse noch immer genau diese eine Arbeit.

Ein Compiler ist am ehesten eine Kette von Übersetzungen, deren jede das Programm eine Stufe tiefer Richtung Maschine trägt. Zuerst wird der rohe Text gelesen und die Zeichenfolge zu Wörtern zusammengefasst; dann wird die grammatische Struktur bestimmt, ganz ähnlich, wie man einen Satz zergliedert, und aus dem flachen Wortstrom entsteht ein verzweigter Baum, der festhält, was worin steckt. Aus diesem Baum baut der Compiler eine innere Darstellung, die absichtlich von allen menschlichen Bequemlichkeiten befreit ist — schlicht, regelmäßig, leicht umzustellen. Hier fällt die eigentliche Arbeit der Optimierung an: Konstanten werden vorab ausgerechnet, unerreichbarer Code fliegt heraus, mehrfach auftretende Berechnungen werden nur einmal ausgeführt, Schleifen werden umgeformt — alles, damit das spätere Ergebnis schneller läuft, ohne dass sich ändert, was es tut. Erst ganz zuletzt entstehen die tatsächlichen Befehle für einen bestimmten Prozessor. Die alte Grenze zwischen kompilierten und interpretierten Sprachen hat sich dabei weitgehend aufgelöst: Die meisten sogenannten Interpretersprachen übersetzen im Stillen zunächst in einen kompakten Zwischencode, und die schnellsten Systeme beobachten das laufende Programm, merken sich, welche Abschnitte heiß sind, und übersetzen gerade diese zur Laufzeit in nativen Code. Durch alles hindurch zieht sich das Typsystem, die tiefste Kraftquelle eines Compilers — jener Bestand an Regeln, der festlegt, welche Fehler auffliegen, ehe das Programm je gelaufen ist. Ein strenges Typsystem baut ein Programm gar nicht erst, das eine Zahl zu einem Stück Text addieren will; ein nachsichtiges lässt diesen Fehler warten, bis der Code im Einsatz ist und jemand ihm beim Scheitern zusieht. Diese eine Entscheidung, weit mehr als die reine Geschwindigkeit, gibt der einen Sprache ihren vorsichtigen und der anderen ihren unbekümmerten Charakter.