Welches Paradigma passt zu Dir?

Im Internet werden ständig sinnlose und anstrengende Glaubenskriege geführt. Das fängt damit an, welches Betriebssystem besser ist und geht dann weiter, welcher Browser cooler ist.
Diese Diskussionen kennt sicher jeder zur Genüge.

Nun müsste man meinen, dass wir als Softwareentwickler innerhalb unseres Bereiches vernünftiger wären. Tja, schön wär's. Da gibt es fast noch hitzigere Debatten, welche Sprache oder welches Paradigma besser ist.
Auch diese Diskussionen werden eher subjektiv, als objektiv geführt.
Man hört aber immer öfter heraus, man solle die Sprachen und Paradigmen wie Werkzeuge betrachten. Und so soll man eben immer das Werkzeug auswählen, welches zu einer bestimmten Problemstellung passt.

Nun haben wir aber das große Glück, dass mittlerweile fast alle größeren bekannten Programmiersprachen Multiparadigmensprachen sind. Damit sollte sich die Wahl der "richtigen" Sprache beinahe erledigt haben. Oft liest man auch von den vernünftigeren Diskutanten, dass man die Sprache wählen soll, dessen Syntax einem besser gefällt. Soweit, so gut!

Und wie ist das mit den Paradigmen? Da bleiben noch viele stur und möchten anderen gerne ihr eigenes bevorzugtes Paradigma aufdrängen. Der große Vorreiter unserer Zeit ist wohl die OOP. "Denn alles andere ist ja out und von vorgestern!"
Und leider wird einem dieses Paradigma wirklich oft aufgezwungen. Da braucht man sich nur mal die Bibliotheken rund um .NET oder Java anzugucken. Da geht wirklich nix mehr ohne OOP.

Was ist aber, wenn man nicht immer objektorientiert denken kann bzw. will? Was ist, wenn einem dieses objektorientierte Zeug Komplexe bereitet oder gar Denkblockaden auslöst?

Das klingt absurd? Sowas ist Unsinn? Der Softwareentwickler ist einfach nur zu dumm für OOP?

Dann sind Linkshänder aus der Sicht eines Rechtshänders sicher auch nur zu dumm, um mit der rechten Hand zu schreiben. Sollen sie doch gefälligst lernen, mit der rechten Hand zu schreiben. Immerhin kann die Mehrheit der Menschen auch mit der rechten Hand schreiben.
Zum Glück wurde diese Einstellung aus den Köpfen der meisten Menschen verbannt. (Auch, wenn bis dahin viele Linkshänder zur Rechtshändigkeit gezwungen wurden. Ich wollte früher als Kind auch mit Links schreiben ... aber mit spiegelverkehrter Schrift. Ich sollte dann aber mit der rechten Hand schreiben ... was ich auch heute noch tue. Ob das meine geistige Entfaltung beeinträchtigt hat, kann ich nicht klar sagen. *g*)

Warum ist das aber noch nicht in den Köpfen der Softwareentwickler angekommen?
Paradigmen werden immer noch wie Werkzeuge behandelt, die nur für ein bestimmtes Problem in Frage kommen und bei anderen wiederum nicht in Frage kommen (dürfen!).

Gerade in der OOP wird mit Dogmen umher geworfen, wo man meinen könnte, man hat die zehn Gebote vor sich. Da gibt es dann sogar Kampagnen, wie z.B. die "Anti-If-Kampagne", wo ich in dem Moment nicht weiß, ob ich lachen oder weinen soll. Früher war das böse "goto" das Übel allen Übels und musste bekämpft werden. Oh, das hat man auch erfolgreich durchgesetzt! Oder traut sich heute noch jemand ein wohl überlegtes "goto" in seinen Quellcode zu setzen, wenn es dem besseren Verständnis oder gar der Performance dient? Das macht kaum noch jemand, weil viele Angst haben, als unfähig bezeichnet zu werden.
Und nun versucht man das Selbe mit dem "if-then-else"-Konstrukt. Denn es gibt ja dafür die heilige Polymorphie. Und wer die nicht in seinem Programm verwendet, ist doch von vorgestern und unfähig.

Aber ich schweife etwas ab.

Der Punkt ist aber, dass man offenbar versucht, ein bestimmtes Paradigma zu DEM global gültigen Paradigma zu erheben. Dabei fragt aber keiner, ob man damit überhaupt zurecht kommt, oder nicht. (Gibt es überhaupt noch Frameworks, die nicht objektorientiert aufgebaut sind? Das ist eine ernsthafte Frage. Mir fällt da höchstens spontan die normale Win32-API ein.)

Dazu möchte ich ein Zitat einstellen, was mir sehr gut gefallen und mich dazu veranlasst hat, diesen Beitrag zu schreiben. Es ist auf der Seite "OOP Criticism" unter der Überschrift "One Mind Fits All?" zu finden:

...I was always told that OO was an intuitive way of thinking. Although I develop daily in OO languages, I do find OO rather unintuitive (although I manage). ... If I analyze a problem, I draw tables not objects and classes, I think in tables, those are much more intuitive to me. Even when I program in OOP, I rely as much as possible on tables. ...it's nice to see that I'm not the only one who 'thinks' in tables. ...

Es geht doch am Ende genau darum: Welches Paradigma passt zu Dir?
Einer denkt in Bildern, ein anderer in Tabellen und wieder ein anderer denkt in Wörtern oder etwas ganz Anderes.

Vielleicht sollten wir in Zukunft diesbezüglich offener und toleranter sein.
Es gibt eben nicht DAS Paradigma. Es gibt auch nicht DAS Paradigma für ein bestimmtes Problem.
Es kann nur DAS Paradigma geben, was DU in einem bestimmten Kontext für richtig hältst und womit DU am Besten zurecht kommst.

Wenn man in diesem Punkt die Freiheiten lässt, kann auch eine Entwicklung statt finden. Zum Einen kann man sich persönlich entwickeln, wenn man sein passendes Paradigma sucht. Zum Anderen kann man aber auch die Softwareentwicklung aktiv verändern. (Vielleicht entstehen dadurch sogar noch ganz andere Paradigmen?!)

Softwareentwicklung ist ein kreativer Prozess! Und Kreativität muss sich frei entfalten können! :-)

Warum versucht man die Welt zu modellieren?

Inspiriert durch den letzten Beitrag von Ralf Westphal "Mehr vom Selben hilft nicht mehr", dachte ich mir, dass es durchaus sinnvoll sein kann, der Kernaussage noch mehr Ausdruck zu verleihen. Ganz im Sinne von "Spread the word!"

Längere Zeit vorher beschäftigte ich mich auch mal mit Konzepten, wie z.B. Funktionale Programmierung und Data Oriented Design.
Und ich sagte so zu mir: "Verdammt! Recht haben sie!"

Es geht seit der Erfindung des ersten Computers um Datenverarbeitung. Und das möglichst effizient und seiteneffektfrei!

Warum ist das aber in Vergessenheit geraten? Haben wir schon lange den Boden unter den Füßen verloren?
Das kann man wohl annehmen. Dank *hust* der Objektorientierten Programmierung (OOP) programmiert man nicht mehr, sondern modelliert nur noch. Es wird alles Erdenkliche in Klassen beschrieben und durch Objekte ins Leben gerufen. Ob das nun sinnvoll ist, oder nicht. Egal! "OOP ist ja sooo geil und überhaupt kann man damit viel besser die Welt beschreiben."
Ja, man kann damit wunderbar die Welt beschreiben und modellieren. Damit wirbt zumindest jedes mir bekannte OOP-Buch.
Gerade, um den Leser für Vererbung zu begeistern, werden wirklich immer diese trivialen Beispiele, wie z.B. die Tierklassen, Autoklassen, Baumklassen, etc. aufgeführt.
Aber ganz ehrlich: Derartigen trivialen Nonsens habe ich bisher noch nie in meinen Softwareprojekten vorgefunden. In der Software-Realität gibt es eher "Tierautos mit Blättern dran". Das liegt ganz einfach daran, dass man viele Dinge im Businessproblem nicht so einfach klassifizieren kann, wie es einen die OOP-Autoren gerne schmackhaft machen wollen. Objekte müssen miteinander interagieren und Daten austauschen, denn nur darum geht es letztlich wieder: um die Datenverarbeitung.

Aber auch dafür hat sich die OOP-Gemeinde einige Konstrukte ausgedacht, die sich Entwurfsmuster "schimpfen". Überhaupt wurde der Trend eingeleitet, man solle nicht mehr "ableiten" und "vererben", sondern "komponieren". Dies sei flexibler, sagt man. (Was ich auch nicht bestreiten will.)

Doch sehe ich die Entwurfsmuster eher als Krücke. Nach dem Motto: Not macht erfinderisch.
Und, dass diese Entwurfsmuster nur ein Notnagel sein können, sieht man z.B. am "Visitor Pattern" oder dem "State Pattern". Die mögen ja wunderbar funktionieren, aber den Quellcode darf man hinterher nicht verstehen, geschweige denn debuggen wollen.

Tja, das hat alles nicht mehr den Eindruck, als wolle man Daten verarbeiten, sondern als wolle man geschickt mit einem Netzwerk aus Objekten um die Daten herumtanzen, ohne diese direkt zu berühren.

Es denkt doch keiner mehr an den Prozessor und an den Speicher.

Die OOP widerspricht immer noch der Arbeitsweise der gegenwärtigen Rechner. Denn im Rechner sind noch immer die Daten vom Code getrennt. Der Prozessor kennt keine Klassen, Objekte und erst recht keine Entwurfsmuster. Das wäre ja alles kein Problem, wenn die Zugriffszeiten auf den Arbeitsspeicher nicht den Prozessor unnötig ausbremsen würden.

Ganz ehrlich: Ich würde kein Prozessor sein wollen, der ein OO Programm bewältigen muss. ;-)

Warum versucht man also die Welt - das Businessproblem - in ein OO-Schema zu pressen, welches der Compiler wieder halbwegs entfrickeln (Code von Daten trennen) muss, damit es der Prozessor dann mehr schlecht als optimal lösen "darf"?

Und wie man dem Beitrag von Ralf entnehmen kann, geben die OOP-Gurus zu verstehen, dass die Mehrheit nach so vielen Jahren noch immer nicht richtig OO programmieren kann.

Ja, da muss man wirklich fragen, wessen Problem das ist? Ich brauche diese "Religion" OOP nicht wirklich, um meine Business-Probleme auf Arbeit zu lösen. Das habe ich jedoch leider eher spät gemerkt, weil ich auch auf den OOP-Zug aufgesprungen bin, der sehr gut beworben wurde. Hinterher fand ich die Codebasis aber trotzdem nicht schön. Vielmehr war alles so aufgeblasen und ich verlor den Überblick.

Ich frage mich aber wirklich, warum die OOP-Gurus so hartnäckig an der Objektorientierung festhalten. Geht es dabei nur um das Modellieren der Welt?
Wäre es nicht sinnvoller, ein Paradigma zu wählen, welches dem Programmierer gleichermaßen entgegen kommt, wie der Hardware? Wenn man nicht mehr versuchen würde, die Business-Probleme 1:1 mit Objekten zu beschreiben, sondern die Probleme grundlegend abstrahieren würde, sodass diese einfacher zu fassen und für die Hardware optimal beherrschbar sind?

Vielleicht hat man damals die Idee - den Code von den Daten getrennt zu halten - zu schnell verworfen. Denn gerade die Rechnerarchitektur zeigt uns doch, wie die Daten am besten verarbeitet werden können. Und solange sich die Architektur nicht ändert, ist es IMHO keine gute Idee, weiterhin die Daten mit dem Code zu mischen.

Ich bin zumindest gespannt, wohin die Reise gehen wird. Spätestens mit den ersten Quantenrechnern dürfte sich noch so Einiges ändern. ;-)