Exoten

Was als exotisch gilt, ist eine Frage von Zeit- und Standpunkt. Leitmotiv für die hier getroffene Auswahl von Programmiersprachen ist der Gedanke, Exotik nicht um ihrer selbst willen - etwa in Gestalt einer Collage von ‘weird constructs’ - sondern um ihrer Fruchtbarkeit für die Welt des Normalen willen vorzuführen. Das Ziel dieser Serie, auf Information hinzuweisen, die das Internet bietet, stößt allerdings an seine Grenzen: Tatsächlich vermag eine sorgfältig aufgebaute Fachbibliothek immer noch mehr zu bieten. Die Sprachen sind exotisch insofern, als sie auf den ersten Blick so scheinen mögen. Andererseits zeichnen sie sich dadurch aus, dass sie Spuren in der Gegenwart hinterlassen haben.

Gemeinsam ist ihnen, dass sie innovative Konstrukte einführten, die Programmierer dabei unterstützen sollten, Code in sinnvoller Weise in Module zu gliedern. Dieses Thema verbindet Sprachen, die es in den Werkzeugkasten des Mainstreams geschafft haben, mit solchen, denen dies verwehrt blieb und die deshalb als exotisch gelten.

Wahrscheinlich ist das Ziel, Software zu modularisieren, so alt wie die Softwareentwicklung selbst. In den 60er-Jahren des letzten Jahrhunderts hatten sich als Mittel dazu die Unterprogrammtechnik und die getrennte Übersetzung etabliert. Einen Fortschritt brachten an der Wende der 60er/70er-Jahre Studien von Forschern wie David Parnas, Barbara Liskov, O.-J. Dahl, C.A.R. Hoare und John Reynolds. Entscheidend wären - in der Formulierung eines klassischen Papiers von Parnas - die Kriterien, anhand derer Softwaresysteme in Module zu zerlegen seien. Der Schlüssel zu stabilen, isoliert erstellbaren und verstehbaren Modulen mit kleiner Schnittstelle seien die Datenstrukturen und die zu ihrer Inspektion und Modifikation erforderlichen Operationen. Im Verhältnis zu den bisherigen Ansätzen, die sich vorwiegend an der Ablaufsteuerung orientierten, bedeutete dies eine Art kopernikanische Wende.

Die erste Programmiersprache, die das Bündeln von Variablen und Operationen durch ein besonderes Sprachkonstrukt unterstützte, war Simula67, eine Erweiterung von Algol60, das in der europäischen akademischen Informatik (die damals noch nicht als eigenständiger Fachbereich existierte) chic war. Simula67, 1967 am Norwegian Computing Center von Dahl und anderen geschaffen, befreite den Algol-Block - jene begin/end-Klammer, die Variablendeklarationen, Prozedurdefinitionen und Anweisungen verband - aus der Einbettung in den linearen Kontrollfluss und verschob den Activation Record vom Stack in den Heap. Die abgelösten Blöcke hießen jetzt Klassen, waren beliebig oft aufrufbar und ihre Inkarnationen lebten, solange es noch Referenzen auf sie gab - automatische Speichermüllabfuhr inklusive, sobald dies nicht mehr der Fall war. Unter Kennern gilt die Sprache auch heute noch als ‘significant improvement upon most of its successors’ - Nachfolgern wie Smalltalk, C++ und Java.

Was Simula kann, kann Lisp schon lange

In ihrer skandinavischen Heimat, doch auch im Ostblock, in Schottland, Kanada und der BRD hatte Simula treue Anhänger. Die Université de Montréal unterhält heute noch eine Simula-Seite, eine Vielzahl von Hinweisen bringen die Cetus-Links unter. Theoretische Einsichten vermittelt die Programmiersprachenvorlesung (http://www.stanford.edu/class/cs242/Autumn1997/outlines-95/simula.html) von Kathleen Fisher. Lisp-Experten wissen natürlich, dass alles, was die Klassen von Simula und allem, was danach kam, leisteten, mit Lisp schon längst ging und auch mit den moderneren funktionalen Sprachen wie ML geht (zu SML/NJ, zu caML).

Kathleen Fisher macht das durch ein ML-Beispiel deutlich: Alles was class kann, kann auch let, und eine Klassenausprägung ist nichts anderes als ein lexikalischer Abschluss: eine Klammer, innerhalb der sich die Evaluation eines Ausdrucks unter einer Menge von Bindungen - Assoziationen von Namen mit Werten, die auch Funktionen sein können - vollzieht.

Litt Simula67 noch unter einer inkonsistenten Semantik, die eine Mischung herkömmlicher Datentypen beziehungsweise Variablen mit fest im Stack verankertem Speicher mit den neuen, durch Klassen begründeten Objekttypen kannte, bereinigte Barbara Liskov 1973/74 mit Clu die Situation, indem sie sich am Modell von Lisp orientierte: Datenobjekte lebten jetzt nur noch im Heap und Variablen enthielten nur noch Referenzen auf sie - das Vorbild auch für heutige Sprachen wie Python. Allerdings verband sie das mit einem starken, statischen Typkonzept; wobei sie zwischen der Spezifikation und der Implementierung von Typen eine undurchdringliche Mauer errichtete. Das hier eingeführte Geheimnisprinzip machte es nicht nur unnötig, sondern verhinderte es auch, bei der Verwendung eines Typs von Eigenschaften seiner Implementierung Gebrauch zu machen. Die Kombination aus Geheimnisprinzip und Objektkonzept ermöglichte isolierbare und parameterisierbare Module. Letzteres bedeutete, dass Cluster, wie die Module hießen, von anderen Typen, deren Implementierung geheim blieb, abhängen konnten; ein Behältertyp etwa vom Typ der enthaltenen Objekte - ein Prinzip, dessen Tragweite die Schöpfer von Ada nur unvollständig und die von Java überhaupt nicht verstanden. (Wissenswertes über Ada.)

Auf dem MIT-Server gibt es immer noch die Clu-Seiten. Lesenswert ist dort vor allem die Clu-Geschichte aus der Feder der Schöpferin. Liskov entwickelte die Ansätze von Clu in den 80er-Jahren weiter, fügte vor allem eingeschränkte Typparameter, Vererbung und die Untertyp-Relation hinzu; wobei sie die den gängigen objektorientierten Typsystemen zugrunde liegende Irrlehre, dass Unterklassen auch Untertypen seien, verwarf. Die Nachfolgesprache Theta hat ihre Seiten ebenfalls am MIT.

Eine gewisse Breitenwirkung entfalteten die hier skizzierten Ideen erst über die Informatik-Lehre und die dort eingesetzten Sprachen. UCSD-Pascal erweiterte die Basissprache um ein Modulkonzept mit Geheimnisprinzip. Die Units genannten Module waren keine Generatoren für dynamische Heap-Objekte, sondern statische Objekt-Solitäre. Neu und von großer Tragweite war dagegen die Implementierung durch eine virtuelle Maschine, die das Vorbild für Java darstellte. Über UCSD-Pascal informieren das UCSD-Museum und die Seiten des Educational Technology Center der UC Irvine.

In Deutschland machte Elan, an einigen Unis und Gymnasien verbreitet, die nachwachsenden Generationen mit dem Modulkonzept in verkürzter Form vertraut. Auch Elan lief - unter dem Betriebssystem Eumel - auf einer virtuellen Maschine. Und auch Eumel war avantgardistisch: Ein Microkernelsystem, in dem alle Interprozesskommunikation durch Message-Passing stattfand. Ein Einstieg in Elan findet sich bei der TU Dresden, die umfassend über L4, den aktuellen Eumel-Nachfolger informiert.

Die erste Sprache, die die Konzepte von Simula und Clu vereinigte, war das immer noch ziemlich exotische Eiffel. Infos unter www.eiffel.com und www.cetus-links.org/oo_eiffel.html. (ka)