Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:
Heute, am 1. April 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:
Funktional oder objektorientiert?
So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:
Nicht-objektorientierten Sprachen wurde in den vergangenen Jahren eine deutlich höhere Aufmerksamkeit als davor zuteil: JavaScript als dynamische Sprache hat im Rahmen von AJAX daran ebenso Anteil gehabt wie F# als funktionale Sprache und Ableger von OCaml und ML.
Doch auch außerhalb von .NET haben beispielsweise Ruby im Rahmen von Rails und Python – jeweils als dynamische Sprachen – zunehmende Verbreitung erfahren. Inzwischen stehen mit IronRuby und IronPython auch entsprechende .NET-Vertreter dieser Sprachen auf Basis der Dynamic Language Runtime zur Verfügung.
Darüberhinaus führt der Tiobe-Index statische Sprache nur noch bei rund 60 Prozent, und auch der Anteil der objektorientierten Sprachen ist im Vergleich zum Vorjahr um knapp drei Prozent gefallen.
Auf den ersten Blick scheinen funktionale Sprachen also kräftig auf dem Vormarsch zu sein, ebenso wie dynamische Sprachen. Ist es also ratsam, sich mit diesen Sprachen auseinanderzusetzen?
Bevor man diese Frage beantworten kann, soll noch einmal deutlich darauf hingewiesen werden, dass funktionale Sprachen ein anderes Paradigma verfolgen als objektorientierte Sprachen – nämlich das funktionale an Stelle des objektorientierten Paradigmas – , dynamische Sprachen aber nicht per se: Während sich das funktionale von funktionalen Sprachen auf die Art der Entwicklung bezieht, weisen dynamische Sprachen einfach nur ein flexibles Typsystem auf.
Das bedeutet, dass eine dynamische Sprache sehr wohl objektorientiert sein kann, aber nicht muss, und dass eine funktionale Sprache nicht zwingend dynamisch sein muss – aber kann.
Über die Bedeutung von dynamischen Sprachen haben Peter und ich uns schon in unserem ersten Streitgespräch unter dem Titel Dynamic Language Runtime: .NET, quo vadis? Gedanken gemacht – funktionale Sprachen bislang allerdings noch nicht. Spätestens seit F# als neue Sprache in Visual Studio 2010 enthalten ist, wird es aber Zeit, sich die Frage zu stellen, inwiefern sich die Beschäftigung mit funktionalen Sprachen lohnt.
Liest man die Definition von funktionaler Programmierung, die in Wikipedia gegeben wird, ist die Nähe zur Mathematik unübersehbar. Auch die Sprachkonstrukte von F#, wie beispielsweise explizite Unterstützung von Rekursion, die Unterstützung von Funktionen höherer Ordnung und die Fähigkeiten zur Listenverarbeitung und –manipulation, legen nahe, dass der Fokus von F# auf der Verarbeitung von Datenstrukturen liegt.
Da für funktionale Sprachen die Turing-Vollständigkeit bewiesen wurde, ist klar, dass sich jedes programmatisch lösbare Problem auch in einer funktionalen Sprache lösen lässt – die Frage ist nur, wie elegant: Natürlich können grafische Oberflächen auch in funktionalen Sprachen entwickelt werden – wirklich Spaß macht das aber nicht. Hierbei merkt man allzu häufig, dass F# andere Schwerpunkte setzt.
So gesehen stellt F# also eine hochspezialisierte und äußerst gut geeignete Sprache für algorithmische Probleme dar – als Allzwecksprache für den tagtäglichen Einsatz eignet sie sich jedoch weniger. Andere funktionale Sprache verhalten sich in dieser Eigenschaft ähnlich wie F#.
Ein interessanter Aspekt ist zudem, dass das objektorientierte Paradigma mehr bietet als nur eine Art, wie Code geschrieben wird. Die Objektorientierung gibt von Haus aus nämlich außerdem bereits ein hierarchisches Modell vor, wie Code organisiert wird – in Methoden, Klassen und Namensräume, die auf Grund von Vererbung und Komposition miteinander in Beziehung stehen und durch abstrakte Basisklassen und Schnittstellen mit Kontrakten versehen werden können.
Funktionaler Programmierung fehlt ein solcher Ansatz: Hier ist schlichtweg alles eine Funktion – was auf der einen Seite gerade die Stärke funktionaler Programmierung begründet, auf der anderen Seite aber auch viel mehr Disziplin und die Existenz eines eigenen Ordnungssystems erfordert.
So gesehen kann man mit Fug und Recht behaupten, dass objektorientierte Sprachen für den tagtäglichen Einsatz die geeigneteren Sprachen sind, da sie universeller und besser strukturierend sind. Für algorithmische Spezialaufgaben mag es aber durchaus lohnenswert sein, eine funktionale Sprache zur Problemlösung in Betracht zu ziehen.
Insofern fällt mein Fazit daher ähnlich wie zu den dynamischen Sprachen aus: Die Koexistenz beider Welten dürfte .NET insgesamt voranbringen, da es besser möglich wird, das am besten geeignete Werkzeug für die jeweilige Aufgabe zu wählen, ohne eine ausgereifte Plattform wie .NET verlassen zu müssen.