Spätestens seit Worse is Better ist uns bewußt, daß unschöne Dinge für das Überleben von Software wohl oder übel von entscheidender Bedeutung sein können. Bei Programmiersprachen ist eines dieser Dinge die nahtlose Zusammenarbeit mit dem Betriebssystem, und das bedeutet in der Regel Integration mit C. Viele interaktiven Programmiersprachen wie Common Lisp leiden unter Schwächen in diesem Bereich.

Nun ist Interaktivität schon etwas, das sich mit C vom Prinzip her ein wenig beißt. C ist eine statisch kompilierte Sprache, noch dazu ohne jegliche Introspektion geschweige denn Reflexion. Daher muß man eine mehr oder weniger dicke Schicht darüberlegen, wenn man etwas Dynamik haben möchte. So eine Schicht nennt man Runtime, und verschiedene Runtimes können sich in Bereichen wie C-Nähe, Effizienz und Dynamik sehr unterscheiden.

Sehen wir uns als Beispiel bestehende freie Common-Lisp-Systeme mit ihren Runtimes an:

1. CMUCL und SBCL haben effiziente, robuste Runtimes mit einer eigenen Speicherverwaltung, die mehr an eine Lispmaschine erinnert als an ein C-Programm, und die auch sonst eher betriebssystemfeindlich als -freundlich ausgelegt sind.

2. ECL ist sehr C-nah und kompiliert Code mithilfe von GCC. Dafür leidet die Interaktivität unter der langen Kompilierzeit und der Abhängigkeit von externen Programmen, und die Geschwindigkeit des Systems ist insgesamt eher weniger berauschend.

3. CLISP ist ein Zwischending. Es ist in C implementiert und sehr interaktiv. Ein nativer Codegenerator fehlt zwar, es wird aber an einem basierend auf libjit gearbeitet. Dennoch ist es nicht viel einfacher, mit C von CLISP aus zu interagieren, als es bei CMUCL und SBCL der Fall ist, weil auch die CLISP-Runtime relativ abgeschottet vom Rest der Welt existiert.

Man kann noch eine Menge anderer Runtimes aufzählen, die außerhalb der Lispgemeinde entstanden sind. NekoVM, HLVM, Squeak, die JVM und die CLR sind allesamt ganz interessante Runtimes (besonders NekoVM*), aber jede einzelne von ihnen leidet unter schlechter C-Integration (Squeak ist hierbei wohl das extremste Beispiel -- kein Wunder, denn Smalltalk war schon immer eine radikal dynamische Sprache und hatte eine entsprechend separatistische Umgebung).

Und dann gibt es da noch Objective-C.

Kompakt, dynamisch, ungeheuer C-nah, nicht aussterbensgefährdet -- und immerhin ist fast der ganze graphische Teil eines beliebten Betriebssystems darauf aufgesetzt, also kann es auch nicht sehr ineffizient sein. Die Objective-C-Runtime bietet sicherlich weniger als z.B. NekoVM. Sie ist low-level, keine Frage. Sie erfüllt jedoch jedes Kriterium, das eine lebensfähige VM in einer C-orientierten Welt erfüllen muß. Sogar Methoden, welche man in der Objective-C-Runtime zur Laufzeit reibungslos auswechseln kann, sind ganz normale C-Funktionen und können als solche aufgerufen werden.

Objective-C ist vielleicht nicht die ultimative, allumfassende Runtime für jede dynamische Programmiersprache der Welt. Aber sie ist näher dran als alles andere, was eine ähnliche Zukunftssicherheit hat.