In letzter Zeit sprach ich mit mehreren Kollegen, die nicht genannt werden wollen, über die Entwicklung der Software und wie man sie verbessern kann. Wir sind zwar noch zu keinen konkreten Ergebnissen gekommen, aber die besprochenen Ideen sind dennoch so interessant, dass ich sie hier beschreiben möchte.

Neues Entwurfsmuster - Multiplon

Alle echten Softwareentwicker kennen und lieben das Singleton-Entwufsmuster, alle wissen wie man es implementiert und viele sogar, wann man es tun sollte.

Nun hat aber das Singleton einen Nachteil: Es kann nur ein Objekt einer Singleton-Klasse geben. Niemand aus der Softwarebranche kann aber ernsthaft behaupten, dass nur ein einziges Objekt für eine Anwendung ausreichen kann. Nach einer intensiven Mustererkennung in verschiedenen Quelltexten, haben wir ein bisher unbeachtetes Entwurfsmuster erkannt und es Multiplon genannt: Ein Multiplon funktioniert ähnlich wie ein Singleton, nur mit dem Unterschied, dass es mehrere Exemplare einer Klasse zulässt. Damit kann man die Anwendung in kleinere, einfachere Komponenten aufteilen.

Ein Kollege hat jedoch die Meinung geäußert, dass die Tatsache, dass eine Singleton-Klasse nur ein Exemplar haben kann, gar nicht ein Nachteil sondern eine fachliche Einschränkung ist.

Zugegeben, da kann er recht haben. Und in der Welt der proprietären Software kann es sicherlich diese „Einschränkungen“ geben. Wo würde es aber hinführen, wenn wir in der Welt der freien Software (FLOSS) solche fachlichen, patentrechtlichen, ökonomischen oder sonstigen Einschränkungen dulden würden? Wir wollen doch, dass die Software frei und in keiner Weise eingeschränkt ist.

Neues Paradigma - Prohibitives Programmieren

Es gibt verschiedene Paradigmen der Programmierung: Deklaratives Programmieren wie im Prolog, funktionales Programmieren mit LISP oder XSLT... das, mit dem wir uns am häufigsten beschäftigen, ist das imperative Programmieren (C, C++, Java, usw.)

Es gibt verschiedene Versuche, die Programmiersprachen so zu gestallten, dass sie sich an die menschlichen Denkmustern anlehnen und so verständlicher und einfacher werden. Die Objektorientierung verteilt das Programm in Objekte, die wie in der echten Welt, Eigenschaften und Verhalten besitzen. Die Aspektorientierung versucht der Tatsache Rechnung zu tragen, dass die Objekte aus verschiedenen Perspektiven betrachtet werden können.

So können wir auf verschiene Art und Weise dem Computer sagen, was er wann machen soll. Wäre es aber nicht oft einfacher dem Programm zu sagen, was es lassen soll? Also statt imperativ eben prohibitiv zu programmieren?

Wenn man also z.B. die Persistenz in einem Programm implementieren will: Statt bei jeder persistenten Entität Save(), Commit() usw. auszuprogrammieren, würde man die ganze Persistenz nur an einer Stelle implementieren und lediglich bei den transienten Teilen die Methode DontSave() hinzufügen.

Weitere Elaboration dieser Idee wurde leider dadurch verhindert, dass wir uns nicht darauf einigen konnten, ob die prohibitiven Methoden virtuell sein können. Manche behaupten, dass man etwas nur auf eine Art und Weise nicht tun kann, und es deswegen nicht sinnvoll sein kann, verschiedene Implementierungen davon zuzulassen. Andere sagen, dass das Nichtstun zwar gleichartig sein mag, die Art des Verbietens aber durchaus Nuancen in der Implementierung zulässt. Wieder andere argumentieren mit der, aus SQL bekannten, NULL, die zwar intern gleich implementiert ist, aber nie einer anderen NULL gleicht. (NULL == NULL ist nie TRUE).

Solange jedoch keine Einigkeit in solch fundamentalen Fragen gefunden wird, kann die Idee des prohibitiven Programmierens leider nicht weiterentwickelt werden :-(

Psychologie der Programmiersprachen

Die Computerhardware wird immer leistungsfähiger und so verschieben sich die ökonomischen Schwerpunkte der Softwareentwicklung. Vor 30 Jahren kostete ein Prozessorzyklus oder ein Bit im Computerspeicher das Milliardenfache des heutigen Preises. So war es nur natürlich, dass sich die Softwareentwicklung der effektiven Nutzung der Computerressourcen gewidmet hat und sich an den "Bedürfnissen" der Computerlogik orientiert hat. Alles wurde optimiert, streng logisch. Eine 0 hier, eine 1 da. Alles mathematisch präzise.

Heutzutage ist die Hardware schnell und preiswert und die Kosten der Entwicklung spielen immer größere Rolle. Obwohl sich die Programmiersprachen der menschlichen Psychologie immer mehr annähern, und es den Programmieren ermöglichen, statt über Bits und Bytes über die fachlichen Anforderungen nachzudenken - sind sie immer noch streng logisch und kalt präzise. Wichtige Aspekte der menschlichen Psyche sind in den Programmiersprachen überhaupt nicht vorhanden.

Nehmen wir z.B. die Boolsche Logik. Sie ist einfach und klar - wie geschaffen für Mathematik und Computer. Die menschliche Logik funktioniert aber anders. Ein Mensch würde kaum die Frage „Mitnehmen oder hier essen?“ mit „Ja“ oder „Nein“ beantworten. Ein Computer würde keine andere Antwort verstehen.

Es ist aber nicht nur die Dominanz der Computer in der Mensch-Maschine-Beziehung, die solche Diskrepanzen verursacht. Traditionell wird das Englische als Ausgangspunkt für die Programmiersprachen verwendet. Obwohl dies schon Sinn macht, ließen sich bestimmte Probleme besser mit Strukturen anderer natürlichen Sprachen adressieren.

Das Deutsche, früher die Sprache der Wissenschaft, wäre im Stande die Logik der Programmiersprachen wesentlich zu erweitern. Wie kann man, fragt man sich, überhaupt von einer vollständigen Logik sprechen, wenn das kurze aber sehr wichtige Wörtchen „doch“ fehlt?

Kein Wunder, dass die gängigen Ausdrücke oft zu Kurzschlüssen führen. In vielen Programmiersprachen wird z.B. in einem Ausdruck a() and b() die Funktion b() gar nicht ausgewertet, wenn a() FALSE zurückgibt - in der Annahme, dass FALSE und irgendwas immer FALSE ergibt. Wenn jetzt aber b() nicht nur mit FALSE oder TRUE sondern auch mit DOCH antworten könnte, wäre solche Schlamperei ausgeschlossen. Diese mehrwertige Logik könnte man aber auch um andere Antworttypen erweitern. Denn kein „DOCH“ ist ohne ein „VON WEGEN!“ komplett. So lange aber alle Programmiersprachen von Englischem abgeleitet sind, müssen wir and diesen Mehrwert verzichten. Die einzige Hoffnung besteht darin, dass das Englische das Wort DOCH übernimmt - schließlich wurde auch „Eigenvector“ oder „Schadenfreude“ übernommen.

Ein weiterer Aspekt, den das Englische nicht besonders gut ausdrücken kann, ist das Konzept der Höflichkeit. In Englischem gibt es kein siezen oder duzen und so wundert es niemanden, dass z.B. in C++ die Unterklassen die Oberklassen einfach so mit deren Namen ansprechen. In Java gibt es zwar das Schlüsselwort super, das diese Ungehörigkeit beseitigt, dafür aber ging das Konzept der Freundschaft zwischen den Klassen völlig verloren.

Hier wäre eher eine Kombination des Japanischen und des Französischen angebracht.

Im Gegensatz zu Deutschem hat kennt das Japanische angeblich nicht nur zwei Höflichkeitsstufen, sondern sieben. Damit könnte man ganze Klassenhierarchien in leicht verständlichen Stukturen beschreiben.

Mit dem Schlüsselwort friend können Klasen in C++ anderen Klassen den Zugriff auf Ihre Privatteile erlauben. Ich bin davon überzeugt, dass das Französische mehr Möglichkeiten bietet, die Zugriffmodalitäten auf eigene Privatteile zu beschreiben. (Kein Wunder, dass eine Sprache, die mehr Kontrolle als Java oder C++ ermöglicht gerade Eiffel heißt).

Man könnte es natürlich auch in andere Dimensionen erweitern. Das Italienische oder die slawischen Sprachen würden sich hervorragend für das pejorative Programmieren eignen, dessen formelle Andeutung man als Exceptions kennt.

Disclaimer

Die hier beschriebe Ideen kann man nur dann in der richtigen Perspektive sehen, wenn man bedenkt dass heute Rosenmontag ist, und hier in Rheinland seit paar Tagen alle jeck sind :-)