Heilig halte Hypostasen!

 

 

 

 

 

 

 

Ceci n'est pas une pipe!

Wider den objektorientierten Hypostasierungswahn

 

10. Mai 1998

Hartwig Thomas



Ceci n'est pas une pipe!

Wider den objektorientierten Hypostasierungswahn

Inhalt

 

Inhalt...................................................................................................................................................................................... 2

Objekt-orientiert ist heute PC............................................................................................................................... 3

CORBA und JAVA................................................................................................................................................................. 4

Instant CORBA................................................................................................................................................................... 5

Vom Nutzen schlechter Bücher............................................................................................................................ 7

Die Vision des ultimaten Objekts......................................................................................................................... 8

Hypostasierung bedeutet unzulässige Verdinglichung.................................................................... 11

Die Sehnsucht nach dem verlorenen analogen Paradies................................................................. 12

Ein noch nicht ganz vergessenes Schulbeispiel der Hypostasenbildung............................ 13

Relationale Datenbanken...................................................................................................................................... 15

Hypostasierung und relationaler Design.................................................................................................. 17

Objekte und Datensätze........................................................................................................................................... 18

Traum vom programmiererlosen Unternehmen..................................................................................... 19

Vom Nutzen und Nachteil des objekt-orientierten Designs für das Leben.......................... 21

Analoge Imitation und Digitale Abstraktion im Object-Web........................................................ 23

 


Objekt-orientiert ist heute PC

Im Folgenden geht es zwar um Computer, PC steht hier aber für “Politically Correct”. Tatsächlich hat sich die objekt-orientierte Programmierung, der objekt-orientierte Design, die objekt-orientierte Datenbank, die objekt-orientierte Middleware vom sektiererischen Kult zur staatlich sanktionierten Landeskirche gewandelt. Ihre ferventen Verfechter werden nicht mehr freundlich belächelt, sondern haben inzwischen in allen Chefetagen Gehör gefunden und unter Managern viele neue Proselyten gewonnen.

Wenn die Begeisterung überschäumt, die Augen zu glänzen beginnen und die Rhetorik einen gewissen missionarischen Charakter annimmt, kann man dies bei einer marginalen Sekte verstehen und verzeihen. Wenn sich die Vertreter einer dominierenden Lehrmeinung immer noch so verhalten, dann droht den abweichenden Ketzern plötzlich das Autodafé.

Die führenden Kräfte in Universitäten und Grossfirmen im Informatikbereich haben im letzten Jahrzehnt die Kritik an objekt-orientierten Methoden für nicht mehr “politically correct” erklärt. Wer auch nur einen Pieps gegen CORBA, DCOM, JAVA, Smalltalk oder C++ äussert, wird niedergewalzt, bevor er auch nur Atem geholt hat, um seine Argumente vorzulegen.

Weil damit ein sehr teurer und langfristiger Irrweg auf dem Gebiet der weltweiten Netzwerk-Kommunikation eingeschlagen wird, liegt mir daran, diesen Argumenten hier trotzdem noch einmal Raum zu geben. Es geht mir hier als Vertreter der ketzerischen Minderheit in erster Linie darum, Gehör zu finden. Ich habe nicht genügend abgeklärte Distanz zum Thema, um den Inquisitoren ausgewogene Gerechtigkeit widerfahren zu lassen.


CORBA und JAVA

Das objekt-orientierte Modell wird von allen Autoren als ein Sammelsurium von Eigenschaften definiert (Klassenabstraktion, Kapselung, Modularität, Vererbung, abstrakte Datentypen, Multitasking, Persistenz), und nicht als selbständiges, einigermassen geschlossenes, Paradigma, wie etwa seinerzeit das “strukturierte (prozedurale) Programmieren” von E. W. Dijkstra.

Programmobjekte sind in diesem Modell gegen aussen gut abgekapselte, aus Code und Daten bestehende, Programmkomponenten. Über in einem vertragsähnlichen Schnittstellenbeschrieb bekanntgegebene Prozeduren, welche in diesem Zusammenhang die Methoden des Objekts genannt werden, kann man auf die in ihnen aufbewahrten, nicht direkt inspizierbaren Daten zugreifen und diese verändern. In der heutigen vernetzten Welt, liegt es nahe, statt dem lokalen Prozeduraufruf, den über das Netz vermittelten Distanzprozeduraufruf (RPC = Remote Procedure Call) zu verwenden. Wenn die Methoden eines Objekts auf diese Art netzwerkfähig gemacht werden, spricht man von “verteilten Objekten”, da sich sowohl ihr Dateninhalt als auch ihr Code nicht mehr notwendigerweise auf einer einzelnen Maschine befindet. Wenn nun ein Programm ein solches verteiltes Objekt herstellen oder finden oder eine seiner Methoden aufrufen will, muss eine systemweite Buchhaltung der Lokalisierung aller Objektbestandteile mithelfen, eine solche Objektanforderung (object request) an den richtigen Adressaten zu lenken. Die Systemkomponente, welche Objektanforderungen vermittelt, heisst ORB (Object Request Broker) in der Terminologie einer der grossen Netzobjektkirchen. Die gesamte Architekur der verteilten Objekte und wie man diese mit Hilfe eines ORB anwendet nennt sich daher CORBA (Common Object Request Broker Architecture).

Es ist zweckmässig, auf solche verteilten Objekte mit Hilfe einer “objekt-orientierten” Programmiersprache zuzugreifen, welche diese Kombination von gekapselten Code und Datenkomponenten als spracheigene abstrakte Datentypen gut unterstützt. Neben traditionellen objekt-orientierten Programmiersprachen wie Smalltalk und C++ ist hier in neuerer Zeit vor allem JAVA zum grossen Hoffnungsträger geworden. JAVA wurde von vornherein als objekt-orientierte Sprache für Netzwerkanwendungen entwickelt. Wie andere “portable” Programmiersprachen wird JAVA mit dem Versprechen vermarktet, dass es plattformunabhängige, für den Benutzer sichere Programmierung ermögliche. Bei einer auf mehrere Maschinen mit eventuell verschiedenen Betriebssystemen verteilten Anwendung ist die Portabilität natürlich eine wichtige Anforderung. Die Voraussetzung dafür ist natürlich einerseits, dass ein fehlerfreier JAVA-Interpreter (eine JAVA-Engine) auf jeder Plattform zur Verfügung steht, und andererseits, dass man sich einschränkt in der Benutzung von Spezialhardware und Betriebssystemeigenschaften, welche nicht plattformübergreifend zur Verfügung stehen.


Instant CORBA

Ich lese viele Informatikbücher, kenne wenige, die etwas taugen, habe aber selten etwas dermassen abgründig Debiles gelesen, wie “Instant CORBA” von Robert Orfali, Dan Harkey und Jeri Edwards (John Wiley & Sons, Inc., 1997, ISBN 0-471-18333-4).

Schon die Typographie appelliert an Analphabeten, weil sie offensichtlich nicht gelesen werden will. Das Vorwort stammt verspielterweise von Zog, dem Marsianer, dessen Konterfei auch gleich mit abgebildet ist. Diese Zeichnung ist im Stil von Sesame Street gehalten. Trotzdem stipulieren die Autoren, die immerhin Professoren an irgendwelchen nordamerikanischen Universitäten sind, dass ihr Text sich an Erwachsene richtet.

Die Autoren haben sich offensichtlich zum Ziel gesetzt, eine dreihundertseitige Lobhudelei über CORBA und JAVA (deshalb “Instant” mit Hilfe des Tertium Comparationis “Kaffee”) zu publizieren, die möglichst viele, noch beeindruckbare Studenten davon überzeugen soll, dass es sich nicht mehr lohnt, seriös programmieren zu lernen, und möglichst viele unbedarfte Manager zu überreden versucht, die Produkte des angepriesenen CORBA-Konsortiums (Sun, IBM, Netscape, Apple, Oracle, HP u.a.) zu kaufen, und die objekt-orientierten Studenten nach ihrem Abschluss trotz fehlenden Programmierkenntnissen anzustellen. Nebenbei mögen sie die Firma Microsoft nicht.

Für die noch beeindruckbaren Studenten sind offensichtlich die bemüht witzigen Anspielungen an beliebte Science Fiction Fernsehserien berechnet, wie auch das Ersetzen jeglicher formaler Definitionen durch graphische Andeutungen von zusammensetzbaren Lego-Objekten mit Nippeln und Löchern. Für die ohnehin schon von Unsicherheit beherrschten unbedarften Manager wird alle paar Seiten eine neue, meist dreibuchstabige Abkürzung (ORB, POS, MOM, SFA, BOF ...) eingeführt. Auf den hinteren Seiten, kommen dann kaum mehr Sätze vor, die nicht eines oder mehrere dieser Akronyme enthalten.

Beiden Lesergruppen wird eingehämmert, dass es sich bei CORBA, JAVA und dem daraus kombinierten Object-Web um die “ultimate”, also endgültige, abschliessende, Informatikentwicklung handelt. Das Buch wimmelt von dröhnende Wort- und Satzhülsen mit diesem Verräterwörtchen: “Dieser Ansatz ist die ultimate Form von massgeschneiderter Middleware.” [This approach is the ultimate form of made-to-order middleware. p. 19] “Durch Kombination von Metaklassentechnologie mit CORBA Services kann man in letzter Minute angepasste Middlewareumgebungen erzeugen um spezifische Komponenten auszuführen. Dies demonstriert die ultimate Flexibilität von Objekten.” [By combining metaclass technology with CORBA services you will be able to create last-minute, customized middleware environments for running particular components. It demonstrates the ultimate flexibility of objects. p. 20] “Das ultimate Nirwana im Client/Server-Komponentengeschäft sind also superkluge Geschäftsobjektkomponenten, die mehr als nur interoperieren — sie arbeiten auf der semantischen Ebene zusammen, um ihren Auftrag zu erledigen.” [So the ultimate Nirvana in the client/server components business are supersmart business object components, that do more than just interoperate - they collaborate at the semantic level, to get the job done. p.26]

In der Mitte des Buchs preisen die Autoren die Fähigkeiten ihrer Studenten an, die in der neuen objekt-orientierten Welt ja nicht mehr zu programmieren brauchen, sondern nur noch auf semantischer Ebene kooperierende Objekte zusammenstecken. Sie wundern sich darüber, warum in ihren Semesterübungen jeder Student einen funktionierenden ORB (Object Request Broker) gebaut hat, während die kommerziell erhältlichen Produkte alle ziemlich viele Fehler enthalten und nur langsam auf den Markt kommen. “Die Millionen-Preisfrage ist also: Warum produzieren ORB-Verkäufer kommerzielle Produkte nicht in Studentengeschwindigkeit? Wir werden die Frage vielleicht später in einer Seifenkiste beantworten.” [So the million dollar question is: Why aren’t the ORB vendors delivering commercial implementations at student speeds? We may later answer this question in a Soapbox. p.104] Unter “Seifenkisten” verstehen sie ein lustig illustriertes Textkästchen voll von kontroversen Meinungshäppchen, die wie am Hyde-Park-Corner von Rednern auf Seifenkisten herab unter das zuhörende Volk gestreut werden. Leider findet sich die angekündigte Seifenkiste nirgends im Buch. (Offensichtlich wusste der Schreiber dieses Satzes noch nicht, wie das Buch dann ausgehen würde.) Die offensichtliche Antwort, dass die ORB-Produzenten als Mitarbeiter nur noch objekt-orientierte Studenten ohne Programmierkenntnisse zu Verfügung haben, würde den Rahmen des Buchs offensichtlich sprengen, das sich sklavisch bemüht, jeden sozial relevanten Aspekt zu vermeiden.

Im Abschnitt über Sicherheit schimmern dann aber ein paar grundsätzliche Bruchstellen dieser schönen neuen Object-Web-Welt durch: “Typischerweise kann man Servern trauen, nicht aber Clients.” [Typically you can trust servers but not clients. p. 152] Transponiert in unsere reale Welt würde ja kaum jemand einen so blödsinnigen Satz unterschreiben wie “Typischerweise kann man Banken trauen, Bankkunden hingegen nicht.”. Mehrfach wird wiederholt, dass die Sicherheit ja durch den ORB (und dessen Lieferanten Sun, IBM, ...) garantiert sei, dem man eben blind vertrauen müsse. Dieser authentisiert sich natürlich nicht gegenüber dem Benutzer, während der Benutzer genauestens geröntgt wird. Immerhin wird zugestanden, dass CORBA eine Traumumgebung für trojanische Pferde darstellt.


Vom Nutzen schlechter Bücher

Der Vorteil schlechter Bücher besteht darin, dass sie Fehlkonzepte dermassen übertrieben präsentieren, dass man den zugrundeliegenden Grundirrtum klarer zu Gesicht bekommt. Im Folgenden geht es nun nicht darum, die Problematik der asymmetrischen Client/Server-Kom­mu­ni­ka­tions­infra­struk­tur der CORBA-Middleware weiterzuverfolgen, und sie etwa einem symmetrischen Peer-to-Peer-Modell gegenüberzustellen, sondern der Rest dieses Pasquills konzentriert sich darauf, die extreme und damit entlarvende Sicht des objekt-orientierten Paradigmas zu sezieren, die im zitierten Buch ihren Ausdruck findet.

Obwohl der Anstoss zu dieser Kritik an allem Objekt-orientierten einem extrem schlechten Buch entstammt, bezieht sie sich auf die ideellen Wurzeln dieses Konzepts. Im schlechten Buch verbreitet die Fäulnis um diese Wurzeln einen eindeutigeren Geruch als bei moderateren Darstellungen. Der Wurm steckt aber im Konzept selber und ist nicht nur ein Produkt der Beschränktheit des zitierten Buchs.

Das objekt-orientierte Modell hat für Programmierer in Einzelheiten viele Verbesserungen gebracht. Das Konzept der abstrakten Datentypen wird heute mit Erfolg weltweit eingesetzt. Das Abschirmen der Daten eines Objekts gegen Zugriffe der Aussenwelt hat zur Folge, dass diese nur über die Methoden eines Objekts benutzt werden können. Höchstens während eine solche objekt-eigene Methode ausgeführt wird, befindet sich das Objekt temporär in einem inkonsistenten Zustand. Dem Benutzer der Programmkomponente, dem nur die Methoden des Objekts zur Verfügung stehen, ist die Möglichkeit genommen, die konzeptionelle Integrität der Daten des Objekts zu zerstören. Gegen die Anwendung von Programmobjekten ist also nicht das Geringste einzuwenden. Auch ich werde also auch weiterhin einen Teil meiner Programme gerne in C++ entwickeln.

Die Kritik fasst erst richtig Fuss, wenn man sie auf die teleologische Vision zielt, welche den Treibstoff für die objekt-orientierten Proselytenmacher hergibt.


Die Vision des ultimaten Objekts

Im Buch, dem der vostehende Verriss gewidmet ist, wird die Vision des “ultimaten” Objekts vorgestellt. Die Autoren nennen es “(CORBA) Geschäftsobjekt” [CORBA business object]. Wie man am weiteren Text ablesen kann, steht hier “business” stellvertretend für “real-life”. Vermutlich soll die Seriosität und der kommerzielle Nutzen durch diese Qualifizierung betont werden. Auf der beigefügten Illustration [S. 21] ist dann das Geschäftsobjekt verspielt als Humpty-Dumpty abgebildet, der auf der monolithischen Wand aus CORBA-Middleware sitzt. Offensichtlich ist den Autoren selber mulmig bei der Frage, wer diese Objekte wieder zusammensetzen soll, wenn sie mal von diesem Turm herunterfallen.

“Geschäftsobjekte ermöglichen, auf natürliche Art und Weise anwendungsunabhängige Konzepte zu beschreiben wie etwa Kundenauftrag, Konkurrent, Geld, Zahlung, Auto und Patient. Sie fördern eine Ansicht von Software, die den Charakter von Werkzeugen, Anwendungen, Datenbanken und anderen Systemkonzepten transzendiert. Das ultimate Versprechen von Objekttechnologie und -komponenten besteht darin, dass diese mittelkörnigen Komponenten zur Verfügung gestellt werden, die sich mehr wie die wirkliche Welt verhalten.” [Business objects provide a natural way for describing application-independent concepts such as customer, order, competitor, money, payment, car and patient. They encourage a view of software that transcends tools, applications, databases, and other system concepts. The ultimate promise of object technology and components is to provide these medium-grained components that behave more like the real world does. p. 20/21]

“Ein Geschäftsobjekt ist eine Komponente auf Anwendungsebene, die man in nicht vorhersagbaren Kombinationen einsetzen kann. Ein Geschäftsobjekt ist definitionsgemäss unabhängig von jeder spezifischen Anwendung. Post-monolithische Anwendungen werden aus Suiten von Geschäftsobjekten bestehen — die Anwendungen stellen nur die Umgebung zur Verfügung, wo diese Geschäftsobjekte ausgeführt werden. Mit anderen Worten, ein Geschäftsobjekt ist eine Komponente, die eine ‚erkennbare‘ Entität des Alltagslebens darstellt. Im Gegensatz dazu stellen Objekte auf dem Systemniveau Entitäten dar, die nur für Computersysteme und Programmierer verständlich sind — Endbenutzer können mit ihnen nichts anfangen.” [... a business object is an application-level component you can use in unpredictable combinations. A business object is, by definition, independent of any single application. Post-monolithic applications will consist of suites of business objects — the application simply provides the environment to execute these business objects. In other words, a business object is a component that represents a “recognizable” everyday life entitiy. In contrast, system-level objects represent entities that make sense only to information systems and programmers — they’re not something an end user recognizes. p.21/22]

“Geschäftsobjekte werden eingesetzt werden, um Systeme zu entwickeln, welche die Geschäftsabläufe imitieren, welche sie unterstützen. In der wirklichen Welt sind Geschäftsereignisse selten auf ein einzelnes Geschäftsobjekt beschränkt. Statt dessen betreffen sie typischerweise Ansammlungen von Objekten. Damit Geschäftsobjekte ihre Gegenstücke in der wirklichen Welt imitieren können, müssen sie fähig sein, miteinander auf einer semantischen Ebene zu kommunizieren.” [Business objects will be used to design systems that mimic the business processes they support. In the real world business events are seldom isolated to a single business object. Instead they typically involve clusters of objects. To mimic their real-world counterparts, business objects must be able to communicate with each other at a semantic level. p. 22]


Hypostasierung bedeutet unzulässige Verdinglichung

Die Zitate stellen ein fortgeschrittenes Stadium der Hypostasierung von Programmbestandteilen dar. Unter Hypostasierung versteht man — vor allem unzulässige — Verdinglichung. Es ist verführerisch, nur weil die Sprache für irgendeine Gegebenheit ein Substantiv bereithält, daraus abzuleiten, es müsse auch ein Ding geben, das mit diesem Wort gemeint ist. Die objekt-orientierte Vision lädt dazu ein, die beschreibenden Programm-“Objekte” mit den beschriebenen Dingen der wirklichen Welt zu verwechseln. Die berühmte Pfeife in Magrittes Bild ist aber nicht aus Holz sondern aus Ölfarbe.

Wer auch nur zwei Sekunden darüber nachdenkt, wie unsinnig es ist, etwa das “Objekt” Patient zu imitieren, um zum Beispiel eine Diagnose zu stellen, wundert sich darüber, wie man auf die wahnwitzige Idee verfallen kann, die Abbildung der wirklichen Welt diene der Lösung der Probleme, denen wir in dieser wirklichen Welt begegnen. Das Ganze erinnert etwa an animistische Magiepraktiken oder an Homöopathie, wo das Heilmittel die Krankheit imitieren muss. (Darum sind alle Abführmittel braun, ob in Tablettenform, als Pulver, als Tee oder als Säftchen.)

Die Sehnsucht nach der Imitation der Welt durch die sprachliche oder neuerlich auch programmiersprachliche Beschreibung scheint allerdings sehr tief zu stecken. Ein sehr kurzer Weg führt von Wittgensteins “Die Welt ist alles was der Fall ist.” am Anfang unseres Jahrhunderts zur Hypostasierung der Entitäten in den Entity-Relationship-Diagrammen der Datenbank-Gurus am Ende desselben. In beiden Fällen wird angenommen, jedes Substantiv (jedes Programm-Objekt) habe als Gegenstück einen Gegenstand (ein Objekt) in der wirklichen Welt und jeder Sachverhalt (Beziehung oder Relation zwischen Gegenständen) entspreche einem Satz, einer “Kommunikation auf semantischer Ebene” zwischen Programm-Objekten.


Die Sehnsucht nach dem verlorenen analogen Paradies

Diese Idee der Ähnlichkeit ist eine zutiefst analoge Idee (s. “Digitales Zeitalter” http://www.enterag.ch/people/hartwig). Sie basiert auf der Verkennung der Tatsache, dass Sprachen und Programmiersprachen in ihrem eigentlichen Wesen digital sind und somit keinerlei Ähnlichkeit zwischen Beschreibendem und Beschriebenen stattzuhaben braucht. Gerade die Vielgestaltigkeit und Unähnlichkeit des sprachlichen Ausdrucks und der wirklichen Welt scheinen es zu ermöglichen, mit seiner Hilfe nützliche Lösungen für die in dieser Welt bestehenden Fragen und Probleme zu erarbeiten. Diejenigen Programme und Informatikkonzepte, wie etwa Relationale Datenbanken, Computergestützte Graphik, digitale Regeltechnik, etc, die in den letzten fünfzig Jahren am meisten ökonomischen Nutzen gebracht haben, zeichnen sich dadurch aus, dass sie nur von Computersystemen und Programmierern verstanden werden. Wenn sie Endbenutzern einfach verständliche Abbilder von Objekten der realen Welt wären, brächten sie für diese keinen Mehrwert.

Das Aufspüren abstrakter, einfacher Grundlagen von komplexen Vorgängen in der wirklichen Welt, hiess früher Analyse. Heute wird den Informatikern schon in der Universität eingeredet, diese habe sich überlebt und werde nicht mehr benötigt. Ziel der Programmierung sei vielmehr die Imitation der realen Welt. Aufgrund dieser Objektmanie fallen denn auch alle mir bekannten grösseren CORBA-Projekte spätestens bei der Inbetriebnahme der Komplexitätsexplosion zum Opfer.

Die Hauptbeschäftigung eines guten Programmierers müsste nun eben darin bestehen, seine Programme so digital, polymorph, abstrakt zu gestalten, wie sprachliche oder monetäre Systeme. (Geld hat hochgradig digitalen Charakter und ähnelt auch den Objekten in keiner Weise, die es vertritt.) Niemand zweifelt heute mehr daran, dass man mit Programmen im Prinzip “alles” machen kann. Bei “fast allem” stellt sich aber heraus, dass seine Beschreibung im Programm komplexer ist als die beschriebene Realität selber. (s.a. das sensationelle, wenn auch ziemlich theorielastige Buch: “An Introduction to Kolmogoroff Complexity and its Applications” von M. Li und P.M.B. Vitányi, New York, Springer Verlag, 1997). Diese Komplexitätsexplosion wird wohl in Form der Kostenexplosion das CORBA-JAVA-Object-Web in kurzer Zeit zum Stillstand bringen.

Das tägliche Brot des Programmierens besteht nun darin, mit List und wenig Programmieraufwand viel konkreten Nutzen zu schaffen. Das ist das Ziel der Analyse. Die Fussangel eines jeden Programmprojekts besteht in der Verführung, mit viel Programmieraufwand wenig Nutzen zu schaffen. Dies ist die unweigerliche Folge der objekt-orientierten Realitätsimitation, denn die zu imitierende Wirklichkeit hat einen sehr hohen Komplexitätsgrad und trägt fast nie freiwillig zur Lösung der Probleme bei, da sie ja selber das Fundament der Probleme ist.


Ein noch nicht ganz vergessenes Schulbeispiel der Hypostasenbildung

Die heute allgegenwärtige Verabsolutierung von “Objekten” im Informatikbereich erinnert an einen harmlosen Vorläufer in den Achtzigerjahren. Plötzlich war es nicht mehr PC (diesmal wieder “politically correct”), eine Textverarbeitung auf den Markt zu bringen, die nicht der Norm WYSIWYG (What You See Is What You Get) entsprach. Ein Teil dieser Modewelle war von der Marketingabteilung der Firma Apple ausgelöst worden, die den damals beliebten Beelzebub vom Dienst, IBM, damit austreiben wollte. Tatsächlich hatten die Mainframe-Textverarbeitungen dieser Firma den grossen Nachteil, dass man ihre Steuerzeichen “kompilieren” und “debuggen” musste und häufig nicht bekam, was man wollte. Die Reduktion der typographischen Abstraktion mit Hilfe einer modernen graphischen Oberfläche, wo man nicht irgendwelchen Steuerzeichensalat auf einem Textbildschirm mit 25 mal 80 gleich breiten Zeichen sah, war zweifelsohne ein grosser Fortschritt, auf den die Pioniere bei Xerox, an der ETH Zürich und bei Apple stolz sein dürfen.

Dass der Slogan WYSIWYG dann aber mit religiösem Eifer von der Benutzer- und Managergemeinde dermassen verabsolutiert wurde, dass ganze Betriebssystemgenerationen nur noch nach diesem Kriterium beurteilt wurden, lässt sich nicht nur aus der Marketingstrategie von Apple und aus der sympathischen David-gegen-Goliath-Situation alleine erklären. Eine nicht unbeträchtliche Rolle dürfte der “Imitationszwang des neuen Mediums” gespielt haben. Wie Gutenbergs mobile Lettern zuerst die handschriftliche Unregelmässigkeit von Manuskripten imitieren mussten, wie die Fotographie zuerst beweisen musste, dass sie wie die Malerei sein kann, wie das Kino zuerst das Theater imitierte, bevor es beim Publikum Akzeptanz fand und sich selber sein durfte, so musste der Computer zuerst beweisen, dass er den Buchdruck imitieren kann, dass er so gut ist, wie eine Diashow und heute versuchen alle verzweifelt zu beweisen, dass man auch das Fernsehen damit imitieren kann. Alle diese Imitationen dienen anscheinend der gesellschaftlichen Verdauung und der Vereinnahmung des neuen Mediums.

Bei diesen Imitationen erscheint ein neues Medium natürlich zwangsläufig immer eher schlechter als das Original. Wenn WYSIWYG wirklich der Massstab für die Güte eines Computers war, musste die Kugelkopfschreibmaschine (von IBM!) der “ultimate” Computer sein. (Jetzt fange ich auch schon damit an. Dieses Wort ist ansteckend!) Dort jedenfalls erhielt jedermann immer, was man sah. Die Fixierung auf die Hypostasierung der äusseren Erscheinung hat jedenfalls die Bedeutung der digitalen Texte für das Geistesleben der Menschheit um mehrere Jahrzehnte zurückgeworfen. Es ging vergessen, dass der Wert eines Textes nicht in seiner Typographie, sondern in seiner Textlogik steckt, dass es derselbe Text bleibt, auch wenn er in einem Büchlein mit einem anderen Format gedruckt wird. Der Mehrwert, den die Computertechnik gerade auf dem Gebiet Texte gegenüber der Schreibmaschine und dem Offsetdruck hätte einbringen können, wären Retrieval, Austauschbarkeit, Archivierung in standardisierten Formaten etc. gewesen. Auf diesen Gebieten stehen wir heute dank der WYSIWYG-Manie auf dem Stand von 1983. Ironischerweise baut die einzige etwas zukunftsweisende Entwicklung auf diesem Gebiet, die Standardisierung von SGML (Standard Generalized Markup Language), auf der das heute so allgegenwärtige HTML (Hypertext Markup Language) beruht, auf den damals vielgeschmähten Steuerzeichen der Textverarbeitung von IBM auf.

Der gewaltige Publikumserfolg des World Wide Web ist auch das Verdienst dieses Dokumentenstandards, der Textlogik über äussere Erscheinung setzt. Dank diesem Richtungswechsel wurde es möglich, denselben Inhalt in verschiedenen Formen zu präsentieren. Er wird denn auch von den Experten der Kommunikation intensiv bekämpft und zerfetzt, denen der Inhalt nichts gilt, die bunte Form jedoch alles. Der Gedanke, die Amateure der Kommunikation, die Bezüger und Leser von Dokumenten auf dem Netz könnten selber den Schriftsatz bestimmen, in dem sie am liebsten lesen oder drucken möchten, ist diesen selbsternannten Kommunikationsgurus ein Greuel. Diese Ewiggestrigen versuchen in neuen Standardisierungsrunden schon wieder die Textlogik ins Korsett der Pixel zu spannen und damit die weltweite Kommunikation auf das bildlich Darstellbare zu reduzieren indem sie die sprachliche Reflexion ausschalten.

Die Schwierigkeit beim Benutzen von Programmen liegt darin, das herauszuholen, was wir wollen, nicht was wir sehen. Statt WYSIWYG müsste der Slogan WYWIWYG (What You Want Is What You Get) heissen. Das würde uns den ultimaten Programmen etwas näher bringen.


Relationale Datenbanken

Nicht Programmobjekte, sondern relationale Datenbanken stellten die erste Arena für massive und sich epidemisch verbreitende Hypostasierung auf dem Gebiet der modernen Computertechnologie dar. Wie die objekt-orientierte Methode der Programmentwicklung war die Einführung der relationalen Datenbanken in ihrem Wesen ein grosser Fortschritt im Umgang mit informationsverarbeitenden Maschinen. Kritisch wurde es erst, als das mathematische Konzept der Relation überladen wurde mit der Hypostasierung, die unter dem Stichwort Entity-Relationship Modell propagiert wurde. Schon im zitierten CORBA-Buch sind wir oben den “erkennbaren Entitäten des Alltagslebens” im Zusammenhang mit der totalen Hypostasierung von Programmobjekten begegnet.

Nichts lag der Erfindern der “relationalen” Datenbanken ferner als die Modellierung der Welt vermittels Imitation. Statt dessen ging es – ähnlich wie beim objekt-orientierten Modell – zuerst um Erhöhung von Konsistenz, um Vermeidung von Fehlern, um Lokaliserung von benötigtem Wissen, um die saubere Trennung von Zielvorgaben. Man hatte festgestellt, dass sich viele in Computern gespeicherte Daten aufeinander beziehen. Der Versuch, aus diesen Beziehungen mit Hilfe von wild durcheinanderzeigenden Querverweisen Kapital zu schlagen, schlug insofern fehl, als es sich als nahezu unmöglich erwies, die Verweiskonsistenz aufrecht zu erhalten. In der Folge zeigten eben mehr und mehr Verweise ins Nichts – wie etwa heute die wild querverweisenden Hyperlink-URLs im World Wide Web. Ausserdem waren Art und Weise des Verweisens gegen Ende der Sechziger Jahre nicht so gut standardisiert, wie etwa heute die URL (Universal Resource Locators). Insofern hing die Auflösung eines Verweises oft vom Programm ab, welches auf die gespeicherten Daten zugriff.

Zur Behebung dieser Unzulänglichkeiten der frühen Datenbanken wurde das relationale Modell entwickelt. Weil Daten viel länger “leben” als Programmiersysteme, sollten nur Daten und kein Code gespeichert werden. Inkonsistente Zustände sollten von vornherein ausgeschlossen werden. Verweise sollten wieder als Daten gespeichert sein, damit sie nicht zusammen mit den Programmiersystemen obsolet wurden. Als Datenmodell wurde deshalb die mathematische “Relation” gewählt. Eine Datenbank sollte nur Relationen speichern. Jede Operation auf einer Datenbank würde als Operation auf Relationen wieder Relationen ergeben. Die Logik des mathematischen Relationenmodells würde die Konsistenz der Daten garantieren, solange nur relationale Operationen auf ihnen ausgeführt wurden.

Eine Relation im mathematischen Sinne ist eine Beziehung zwischen den Elementen mehrerer Mengen. Ein Satz von solchen Elementen steht entweder in der gemeinten Beziehung oder nicht. So ist etwa die Autor-Buch-Relation eine Beziehung zwischen Mitgliedern der Menge der Menschen und der Menge der Bücher. Ein spezieller Mensch M und ein spezielles Buch B stehen in dieser Beziehung oder nicht. Insofern ist eine Relation nichts anderes als eine Teilmenge aller möglichen Kombinationen von Elementen aus den die Relation konstituierenden Mengen (d.h. eine Teilmenge ihres kartesischen Produkts). Eine solche mathematische Relation kann nun “intensional” oder “extensional” beschrieben werden. Unter “intensional” versteht man in diesem Zusammenhang die Angabe von Regeln, anhand deren man feststellen kann, ob ein Satz von Mengenelementen zur Relation gehört oder nicht. Unter “extensional” versteht man die Beschreibung der Relation durch vollständige Auflistung aller Sätze von Mengenelementen, die in der gemeinten Relation stehen. Die Verfolgung des intensionalen Ansatzes führt zur Identifizierung von Relationen mit logischen Prädikaten und zur Entwicklung der mathematischen Logik. Der extensionale Ansatz führt direkt zu den relationalen Datenbanken.

Als Aufzählung einer Teilmenge von Sätzen von Elementen der konstituierenden Mengen, ist eine extensional beschriebene Relation einfach eine Tabelle. Jede Zeile einer solchen Tabelle stellt einen Satz von Daten dar, der in der intendierten Relation stehen. In jeder Spalte der Tabelle dürfen nur Elemente derselben Menge vorkommen. Tabellen können einfach verknüpft werden, indem man ein Spaltenfeld einführt, dessen Wert den Datensatz eindeutig identifiziert (etwa die AHV-Nummer für Arbeitnehmer in der Schweiz).

Da relationale Datenbanken konzeptionell eine gewisse Nähe zur mathematischen Logik aufweisen, liegt es nahe, ihre Konsistenz mit Hilfe des Prädikatenkalküls zu formulieren. Auf diese Weise können Anforderungen deskriptiv und nicht prozedural und daher programmunabhängig gespeichert werden. Vor zwanzig Jahren hatte man noch Hoffnung, aus solchen deskriptiven Angaben mit Hilfe von Beweisprogrammen (Theorem Provers) alle erdenkbaren logischen Schlussfolgerung aus der derart relational beschriebenen Welt ableiten zu können. Dieses Programm scheiterte auf zweifache Weise: einerseits erwies es sich als unmöglich, zuverlässige Beweisprogramme zu schaffen, wie dies schon von Gödel, Turing und anderen früher einmal nachgewiesen worden war, andererseits erwies sich der Aufwand, die “Welt” in Relationen (Prädikaten) extensional zu beschreiben, als prohibitiv.

Relationale Datenbanken haben in den letzten zwanzig Jahren einen Siegeszug um die Welt angetreten. Das Wort Datenbank selber ist zum Synonym für relationale Datenbank geworden. In der Praxis haben sich die Prinzipien dieses Modells wieder und wieder glänzend bewährt.

Ein gutes Programmier- oder Datenmodell schützt allerdings nicht vor seiner unzweckmässiger Anwendung. Das gilt für das objekt-orientierte Programmiermodell wie für das relationale Datenmodell.


Hypostasierung und relationaler Design

So fiel denn auch das Modell der relationalen Datenbanken schon früh der Hypostasierung zum Opfer. Diese wurde in diesem Fall bekannt unter dem Namen Entity-Relationship-Modell und sie war fast so populär wie heute das objekt-orientierte Modell. (Im Vorbeigehen fällt auf, wie verräterisch die Namen dieser Strömungen auf die Tatsache der Verdinglichung hinweisen: OBJEKT-orientiert, ENTITY-Relationship, ...)

Nun waren also nicht mehr alle Tabellen in einer Datenbank Relationen, sondern manche “vertraten” Objekte unserer Anschauung oder unseres Denkens, während andere Beziehungen zwischen diesen Objekten darstellten. Da das Ganze in einfachen Diagrammen ausdrückbar sein sollte und in Zukunft der Datenbank-Design von Nichtprogrammierern gemacht werden sollte, beschränken sich die meisten Verkünder dieser Neuen Lehre auf zweistellige Beziehungen. Dafür wird dann viel Taxonomie verschwendet, um diese nach der Anzahl der möglichen Beziehungspartner zu klassifizieren (1—1, 1—c, 1—m, 1—mc, c—c, c—m, c—mc, m—m, m—mc, mc—mc).

<Gnosarch zitieren?>

Bei der Anwendung des Entity-Relationship-Modell tauchen verschiedene Probleme auf: einerseits dürften funktionale Bezüge (mit einer 1 am einen Ende der Relation) nicht vorkommen, sondern die abhängigen Werte müssten eigentlich als “Attribute” der Entitäten gespeichert werden. Dies widerspricht aber gutem Datenbank-Design und der Forderung, dass Datenbanken der sogenannten Dritten Normalform genügen sollten. Wenn der gute Design respektiert wird, erhalten wir jedoch äusserst gequälte Objekte unserer Anschauung oder unseres Denkens und die Beziehungen zwischen ihnen sind überhaupt nicht mehr intuitiv.

Andererseits neigen Nichtprogrammierer dazu, mit Hilfe dieses Modells ein grauenvoll komplexes Abbild der Welt mit allen erdenklichen Querbeziehnungen zwischen allen erdenklichen Entitäten zu entwerfen. Grundsätzlich ist nicht zu bestreiten, dass die reale Welt wirklich so komplex ist (oder noch komplexer!) und darum alle dieser Beziehungen gerechtfertigt sind, wenn man sie präzis beschreiben will. Der Hase liegt aber genau da im Pfeffer: Wer will denn die Welt wie sie ist als Kollektion von Entitäten und Relationen abbilden? Wozu soll denn so etwas gut sein? Die Handlungsanweisung an den Datenbankdesigner: Identifiziere die Objekte des Problembereichs und die Beziehungen zwischen ihnen und zeichne ein Eintity-Relationship-Diagramm! Das führt zu einem Versuch, die Welt zu beschreiben, in der Hoffnung, dass dann das anstehende Problem als Teil der beschriebenen Welt, gerade mitbeschrieben und somit simuliert wird. Viele objekt-orientierten Analytiker meinen, mit der Simulation eines Problems sei dieses schon gelöst.

Auch auf dem Gebiet der relationalen Datenbanken und sogar beim Einsatz der Entity-Relationship-Modelle ist die Modell-Basis eine sehr brauchbare. Erst die durch das Modell nahegelegte Hypostasierung der Entitäten und der Traum der programmiererlosen Entwicklung ohne Analyse schafft das Problem. Die Aufgabe der Analyse ist das Erkennen von Gesetzmässigkeiten (Abstraktion). Dadurch wird Wiederverwendung von Code in vielen verschiedenen praktischen Situationen ermöglicht und der Komplexitätsexplosion ein Riegel geschoben.


Objekte und Datensätze

Bei genauerem Hinsehen ist es nicht ganz überraschend, dass die vorliegenden Überlegungen nahtlos vom objekt-orientierten Modell der Programmierung zum Entity-Relationship-Modell des Datenbankdesign geführt haben. Es besteht eine tiefere Analogie zwischen Objekten und Datensätzen. Aus dieser Perspektive ist CORBA nur eine verteilte relationale Datenbank.

Ein Objekt enthält normalerweise Daten, die seinen inneren Zustand darstellen. Diese werden Datenmembers des Objekts genannt. Aus Datenbanksicht kann man also das Objekt als Datensatz beschreiben, dessen Attribute gerade die Memberdaten des Objekts sind. Die klassischen Datenbankoperationen sind normalerweise für jedes gut konstruierte Objekt implementiert: Erzeugung des Datensatzes (CREATE = Constructor), Zugriff auf die Attribute des Datensatzes (SELECT/UPDATE = Get¼/Set¼-Methoden), Löschen des Datensatzes (DELETE = Destruktor). Der Vererbung von Objekteigenschaften abstrakterer Klassen auf konkretere entspricht die relationale Projektion einer Relation auf eine Teilrelation mit weniger Attributen. Die Referenzierung eines Datensatzes einer Relation in einer anderen Relation wird im objektorientierten Design mit Hilfe von Ownership wiedergegeben. Diejenigen Methoden eines Objekts, die nicht den Standardoperationen auf relationalen Datenbanken entsprechen, verändern dennoch den Zustand des Objekts (und der von ihm referenzierten Objekte) und könnten somit aus den elementaren Datenbankoperationen zusammengesetzt werden. Durch die für den Benutzer unteilbare Verpackung in einer einzelnen Methode wird im Datenbanksinn eine Transaktionsklammer realisiert, die den Benutzer vor inkonsistenten Zwischenzuständen des Objekts (der Datenbank) schützt, welche diese "stored procedure" durchläuft, bevor sie am Ende wieder einen konsistenten Zustand hergestellt hat.

Die Autoren von “Instant CORBA” bezeichnen das Verwalten von Abermillionen von Objekten in einem ORB als heute in den kommerziell verfügbaren CORBA-Implementationen ungelöstes Problem. Aufgrund der oben aufgeführten Analogie zwischen CORBA-Objekten und Datensätzen in verteilten Datenbanken, bietet sich als Lösung für dieses Grundproblem des zukünftigen Object-Web der Einsatz klassischer relationaler Datenbanken für die Objektverwaltung an.


Traum vom programmiererlosen Unternehmen

Ein Zweck des Einsatzes von hypostasierten Geschäftsobjekten besteht darin, diese anwenderspezifischen Konzepte auf so natürliche Art und Weise zu beschreiben, dass Anwender mit ihnen umgehen können und somit keine Programmierer mehr nötig sind, um aus solchen Objekten Applikationen zusammenzusetzen.

Für viele Informatikverantwortliche sind die Programmierer das Problem. Ihre Abschaffung stellt somit die ultimate (schon wieder!) Problemlösung dar. Programmierer sind in der heutigen Welt zu Glitzerknaben geworden. Sie werden von Anwendern bewundert, weil sie dem Computer gegenüber souverän und nicht ausgeliefert gegenübertreten. Sie werden von Informatikmanagern gehasst, weil ihre Produktionstechnik eine kreative Manufaktur ist, die sehr schlecht planbar ist. Ausserdem ist das, was sie tun nur sehr wenigen Eingeweihten, nämlich anderen Programmierern, verständlich. Alle anderen, insbesondere auch ihre Vorgesetzten, sind darauf angewiesen, ihnen zu glauben. Ihrer Arbeit hängt ein Geruch von Magie an. Obwohl die Produktion von Software regelmässig zu Katastrophen führt, stellen sie doch immer wieder nützliche, arbeitssparende Produkte her, welche die Grenzen des Menschenmöglichen weiter verschieben.

Programmierer sind entgegen allgemein verbreiteten Vorurteilen oft schlechter bezahlt als etwa Sozialarbeiter. Für wirklich gute Programmlösungen erhalten sie fast nie positive Würdigung, weil der Text, den sie produzieren, nicht von Mitprogrammierern gelesen, sondern von Anwendern benützt wird. Ihr Ansehen wird sich zeitbedingt ändern. Wie in der Jugendzeit des Kraftfahrzeugs der Automechaniker das Idol der Jugend war, und, kurz nach der Erfindung des Rundfunks der Radioelektroniker die Berufsträume beherrschte, so hat der Programmiererberuf heute seine kurze Sternstunde. Wenn sich der Staub gelegt hat, wird dieser Beruf unter den kreativen Berufen eingereiht an Faszination verlieren und an seriöser Wertschätzung gewinnen. Dann werden Programmierer und Programmiererinnen in Gewerkschaften organisiert sein, wie heute Werbegraphiker. In der Zwischenzeit träumen die objekt-orientierten Informatikprofessoren, sie müssten ihren Studenten das Programmieren nicht mehr beibringen, da diese Fähigkeit sowieso nicht mehr benötigt wird, wenn das aus CORBA und JAVA bestehende Object-Web aufgebaut ist.

Wenn man genauer hinschaut, wie man sich einen solchen programmiererlosen Umgang mit Objekten vorzustellen hat, werden zur Illustration des objekt-orientierten Postulats der Notwendigkeit der Imitation der Realität normalerweise kleine Demonstrationssysteme vorgeführt, wo sich die anwenderspezifischen Objekte graphisch manipulieren lassen. Sie können einander eingepflanzt werden, Beziehungen können als kleine Verbindungslinien vom einen zum anderen gezogen werden, usw. Das alles wirkt äusserst intuitiv und kann einem Anwender durchaus zugemutet werden, da die Programmobjekte ja die anwenderspezifischen Objekte der realen Welt imitieren. Programmierer braucht man dabei keine mehr, da ja nirgends mehr ein IF oder ELSE oder WHILE vorkommt – solche Programmiersprachenkonstrukte wären natürlich dem Anwender nicht zuzumuten.

Sobald man von solchen kleinen Systemen zu mächtigen Anwendungen überzugehen versucht, wie dies eine Reihe von CASE-Tools tun, werden allerdings ebenso harte formale Anforderungen an die Manipulation der graphischen Objekte gestellt, wie seinerzeit an die Korrektheit eines in einer programmiersprache formulierten Programms. Die Programmierung hat sich einen graphischen Überwurf zugelegt, sie ist aber Programmierung geblieben. Anwender sind hoffungslos damit überfordert, obwohl sie nur die Manipulation graphischer Elemente voraussetzt. Die CASE-Tool-Experten tauchen aus der Versenkung auf, in der die Programmierer verschwunden waren.

Ein entscheidender Nachteil beim Übergang von sprachzentrierter zu graphikzentrierter Programmierung schleicht sich bei diesem Übergang allerdings ein. Diesen Nachteil kennen alle Benutzer von graphischen Oberflächen ohne befehlszeilenorientierte Alternative. Repetitive Abläufe können nicht mehr einfach automatisiert werden. Mausklicks lassen sich schlecht in Batchdateien verpacken. Als Programme noch in Programmiersprachen geschrieben wurden, konnte man Programme schreiben, welche Programme schreiben (z.B. lex, und viele mehr). In den modern gewordenen graphischen Umgebungen ist diese echt digitale Entwicklungsmöglichkeit weitgehend unter analogem Wust begraben worden.


Vom Nutzen und Nachteil des objekt-orientierten Designs für das Leben

Ein klassischer Irrtum der neuen Welle des objekt-orientierten Designs besagt, bei dieser Designart seien Analyse und Spezifikationen hinfort überflüssig. Wie es zu diesem Irrtum kommt, wird verständlich aufgrund der Kernübels der objekt-orientierten Technik, der Hypostasierung der Objekte. Wenn die Entwicklung von Anwendungen nur darauf hinausläuft, Objekte in der Wirklichkeit nachzubauen, ist tatsächlich keine tiefere Analyse vonnöten. Was zu tun ist, liegt auf der Hand.

Dieser Grundirrtum führt alle mir bekannten missionarisch objekt-orientierten Projekte in den ökonomischen Abgrund. Beim Imitieren der Wirklichkeit, werden die Programmobjekte nämlich immer komplexer und ähneln ihren Gegenstücken in der Realität doch immer nur kläglich wenig. Den ursprünglich angestrebten Nutzen können sie natürlich nicht erbringen, da dieser in den seltensten Fällen durch Nachahmung statt Lösung der Probleme in der Wirklichkeit realisiert werden kann. So haben etwa die objekt-orientierten Datenbanken die Fortschritte einer jahrzehntelangen, hochentwickelten theoretischen Kultur des Datenbankdesigns zurückgeworfen auf den Stand des Computermittelalters in den frühen sechziger Jahren.

Wer objekt-orientierte Techniken benutzt, ohne in die Hypostasierungsfalle zu tappen, kann durchaus von einzelnen Eigenschaften des objekt-orientierten Modells profitieren. Modularität, Abstraktion und Kapselung sind sicher sehr ehrenwerte und nützliche Techniken der Programmierung, die besonders bei grossen Projekten von hoher Wichtigkeit sind. Insofern hat uns C++ endlich die extensive Typenprüfung gebracht, wie wir sie von PASCAL her kennen, es hat uns saubere Kapselung der Innereien eines Moduls gelehrt, wie wir sie von Modula-2 her kennen. Wie bei Oberon kann man abstrakte Datentypen (Objekte mit Methoden und versteckter Repräsentation der Daten) in dieser etwas barocken Sprache wunderbar klar realisieren. Nur setze man diese Techniken ums Himmels willen nicht dafür ein, die Natur nachzuahmen!

Nachdem es der ersten Generation von blauäugigen Smalltalk-Jüngern gelungen ist, mit der Behauptung, objekt-orientierter Code brauche keine Pflege und um Grössenordnungen weniger Wartung, auch seriöse Grossbetriebe davon zu überzeugen, einen beträchtlichen Teil ihrer strategischen Betriebssoftware objekt-orientiert umzubauen, hat es sich inzwischen herausgestellt, dass einerseits die angebliche kürzere Entwicklungszeit eine Illusion war, weil die fehlende Analyse zu mehrfachen Implementationsanläufen zwingt, andererseits hat sich die Hoffnung auf Wiederverwendung von Code, der in anwendungsunabhängigen Geschäftsobjekten steckt, nicht bewahrheitet, drittens hat nun fast jeder Programmierer erlebt, dass verlassen ist, wer sich auf irgendwelche vollmundigen “Frameworks” (ob MFC, ob OWL, ob JAVA oder wie sie alle heissen) verlässt, schliesslich besitzt das Objektmodell auf Objektebene nur einen flachen Namespace, der sämtliche Modularisierung verhindert. Dies fällt beim kompilierten und mit statischen Scoping-Regeln versehenen C++ weniger ins Gewicht, macht aber die Entwicklung in Smalltalk oder in CORBA zum wahren Alptraum.

Die manifesten Probleme der objekt-orientierten Manie wurden anfangs den schlechten Programmierern angelastet. Es wäre ja denn auch unfair, die Methode zu verunglimpfen, die doch nichts dafür kann, wenn sie von unfähigen Entwicklern angewendet wird. Da Programmieren im allgemeinen kein einfaches Metier ist, finden sich immer viele Beispiele dafür, dass dumme Programmierer sensationelle Instrumente inadäquat einsetzen. Unheilvollerweise ist aber gerade ein zentrales Dogma der OO-Religion, dass Programmierung im objekt-orientierten Modell so furchtbar einfach ist, dass nur erstsemestrige Collegestudenten diese beherrschen können. Insofern ist es heute an der Zeit, aus den akkumulierten volkswirtschaftlich fehlinvestierten objekt-orientierten Milliarden den Schluss zu ziehen, dass dieses Heilmittel der Softwarekrise den Tod des Patienten nach sich zieht.

Obwohl fast alle Behauptungen der ökonomischen Vorteile der objekt-orientierten Entwicklung inzwischen aufgrund von Erfahrungen widerlegt sind, obwohl nur wenige Entwickler Smalltalk oder CORBA können (beim C++ stocken sie schon!), obwohl kein Mensch riesigste Frameworks produktiv einsetzen kann, werden in den Chefetagen der grossen Informatikkonzerne weiterhin aus Gründen der politischen Korrektheit robuste Anwendungen durch verrottete objekt-orientierte Middleware ersetzt.


Analoge Imitation und Digitale Abstraktion im Object-Web

Die Prophezeihung im oben erwähnten CORBA-Traktat, dass CORBA Ende 1997 fast so allgegenwärtig werden könnte, wie TCP/IP [CORBA may become almost as ubiquitous as TCP/IP by the end of 1997.] hat sich zwar nicht bewahrheitet. Wie alle Sätze im zitierten Buch handelt es sich um Stumpfsinn, da alle CORBA-Implementationen auf TCP/IP beruhen und somit der Vergleich der Allgegenwärtigkeit des einen mit derjenigen des andern eine unzulässige Vermischung von Ebenen darstellt. Trotzdem ist das Object-Web wohl nicht mehr aufzuhalten. Die gesellschaftliche Trägheit dieser Fehlentwicklung ist zu gross. Es ist zwar schade um ein paar verlorene Jahrzehnte der menschlichen Geistesentwicklung auf dem Gebiet der Informatik, die dieser Irrweg kosten wird, aber es ist wohl manchmal notwendig und lehrreich, wie Peer Gynt, einen Umweg zu machen, um zum Ziel zu gelangen.

Während das Web diesen Umweg geht, können Informatikmanager diesen so kurz wie möglich halten, nicht indem sie das Object-Web bekämpfen, sondern indem sie die Hypostasierungstendenzen bei jeder einzelnen Object-Web-Anwendung hinterfragen. Programmierer können ihrer Arbeit weiterhin gerecht weren, wenn sie sich vor Augen führen, dass Analyse nicht das Aufzeichnen von Abbildern wirklicher Objekte des Alltagslebens ist, sondern der permanente Kampf gegen die Komplexitätsexplosion, wo mit Hilfe von Klugheit und Abstraktion mit wenig Aufwand viel Nutzen zu schaffen ist. Die klassische verfehlte Applikationsentwicklung schafft mit viel Aufwand wenig Nutzen. Daran erkennen wir gescheiterte Projekte, auch wenn sie als Erfolg verkauft werden.

Während wir in der CORBA-Agitprop-Broschüre lesen, dass Benutzer nicht zu wissen brauchen, wo ein verteiltes Objekt residert, oder auf welchem Betriebssystem es ausgeführt wird, müssen wir darauf dringen, dass Anwender einen unverzichtbaren Anspruch darauf haben, zu wissen, wer für die Aktionen eines solchen Objekts verantwortlich gemacht werden kann. Das wird kaum abgehen, ohne dass man auch ein bisschen etwas über das “wo” weiss ...

Während das grosse Business auf der Client-/Serverwelle surft, sollten wir uns vermehrt den Peer-to-Peer-Services widmen. Es ist abzusehen, dass diese symmetrische (über Netzanwednungen vermittelte) Kommunikation von Benutzer zu Benutzer ein weitaus wichtigerer Zweig der Entwicklung werden wird, als die asymmetrische Bevormundung des Anwenders an seinem Javaterminal durch den ORB einer Grossfirma.

Wer Programme schreiben will, die echten Mehrwert erzeugen, muss sich auf die Überlistung der Komplexitätsexplosion bemühen. Dies wird  desto eher gelingen, je weniger Ähnlichkeit die Problemlösung mit dem Problem hat. Gefragt ist digitale Abstraktion, nicht analoge Imitation.