Funktionale Programmierung ist nicht die Lösung

Hartmut Schlosser

Während das objekt-orientierte Programmierparadigma die letzten 15 Jahre dominierte, ist spätestens seit dem Erfolg von Scala und Clojure auf der JVM die funktionale Programmierung wieder salonfähig geworden. Manche Vertreter der Szene sehen in ihr die Lösung für die Herausforderungen der nebenläufigen Programmierung. ThoughtWorks-Experte Neal Ford propagiert das Modell einer Programmierpyramide, in der die unteren Architekturschichten funktional (d.h. auch stateless), die mittleren imperativ und die oberen mithilfe von DSLs programmiert werden.

Und nachdem nun auch Java 8 mit seinen Lambda-Ausdrücken um funktionale Aspekte ergänzt werden soll, scheint jeder Java-Entwickler irgendwie aufgefordert, zumindest teilweise auch funktional zu programmieren. Schließlich will man ja „in“ sein: „Funktional ist besser“, nicht wahr?

Die Antwort darauf: Nein – dem ist nicht so!

Auf seinem Blog beschreibt John A de Goes die Gefahr, das funktionale Paradigma zu einer Art Religion zu erheben. Funktional werde allzu oft gleichgesetzt mit „reinem Code ohne Seiteneffekte“ – eine Meinung, die Goes demontiert, indem er eine überaus geschwätzige und schwer lesbare Version des Quick-Sort-Algorithmus funktional (in Haskell) implementiert.

Funktional an sich ist also noch kein Wert – es ist ein reines Mittel, um die Ziele der Software-Entwicklung zu erreichen. Diese lauten Goes zufolge:

  • Schreibe Code, der zuverlässig ist, selbst in Teilen der Applikation, die nicht oft genutzt werden.
  • Schreibe Code, der einfach von anderen verstanden werden kann (denn andere werden ihn weiterentwickeln bzw. warten müssen).
  • Schreibe Code, den man leicht an geänderte Anforderungen anpassen kann. Denn Anforderungen bleiben nie gleich.

Nun, vielleicht spricht Goes hier eine Trivialität aus: Funktionale Programmierung hilft nicht notwendigerweise dabei, diese Werte umzusetzen:

Stated differently, whether or not something’s “bad” is independent of whether or not it’s “purely functional”. “Purely functional” is neither a necessary nor sufficient condition for good code.

Befreiend kann diese Erkenntnis aber durchaus sein, um nicht reflektionslos dem aktuellen Hype um die funktionale Programmierung anheim zu fallen. Denn auch die Nutzung der Lambda-Ausdrücke in Java 8 will gut dosiert sein – hier sehen Experten nämlich durchaus Gefahrenpotenziale:

Java 8 erhöht die Möglichkeiten, tollen Code zu schreiben, ABER es schafft auch mehr Möglichkeiten, schlechten Code zu schreiben! Wir werden viele, viele Anwendungen sehen, die wunderbar mit Lambdas und den neuen APIs realisiert wurden, leider um jeden Preis. Entwickler nutzen Dinge leider VIEL zu oft, schlicht weil sie gerade hipp, cool oder dergleichen sind.
Joachim Arrasz

Da ich häufig Schulungen für Unternehmen mache, aber auch an der Hochschule in der Programmierausbildung für Studienanfänger eingebunden bin, kann ich mir gut vorstellen, dass nicht alle Entwickler und Studenten sofort mit den durchaus recht komplexen Features von Java 8 zurechtkommen werden.

Aus der sehr einfachen Sprache Java in der Version 1.0 wurde mit inneren Klassen (1.1), Generics (5) und Lambdas (8) – um nur die großen Schritte zu nennen – eine durchaus sehr komplexe Sprache. Je komplexer eine Sprache ist, desto leichter ist es, schlecht lesbare, schlecht wartbare oder schlichtweg fehlerhafte Programme zu schreiben. Etwas, was wir sicher nicht wollen.
Bernd Müller

In unseren Kundenprojekten [haben wir] noch zu oft mit fundamentalen Themen zu kämpfen: beispielsweise die geringe Nutzung von JDK 5 Features – Stichwort Generics. Oder das fehlende Verständnis für fachliche Domainmodellierung, die gerade den Java-EE-Entwicklern abhanden gekommen ist – Stichwort Anemic Domain Model.

Es [gibt] schon heute eine große Anzahl an Java-Entwicklern, die von den Entwicklungen der letzten Jahre abgehängt wurden. Leider.
Jens Schumann

Was wir benötigen, ist möglicherweise ein Set an Best Practices oder Programmier-Pattern, die aufzeigen, in welchen Situationen die funktionale anderen Programmierweisen überlegen ist. Die Java-Welt steht hier größtenteils vor einem Lernprozess, der gerade erst begonnen hat.

Richtig ist sicherlich, dass es immer wichtiger wird, sein Repertoir als kompetenter Entwickler um die funktionale Programmierung zu ergänzen. Befreien kann uns dies allerdings nicht von der Frage, welches Mittel am besten für welche Zwecke eingesetzt werden sollte. Oder wie Boes es ausdrückt:

We can’t stop at functional. We can’t pat ourselves on the back just because we wrote “purely functional” code. We can’t ignore “non-functional” programming techniques, including whole other paradigms like logic programming and reactive programming.

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. SEO und KPIs isst er zum Frühstück. Satt machen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: