Die nächste Softwarelandschaft

In der Informatik sollte man neben der Sacharbeit auch die Kritik pflegen. Wir meinen hier Kritik im Sinne von kritischer Beurteilung, wie in Sprachkritik. Man sollte Informatikkritik betreiben. Denn mit Computern lässt sich Allerlei umsetzen. Die Grenze setzt allein unsere Einbildungskraft. Und die Fantasie ist nichts für Fachleute als solche, sondern sie sollte im gesellschaftlichen Umgang gefördert werden, genauso wie dies bereits mit den Künsten und überhaupt mit der Kultur geschieht.

Wie weit entfernt wir von einer solchen Einstellung wirklich sind, sieht man, wenn man beobachtet, wie einsam ein Wegbereiter der Informatikkritik wie Ted Nelson eigentlich da steht. Seine bemerkenswerten Ansichten über die Informatik, seine Kritik der Softwarelandschaft in den letzten Jahrzehnten, seine Ideen von innovativen Entwicklungen und seine Vorschläge von radikal neuen Herangehensweisen stoßen nur auf Unverständnis. Niemand scheint mit seiner Sprache etwas anfangen zu können: Die Laien fühlen sich nicht angesprochen, als ginge es da um eine Fachfrage, die mit ihnen nichts zu tun hat; die Fachleute fühlen sich angegriffen, als würde man ihre Errungenschaften klein reden, und verstehen kein Wort, weil der höhere Blickpunkt von Nelson ihre Vorstellungskraft völlig übersteigt. Doch Nelsons Diskurs ist wertvoll: Aus der Vogelperspektive hat man nach unten eine klare Übersicht und nach vorne breite Aussichten.

Wenn wir nah am Boden der heutigen Technik bleiben, können wir vor lauter Details die Grundstrukturen nicht sehen. Doch eben diese zu sehen, ist von der größten Wichtigkeit, denn Verbesserungen darin bedeuteten große Sprünge in der Informatik überhaupt.

Wie sieht die aktuelle Software überhaupt aus? Vor allem so: zerklüftet. Die heutige Softwarelandschaft ist ein richtiger Turm zu Babel. Es müssen viele Schnittstellen programmiert werden und man vermisst viel Funktionalität, die fehlt, weil die dafür notwendigen Schnittstellen nicht zur Verfügung stehen. Die aktuelle Software wirkt wie ein Flickenteppich, sogar innerhalb eines einzigen Softwaresystems. Das ist eine Folge des aktuellen Softwaremodells. So gehen wir heute vor: Wollen wir eine Liste ausarbeiten? So setzen wir ein Kalkulationsblatt ein. Wollen wir aber eine Schrift verfassen, so entscheiden wir uns für ein Textverarbeitungsprogramm. Haben wir andererseits gut strukturierte Daten, speichern wir sie in eine relationale Datenbank ab. Das gegenwärtige Modell ist also: es gibt bestimmte Informationsstrukturen, jede ist unabhängig von den anderen und wird durch Spezialprogramme gesteuert. Die unerlässliche Folge ist die Kleinstaaterei: Großer Aufwand ist nötig, um zwischen den einzelnen Insellösungen zu vermitteln, und das Zusammenspiel ist im Ganzen mangelhaft.

Ein großer Fortschritt wird man mit einem neuen Paradigma erzielen, das wir die Textorientierte Software nennen. Aus dem Verständnis dessen, was ein Rechner überhaupt ist, ergibt sich eine neue Softwareauffassung, die zu grundlegenden Verbesserungen führen wird. Doch gehen wir der Reihe nach. Sehen wir zuerst an, was die Informatik im Grunde ist.

Das Wesen des Computers

Der Computer kann in mannigfaltigen Bereichen eingesetzt werden, aber was ist sein Wesen?

Das Wesen der Computer besteht in der maschinellen Verarbeitung von Texten. Auf unterster Ebene besteht ein Rechner aus Schaltkreisen, d.h. physischen Einheiten, die elektrische Signale symbolisch — nicht analogisch — verarbeiten. Sie verarbeiten symbolische Geflechte, also Texte. Auf oberster Ebene dient eine Computeranlage dazu, Texte zu bauen, aufzubewahren und zu verarbeiten. So besteht beispielsweise die Datenbank einer Bank in einem Text, der alle Kunden, deren Konten und wiederum deren Bewegungen festhält. Wohlgemerkt setzt diese Definition unseren Textbegriff voraus, denn in den Computern geht es nicht um „Schriften”, sondern um unsere grundlegende allgemeine Textstruktur. Lassen wir uns nicht irritieren von der Tatsache, dass die Computer auch Sachen speichern und verarbeiten, die für uns Menschen keine Texte sind, wie etwa Musik, Bilder oder Videos. Für den Rechner sind das alles durch und durch Texte: Ohne die sogenannte Digitalisierung — sprich die textmäßige Darstellung untextmäßiger Inhalte — wäre dies alles computermäßig gar nicht zu behandeln.

Der Computer ist eine Text verarbeitende Maschine, das heißt ein elektronisches Gerät, dessen Aufgabe darin besteht, textgesteuert Texte umzuschreiben. Diese Definition ist keine Metapher, sondern sie ist wörtlich zu verstehen. Wir sagen, dass der Computer buchstäblich mit Text umgeht, und zwar unmittelbar mit Text und mit dem Text als solchem.

Wir sagen nicht etwa, der Computer verarbeite Informationen. Der Name Informatik hat sich eingebürgert, ist aber falsch und zeugt von Unverständnis dessen, was die Rechner eigentlich sind und tun. Es geht da nicht um Informationstechnologie, weder im Sinne einer Informationsverarbeitung — die Rechner werden gewiss zu Informationsverarbeitung eingesetzt, aber nicht nur dazu, sondern auch zu Bild- und Tonbearbeitung, Kommunikation, Simulation, Gerätesteuerung und zu unzähligen anderen Zwecken — noch in fundamentalem Sinne als elektronische Verarbeitung von bedeutungstragenden Signalen. Denn Information ist kein Stoff, sondern eine Interpretation. In etwas Information zu sehen, ist nicht nur eine Übung, die nur Menschen machen können, sondern auch eine Übung, die eine bestimmte Kulturprägung voraussetzt. Ein mittelalterlicher Bauer aus Mecklenburg-Vorpommern hätte gewiss keine „Informationen” sehen können.

Übrigens deutet auch auf mangelndes Verständnis hin, dass man neben der Analogelektronik von der Digitalelektronik spricht. Denn das Gegenteil des Analogen ist nicht das Numerische, sondern — allgemeiner — das Symbolische. Die elektronischen Signale werden entweder analogisch oder symbolisch verarbeitet, im ersten Falle werden sie als physikalische Signale eingesetzt, im zweiten wirken sie nicht als das, was sie physikalisch sind, sondern als das, was sie be‑deuten: eine symbolische Einheit. Man sollte von Analog- und Symbolelektronik reden. Die symbolische Verarbeitung der Signale durch elektronische Geräte stellt die Möglichkeit der technischen Verarbeitung der Texte dar und ist gleichzusetzen mit der Möglichkeit der Informatik. Für die Informatik selbst wäre auch angemessener der Name Symboltechnik, denn die elektronischen Geräte, um die es sich handelt, haben es nicht unmittelbar mit Informationen zu tun, sondern mit Symbolen.

Das Textorientierte Paradigma

Das Textorientierte Paradigma ist die Auffassung von Software, die sich ergibt, wenn man einsieht, dass der Quellcode Text ist. Den Schritt nach vorne tut man, wenn man den Quellcode nicht als Implementierung, sondern als Spezifikation ansieht. Bisher hat man die Programmiersprachen nur als Implementationssprachen gedacht. Die Listen werden in Lisp immer gleich implementiert, die Objekte werden in Smalltalk immer gleich implementiert. So hat man dann die Sprachen Lisp und Smalltalk immer nur unter dem Aspekt dieser Implementierung gesehen. Der textorientierte Ansatz definiert hingegen nicht irgendwelche neue Implementations-Struktur wie Funktion, Liste, Objekt, sondern eine neue Spezifikations-Struktur: den Text. Der Quellcode spezifiziert Symbole anhand anderer Symbole, und zwar in der Form eines Textes. Der Compiler ist in der Lage, den Quelltext in einen anderen Text — die ausführbare Binärdatei — zu übersetzen. Zum Beispiel könnte im Quelltext etwas wie „f : Funktion” stehen, die „f” als eine Funktion deklariert. Das ist aber für einen textorientierten Compiler kein Implementierungs-Hinweis, sondern ein rein lexikalischer: Hier führt man ein Symbol ein, mit dem Namen „f” und dem Typ „Funktion”, das wiederum der Name eines anderen Symbols ist. Wie der Compiler diese Funktion zu implementieren hat, ist der Definition von „Funktion” zu entnehmen. Aber diese Definition verfügt über den ganzen zu übersetzenden Quellcode als Text und kann ihn abfragen, um die Implementierung zu bestimmen, und so ergibt sie beispielsweise je nach dem eine in-line-Implementierung, oder eine mit Stapel- oder Register-Parametern, einen Bibliothek- oder Webdienst-Aufruf, oder gar die Aufforderung einer Benutzer-Eingabe. Die Textorientierung entsteht, wenn man den Blick an den Text richtet und erst einmal bei dem Text bleibt, ohne ihn sofort unbedingt auch zu interpretieren.

Das Textorientierte Paradigma der Softwareentwicklung ist nicht den anderen existierenden Paradigmen gleich zu setzen, weil es von grundlegender Natur ist. Die anderen Ansätze stellen Werkzeuge und begriffliche Rahmen für den Softwarebau zur Verfügung. Als Text lässt sich hingegen jede existierende Software auf natürlicher, unvoreingenommener Weise analysieren. So reduzieren die funktionalen Programmiersprachen Software auf Funktionen, Argumente, etc., und die Objektorientierung auf Objekte, Nachrichten, etc. Die Textorientierung reduziert Software auf Text. Das ist theoretisch besser. Erstens, weil hier alles auf einem einzigen Begriff basiert. Aber auch, weil mit der textuellen Analyse man der Software keine Fremdbegriffe aufzwingt, sondern nur das ausmacht, was schon immer da war, nämlich die logische Struktur in Erscheinung und Verhalten, im Quellcode und auch in Binärformat. Die anderen Paradigmen selbst lassen sich als Text interpretieren, anders herum nicht.

Spezifikation und Implementation

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 unterstützt. Aus den Wörtern eines Programms ergibt sich linear die Struktur der erstellten Software.

Man behandelt Programmiersprachen nicht allein als das, was sie sind, nämlich Ausdrucksmitteln, sondern immer auch zusammen mit einer jeweils speziellen „Laufzeitumgebung”. Man wirft in einen Topf Kodierung und Semantik, Implementation und Spezifikation.

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 einer geläufigen Sprachauffassung: im Irrtum zu glauben, dass ein sprachlicher Ausdruck identisch mit bedeuteten Sachen ist. Genauer besehen ist das nicht der Irrtum der Menschen im Allgemeinen, sondern der Irrtum allein der gegenwärtigen Theorie, denn man setzt dauernd in der Tat — siehe 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ängig 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 heutigen 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.

Hier wird der Quellcode nicht als Reihe von Befehlen, sondern als symbolisches Gebilde aufgefasst. Hier werden die Programmiersprachen nicht als Werkzeugkasten, sondern als begriffliche Systeme eingesetzt, mit denen man Beziehungsgeflechte ausdrücken kann. Erst der Text als Ganzes wird, endlich, in ausführbaren Code umgeschrieben. Damit wird die Trennung von Implementation und Spezifikation vollständig vollzogen.

Programmiersprache als Textinstrument

So wie ein Musikinstrument dazu da ist, Musik hervorzubringen, so dient auch eine Programmiersprache dazu, Texte herzustellen. Der Computer wird durch Text gesteuert. Mit Programmiersprachen lassen sich Texte bilden, warten und weiterentwickeln, die viel komplexer sind, als das, was der Mensch ohne Sprache — knotenweise — zustande bringen und kontrollieren könnte.

Doch das Feld der Programmiersprachen ist durch Gewohnheit und Fantasielosigkeit geprägt. Der zufällige erste Ansatz wird willenlos gefolgt. Die heutigen Programmiersprachen kommen aus dem eigenen Paradigma nicht heraus; sie begnügen sich damit, den eigenen theoretischen Ansatz zu verewigen. Man sollte diesen einfallslosen Weg verlassen und anfangen, mit der Sprache kreativ, spontan und ungezwungen umzugehen und sie den realen Problemen und deren Lösung näher zu bringen. Anstatt beispielsweise die Entwicklung von Benutzeroberflächen mit bloßer Objektorientierung zu begegnen, sollten wir etwa anfangen, Sprachen zu Beschreibung von Layout und Benutzerinteraktion zu erfinden. So könnte der Softwareentwickler seine Energie daran einsetzen, eine geeignete Benutzerschnittstelle konzeptuell zu erarbeiten, anstatt wie heute nötig, die meiste Zeit damit verbringen zu müssen, das Konzept in funktionierende Software zu übersetzen.

Die bestmögliche Entfaltung der Programmiersprachen wird man erreichen, indem man zwei Ansätze parallel aber unabhängig voneinander pflegt. Zum einen soll es praxisnahe Entwicklung geben, die sich der Realität möglichst gut anpasst und unbekümmert Neues ausprobiert. Da sind die Ingenieure und die Programmierhelden gefragt, kreativ zu sein und neue Wege zu eröffnen. Zum anderen soll eine gründliche wissenschaftliche Arbeit verrichtet werden, die darin besteht, die existierende Software zu untersuchen, darin Gemeinsamkeiten zu finden, Sprachkritik zu üben und zu neuen, besseren, einfacheren und mächtigeren Programmiersprachen zu kommen. Diese theoretische Arbeit wird darin bestehen, die Textstrukturen des realen erfolgreichen Einsatzes zu verfeinern und durch Versprachlichung für die Allgemeinheit zu erschließen.

Vorgänger

Die Textorientierung bringt in der Softwareentwicklung viele bereits existierenden sehr erfolgreichen Ansätze wie etwa die Makroausdrücke, die Umschreibung und die Präprozessoren zur Vollkommenheit. Diese werden jeweils nur in begrenzten Bereichen eingesetzt und zu einem bestimmten Zweck. Die Textorientierung ist hingegen ein einziges Prinzip, das überall eingesetzt werden kann. Der grundsätzliche Unterschied zwischen beiden ist, dass die Vorgänger allesamt den Text als bloße Zeichenkette betrachten, was die Einfachheit der Umsetzung aber auch deren Grenzen bestimmt, wohingegen in der Textorientierung der Text nicht als Darstellung, sondern als Inhalt, geparseten Text, begriffen wird. Die Idee der Textorientierung entsteht dann, wenn man zu der Einsicht kommt, dass die Potenz von Makroausdrücken, Umschreibungen und Präprozessoren sich daraus ergibt, dass der Programmierer nicht „die Sache” beschreibt, sondern deren Beschreibung baut. Man setzt einen Text bewusst als Vermittler ein, dieser Text wird dann automatisch verarbeitet und ergibt endlich das Programm. Die Textorientierung folgt diesem Weg zu Ende und, indem sie eine völlig allgemeine Textstruktur zur Verfügung stellt, auf die jedes Programm in jeder möglichen Programmiersprache zurückgeführt werden kann, bringt sie die Möglichkeit hervor, die vorherige Teilansätze zu einem allgemeinen Prinzip, ja zu einem neuen Paradigma der Software überhaupt, zu erheben.

Außerdem integriert die Textorientierung viele anderen Ansätze, die bisher völlig voneinander getrennt existiert haben und die man mit dem Text überhaupt nicht in Verbindung gebracht hat, wie die Dateisysteme oder — allgemeiner — die Namenssysteme und die abstrakten Datentypen.

Vergleichen wir nun einige Vorgänger im einzelnen mit unserer Textorientierung.

In der Gegenwart gibt es „Datenbanken”, die mit stark strukturierten Daten arbeiten, „Textverarbeitungsprogramme”, die mit unanalysierten Zeichenketten, und „Kalkulationstabellen”, die mit zweidimensionalen Listen arbeiten. Dies alles lässt sich mit unserem Textbegriff als einen Text abbilden. Eine Software, die unseren Text unterstützen würde, würde nicht nur mit all diesen Strukturen umgehen können, sondern auch mit allen ihren Kombinationen, mit Texten, die teilweise sehr stark und teilweise gar nicht strukturiert sind.

Die aktuellen Dateisysteme bestehen aus einer Baumstruktur von Namen und ordnen jedem Eintrag einen Speicherraum zu. Die Grenze der Datei ist die Grenze des Betriebssystems; von dem, was in der Datei steht, weiß das Betriebssystem nichts, es ist Sache der einzelnen Programme. Der textorientierte Ansatz macht das Betriebssystem für den Text verantwortlich. Für den ganzen Text. Der Text fängt mit der bloßen Namensgebung an. Doch die Namen beschränken sich nicht auf eine Hierarchie Ordner- / Dateiname, sondern der Namensraum ist selbst ein Text und hat alle Möglichkeiten des völlig ausgebauten Textes.

Die herkömmlichen Makros (Zeichenketten, die vor der Kompilierung in andere Zeichenketten umgeschrieben werden), Sprach-Präprozessoren (wie PHP, um HTML-Seiten dynamisch zu erstellen), die eingeschobenen Programmiersprachen (wie z. B. in C++ eingebettete SQL-Anweisungen), und die sprachliche Umschreibung (etwa algebraische Umformungen) werden direkt von unserem Textbegriff unterstützt, ohne eine besondere Syntax oder einen Übersetzer zu benötigen. Verschiedene Sprachen können im Text zusammenleben, wenn man den Text in einer allen formalen Sprachen unterliegenden symbolischen Form repräsentiert.

Die herkömmlichen abstrakten Datentypen folgen dem Schema =a { =b :tb }. Ein Datentyp besteht aus Gliedern, die wiederum jeweils von einem Datentyp sind. Unser Text fügt da durch die Rollen einen Freiheitsgrad hinzu: =a { ~r =b :tb }. Dies ist keine Kleinigkeit, sondern damit eröffnet sich eine neue Dimension. Während die bisherige Software den Typ und dessen Instanz grundsätzlich unterschieden hat, gibt es bei uns keine zwei Grundarten Typ und Instanz, sondern nur eine Grundart, die Texteinheit. Typ und Instanz sind nichts Wesentliches, sondern sie kommen den Einheiten als Knoten eines Textes zu. Eine Einheit kann in ein und demselben Text mal als Instanz, mal als Typ vorkommen.

Aber diese neue Dimension eröffnet sich nicht nur für die reinen Datenstrukturen, sondern auch in der Algorithmik. Heute kann man mit einer Programmiersprache beispielsweise Funktionen definieren, und mit einer anderen vielleicht auch Prozeduren, oder Modulen, Klassen, etc. Aber die Semantik der Programmiersprache lässt sich über diese vordefinierten Typen „Funktion”, „Modul”, „Klasse” hinaus nicht erweitern. Ein Compiler implementiert sie in einem geschlossenen System. Eine ganz andere Bewandtnis hat es mit unserem Textbegriff. Mit ihm lässt sich beispielsweise definieren: eine „Funktion” ist dieses und jenes; und ich definiere diese und jene Funktionen. Mit Programmiersprachen, die auf diesen neuen Textbegriff basieren, wird man ganz neuartige Software schreiben können.

Vorbild Unix

Der Weg der Textorientierung wurde seit den siebzigern Jahren von Unix vorbereitet. Unix zeichnet sich unter allen Betriebssystemen durch markantes Textbewusstsein aus. Gerade das hat zur Folge, dass es das beliebteste Betriebssystem unter Programmierern ist. Denn Software ist Text, Textorientierung ist daher in der Softwareentwicklung sachgemäß. Das weiß man heute noch nicht, der Unix-Fachmann spürt aber, dass dies der richtige Weg ist.

Was ich unter Text verstehe, kommt in Unix in verschiedenen Gestalten vor. Manchmal unter dem Namen Text, etwa wenn man jedes Programm als Filter auffasst, der einen eingegebenen Text verarbeitet und wieder ausgibt. Manchmal ohne diesen Namen, so bleibt man etwa beim Schlachtruf „KISS! Keep It Simple, Stupid!” stehen, ohne das schleierhafte „it” als einen Text zu enthüllen. Ferner ragt die Unix-Gemeinde traditionell durch den Umgang mit dem nicht ausführbaren Softwaretext heraus: zum einen wird der Quellcode verteilt — womit die installierte Software keine Blackbox ist —, zum anderen ist jedes Programm mit den sogenannten man-Seiten gut dokumentiert.

Rund um das Betriebssystem Unix ist eine Auffassung der Softwareentwicklung entstanden, die viel mehr ist, als nur eine Eigenart oder eine Art unter anderen möglichen. Seine Textbasiertheit ist kein Gag. Da berührt Unix als einsame Spitze den Nerv der Software überhaupt.

Das Relationale Datenbankmodell

Das Relationale Datenbankmodell ist eine der größten Errungenschaften der Informatik überhaupt. Es ist eindrucksvoll, wie ausdrucksstark eine Abfragesprache wie SQL ist. Diese Sprache verrichtet in der Gegenwart täglich die Arbeit, die sonst unzählige Programmierer einer herkömmlichen Programmiersprache leisten sollten — was ja im Endeffekt bedeutet, dass sie viele sonst undenkbaren Aufgaben ermöglicht. Das Relationale Modell ist — möchte man fast sagen — perfekt: Die Datenstruktur und die Sprache sind einfach und klar, mit wenigen Mitteln, die sehr allgemein gehalten und ohne Ausnahmen sind. Alles basiert auf ein simples mathematisches Modell, das dem Ganzen eine solide Struktur verleiht.

Der durchschlagende praktische Erfolg des Relationalen Modells veranlasst einige Überlegungen. Hier stehen wir nicht vor irgend einer Erfindung, die man mehr oder minder erfolgreich einsetzen kann. Hier stehen wir vor einer grundlegenden Einsicht in den Kern der Informationsstruktur. Wenn sich beliebige Daten mit diesen wenigen Mitteln repräsentieren, verwalten und abrufen lassen, dann beschreibt dieses Modell die Daten als solche und trifft sein Wesen. Das Relationale Modell ist keine „Anwendung”, sondern es ist eine Theorie, die — so wie die Newtonschen Gesetzen — die Regelmäßigkeiten in der Wirklichkeit erfasst.

Das Relationale Modell nehmen wir zum Vorbild in unserer Suche nach einer allgemeinen Textstruktur. Wir wollen den Kern des Textes treffen, genauso wie unser Vorbild den Kern der Daten trifft. Wir wollen ein schlichtes mathematisches Modell finden, das den Text und dessen Umformungen beschreibt. Denn die Daten sind zwar ein wichtiger Teil der Software, aber lange nicht alles. Der Text hingegen ist ein allgemeineres Gebilde, das nicht nur Datenstrukturen, sondern auch allerlei Algorithmen miteinbezieht, und beides integriert.

Vielversprechende XML

Eine andere Entwicklung, die zum Teil positiv ist, spielt sich im Umfeld des Internets. Es geht um die XML. Das, was sich selbst zunächst bescheiden für ein bloßes Dateiformat ausgibt, stellt vielmehr einen großen Schritt in der richtigen Richtung in der Informatik überhaupt dar. Ganz abgesehen vom Format selbst, das schwere Mängel die Lesbarkeit und Benutzerfreundlichkeit betreffend aufweist, hat die XML sehr viele gute Eigenschaften. Sie ist zum einen textbasiert. Der Text bildet eine eigene Schicht zwischen dem Informations-Produzenten und dem -Konsumenten. Sie ist zum anderen universell. Allerlei Informationen lassen sich mit ihr abbilden.

Aber ganz wichtig für die XML ist, dass sie über eine Abfragesprache verfügt. Das ist das Kernstück, das die XML zu etwas Neuartigem, auch verglichen mit ihrer Vorgänger SGML, macht. Erst die Abfragemöglichkeiten machen das Relationale Datenbankmodell zu etwas Besonderem. Genauso bringt XQuery der XML zu ganz neuen Ufern. Zu den Abfragemöglichkeiten zählen auch die zur Verfügung stehenden Bibliotheken, die den Umgang mit XML-Dateien erleichtern.

Nicht zuletzt ist die XML allein deshalb großartig, weil sie ein weltweit einheitliches Standard ist. Überhaupt ist das World Wide Web in der Weltgeschichte ein sonderbares Phänomen, das als Standard geboren und sofort weltweit akzeptiert und unverändert angewendet wird, anstatt — wie sonst üblich — sich die Standardisierung mühevoll Jahrzehnte oder Jahrhunderte lang erkämpfen zu müssen.

Die XML ist nicht als Datenaustauschformat, sondern als Informationsstruktur wichtig und neuartig. Sie ist aber kein bloßer Datentyp neben den anderen Datentypen. Mit der XML rückt die Informatik der Anwendung des wohlverstandenen Textes ein Bisschen näher.

Andererseits jedoch wirkt sich die XML verheerend auf die Softwarelandschaft aus. Denn es ist zwar gut, eine gemeinsame Sprache zu haben, es ist aber katastrophal, mit einer einzigen Sprache zu enden. Der heutige Einsatz der XML besteht darin, alles nur in diesem Format darzustellen. Das ist nicht nur verarmend, wie es jede Monokultur ist, sondern besonders schlimm, weil das XML-Format sperrig und unlesbar ist.