Das Desiderat der Informatik, Spezifikation und Implementation grundsätzlich zu trennen, bleibt heute der Erfüllung so weit entfernt wie in den siebzigern Jahren, als es theoretisch mit aller Deutlichkeit postuliert wurde.
Die Programmiersprachen bis heute —werden sie auch als “deklarativ” bezeichnet— stellen bloß Implementationssprachen dar. So gibt es eine relationale Abfragesprache wie SQL, aber damit lässt sich nur eine bestimmte Datenbanksoftware, die gewisse Datenstrukturen zur Verfügung stellt, steuern. Denn eine TABLE oder ein INNER JOIN werden immer gleich implementiert. So gibt es auch objektorientierte Sprachen, aber ein Objekt, eine Methode, ein Ereignis usw. werden immer auf derselben Weise von der unterliegenden Laufzeitplattform implementiert. Aus den Wörtern eines Programms ergibt sich linear die Struktur der erstellten Software.
Der Grund der bisherigen Unfähigkeit, Spezifikation von Implementation zu trennen, liegt nicht in irgendwelchen technischen Schwierigkeiten, die noch nicht gelöst wären, sondern eigentlich in der herkömmlichen Sprachauffassung: im Irrtum zu glauben, dass Sprache Sachen bedeutet. Genauer besehen ist das nicht der Irrtum der Menschen im Allgemeinen, sondern der Irrtum allein der gegenwärtigen Theorie, denn man setzt in der Praxis —s. verspielte Kabarettisten, liebende Menschen oder ehrgeizige Politiker— die Sprache auf vielfältiger Weise ein, nur theoretisch geht man von einer völlig falschen Auffassung derer aus.
Die Trennung von Spezifikation und Implementation lässt sich durchgänging und sofort erreichen, indem man den richtigen Begriff des Textes als Vermittler zwischen Programmierer und Software einsetzt. Der Programmierer schreibt einen Text (den Quellcode), der Compiler setzt ihn im Ganzen in lauffähige Software um. Die heutige Compiler sind Satz-Übersetzer. Sie übersetzen einzelne Sätze, und zwar unabhängig voneinander. Die hier vorgeschlagenen Compiler sind hingegen Text-Übersetzer. Im ersten Durchgang führt der Parser eine vollständige syntaktische Analyse des Quellcodes durch. Im zweiten Durchgang erstellt der Compiler aus dem ganzen Text eine ausführbare Datei.
Schauen wir uns als Beispiel eine Liste an. Eine Liste ist eine Datenstruktur, die eine Folge von Elementen darstellt. Man kann alle Elemente als Einheit ansprechen oder sie einzeln der Reihe nach durchgehen. Heute sieht dies so aus: Eine Bibliothek stellt Listen zur Verfügung, die in einem Programm eingesetzt werden können. Verteilt wird die Bibliothek als ausführbare Datei. Beim Kompilieren des Programms werden Aufrufe auf die Bibliothek gesetzt. Beim Kompilieren wird ein Satz wie “nehme das erste Element der Liste und drücke es aus” in Maschinencode wie das Folgende übersetzt:
- setze den Zeiger auf die Liste im Stapel;
- rufe die Funktion Bibliothek::Liste_Get_ErstesElement auf;
- rufe die Funktion IO::Ausgeben auf;
Was wir hier vorschlagen, ist: Die Bibliothek stellt die Definition dessen, was eine Liste ist und wie sie zu handhaben ist, zur Verfügung. Sie wird als Text verteilt, was nicht bedeutet: als Zeichenkette, sondern: als geparseten Text, der durchaus in einem effizienten binären Format gespeichert werden kann. Der obige Satz wird nicht immer gleich übersetzt, sondern führt zu völlig anderem Maschinencode je nach dem, um welche Liste es sich handelt und was für Elemente sie enthält. Der Compiler weiß hier einfach, dass er etwas “als Liste” aufzufassen hat, und weiß, was es bedeutet, von einer “Liste” (was auch immer sie konkret für eine Datenstruktur ist) das erste Element auszuwählen.
Hier wird der Quellcode nicht als “Reihe von Befehlen”, sondern als symbolisches Gebilde aufgefasst. Hier werden die Programmiersprachen nicht als “Werkzeugkisten”, sondern als begriffliche Systeme eingesetzt, mit denen man Beziehungsgeflechte ausdrücken kann. Erst der Text als Ganzes wird, endlich, in ausfürhbaren Code umgeschrieben. Damit wird die Trennung von Implementation und Spezifikation vollständig vollzogen.
Kommentar hinterlassen