Komplementäre Softwareentwicklung

"Die Komplementarität ist meiner Ansicht nach wichtiger als jeder Ansatz, den wir haben, auch wenn wir es in unserem Kulturkreis noch nicht wissen." Das habe ich gerade im Blog der Denkagentur des Château d'Orion gelesen – und es hat sich sehr stimmig angefühlt.

Gesagt hat es der Wissenschaftstheoretiker Ernst Peter Fischer und gemeint hat er (wohl), dass uns Verständnis und Erkenntnisgewinn leichter fallen, wenn wir nicht entweder-oder denken, sondern sowohl-als-auch. Die Welt ist nicht extrem, dogmatisch, einseitig. Sie ist facettenreich, bunt, vielseitig.

Hat Platon Recht oder Aristoteles? Die Bibel oder der Koran? Der Kapitalismus oder der Kommunismus? Die Wissenschaft oder die Kunst? Sollen wir der Wirtschaft oder der Natur folgen? Den erneuerbaren Energien oder den fossilen? Ist es besser Grenzen zu bauen oder sie niederzureißen? Soll man hart durchgreifen oder die Dinge sich selbst regeln lassen? So viele Entscheidungen für eine Seite und damit gegen die andere.

Aber warum? Tut es Not, so harte Schlusstriche unter diesem oder jenem zu ziehen? Müssen wir uns klar und für immer positionieren?

Die Komplementarität sagt Nein. Sie gibt beiden Seiten Raum. Sie behauptet sogar, dass beide Seiten von einander abhängen und immer zusammen auftreten. Oder wenn nicht, dass dann etwas fehlt und dieses Fehlen irgendwann zu einem Problem führen wird. So verstehe ich es zumindest, wenn in der Traditionellen Chinesischen Medizin (TCM) oder im Qigong von Yin & Yang die Rede ist. Es geht nicht um Fixierung oder Haltung, sondern um Fluss und Balance.

In Bezug auf die Softwareentwicklung ist mir als erstes die Funktionale Programmierung (FP) eingefallen und dann gleich hinterher die Objektorientierte Programmierung (OOP). Die stehen sich scheinbar unversöhnbar gegenüber. Muss das aber sein?

Ja, ich glaube, solange sie an ihrem Namen festhalten, wird es unnötig lange dauern, den Frieden herzustellen. Denn diese Namen grenzen aus. Sie polarisieren. Die FP konzentriert sich auf die Funktionen. Die OOP konzentriert sich auf die Strukturen.

Das ist natürlich komplementär – nur sehe ich dafür keine Bewegung. Niemand vertritt die inklusive, die Komplementarität suchende Haltung. Schon in der Bezeichnung "hybride Sprache" für z.B. F# steckt ein Augenrollen für viele. Davon zu sprechen, um die Positionen zu verbinden, scheint mir eine schwache Kraft.

Wie könnte der Name für eine Art der Programmierung lauten, der die Komplementarität anerkennt, gar betont? Es geht sowohl um Funktionen wie um Strukturen, sowohl um Verhalten als auch um Daten.

Für mich persönlich passt Datenflussprogrammierung recht gut. Im Datenfluss stecken sowohl die Daten wie der Fortschritt, also dass es weitergeht, kein Stillstand herrscht. Wenn wir Datenflusssprachen hätten, dann wären das ganz bewusst Sprachen der Komplementarität.

Vielleicht sind F# oder Scala schon solche Sprachen? Vielleicht. Nur fehlt ihnen dann bisher eine Kategoriebezeichnung, die das widerspiegelt.

Nach FP vs OOP sind mit Software Craftsmanship (SC) vs Software Engineering (SE) in den Sinn gekommen. Auch hier soll man sich scheinbar entscheiden müssen: Sind sie ein SC oder ein SE?

Aber warum? Haben nicht beide Sichtweisen etwas wertvolles zur Sache beizutragen? Warum so extrem? Jetzt ist das eine out und das andere in.

Mein Gefühl ist, wir machen uns das Leben schwerer als nötig, wenn wir glauben, ohne Komplementarität auszukommen. Wenn also zur Erinnerung daran auf dem einen oder anderen Laptop-Deckel mal ein Yin-Yang-Symbol auftauchen sollte, fände ich das nicht verkehrt. Es ist so ästhetisch wie universell.