- „Funktionale Programmierung (FP) ist schwer zu lernen, aber Ihr Code wird dadurch weniger unangenehme Überraschungen erzeugen“
- In FP gilt: „less is more“
- Das Null-Reference-Problem wird (mit Maybe/Option) gelöst
- FP hat eine steile Lernkurve
- Die Zukunft von FP
- Wenn man mit weniger Entwicklern mehr Software entwickeln will, muss man jedes verfügbare Werkzeug nutzen — FP ist das Ticket dafür
- Für uns, weniger glanzvolle Unternehmen, ist es schwierig, Entwickler einzustellen. Mit einer FP-Codebasis wird es jedoch möglich, Top-Tier-Entwickler zu gewinnen, die genau dort arbeiten wollen
- Durch die Einführung von FP verbessern sich Qualität und Robustheit, und es wird weniger Zeit für Bugs aufgewendet, die in FP gar nicht erst entstehen
- Dass Funktionen von FP zunehmend in Mainstream-Sprachen auftauchen, zeigt, dass sich die Softwarebranche auf einen Paradigmenwechsel vorbereitet
- Bis die Branche vollständig umgestellt hat, ist noch viel Arbeit nötig, aber wegen der klaren Vorteile besteht kein Zweifel daran, wohin die Reise geht
13 Kommentare
Es stimmt wohl, dass die Lernkurve steil ist. Auch in den Kommentaren gibt es Inhalte, die zeigen, dass funktionale Programmierung wirklich nicht vollständig verstanden wurde. Natürlich gibt es auch Kommentare von Leuten, die sich gut damit auskennen. Funktionale Programmierung ist schwierig. Ich lerne selbst immer noch dazu. seufz
Erst wenn es Fälle gibt, in denen eine Programmiersprache nicht länger eine Frage der Vorlieben des Entwicklungsteams ist, sondern eine Frage des Überlebens eines Unternehmens, können wir wohl wieder über die Notwendigkeit von FP sprechen.
Ich fasse es zusammen. Beim Speicher-Management und einigen Algorithmen übertrifft es die objektorientierte Programmierung noch nicht. Je nach Situation und Kosten sollte man es angemessen einsetzen.
Hm … ich kann der Behauptung nicht zustimmen, dass die Lernkurve steil sei.
Zunächst einmal ist es einfach leicht, man macht weniger Fehler, und dadurch steigt die Produktivität.
Das reicht doch, oder?
Es ist schwer, menschliches Denken und Arbeiten so vollständig zu formalisieren wie in rein funktionalen Programmiersprachen. Wenn man sich Dinge wie
free monadanschaut, wirkt es so, als wäre selbstrxjsungefähr die äußerste akzeptable Grenze.Auch bei FP kommt irgendwann der Punkt, an dem der Aufwand den Nutzen übersteigt.
Selbst die bisherigen FP-Effekte trennen im Grunde nur Daten und Methoden,
und schon daran, dass
Optionalviel seltener genutzt wird als erwartet, sieht man, dass Typabstraktion eine unnötige Abstraktion ist (weil das Anpassen der Typen die Produktivität zu stark frisst).Wenn es nicht in die Richtung geht, Daten und Operationen wie bei Closures noch stärker zu abstrahieren, gibt es Grenzen dabei, bestehende Sprachen dafür zu nutzen.
Unveränderlichkeit ist nur ein häufig verwendetes Werkzeug im Paradigma der funktionalen Programmierung.
Soweit ich weiß, ist das Paradigma der funktionalen Programmierung ein Programmierparadigma, das darauf abzielt, „Seiteneffekte“ (Side effects) so weit wie möglich zu kontrollieren.
Wenn man versucht, Seiteneffekte zu kontrollieren, legt man naturgemäß Wert auf Dinge wie Referenztransparenz, Unveränderlichkeit und reine Funktionen.
In diesem Sinne halte ich es für wünschenswert, auch dann ein klares Bewusstsein für die Seiteneffekte der von einem selbst geschriebenen Funktionen oder Methoden zu haben und sie angemessen kontrollieren zu können, wenn man nicht unbedingt eine funktionale Programmiersprache verwendet. Das hat viele Vorteile, etwa die Verringerung von Code Smells im Code und das einfachere Schreiben von Unit-Tests.
Dazu gibt es auch ausführlichere übersetzte Artikel.
Aus dieser Perspektive gibt es als Buch, das sich auf Refactoring zur Minimierung von Seiteneffekten konzentriert, Funktionales Coding, das leicht verständlich ist: Komplexe Software mit einfachem Code zähmen. Da es eher aus einer praktischen und anwendungsnahen als aus einer theoretischen Perspektive an das Thema herangeht, ist es für alle, die guten Code schreiben möchten, absolut lesens- und lernenswert. Ich finde, schon wenn man nach der Lektüre beim Schreiben von Code deutlich stärker als zuvor auf Seiteneffekte achtet, ist das Buch seinen Preis mehr als wert.
Danke, ich werde danach suchen und es lesen.
Ah! Es gibt also schon eine übersetzte Ausgabe! Die muss ich lesen!
Danke für die Buchempfehlung!! Ich werde es mir sofort kaufen und lesen!
Das Buch ist wirklich großartig!
Aus der Perspektive des Refactorings betrachtet ist es auch wirklich angenehm zu lesen.
Natürlich denke ich auch, dass funktionale Programmierung ein guter Ansatz ist, aber es scheint nur wenige zu geben, die ihre Vorteile wirklich überzeugend vermitteln. Wenn man einfach nur sagt, dass sie gut ist, kommt das ja nicht wirklich an?
Im Folgenden meine persönliche Meinung: Da im Grunde alle modernen Programme auf einer Turing-Maschine basieren, lassen sie sich abstrakt grob in Funktionen und Daten einteilen, und deshalb halte ich auch prozedurale Programmierung im Ursprung für funktional. Was also der echte Vorteil funktionaler Programmierung gegenüber prozeduraler ist, ist meiner Ansicht nach ganz einfach: keine globalen oder global ähnlichen Variablen zu verwenden. Durch diesen Vorteil werden sowohl die „Isolation zwischen Funktionen“ als auch „Multithread-Computing“ effizienter.
Aber ob man diesen Vorteil nur mit funktionaler Programmierung erreichen kann? Nein. Auch in prozeduralen Sprachen wird über das Konzept der dependency injection die Isolation auf Klassen- und Funktionsebene empfohlen (moderne Frameworks übernehmen das bereits standardmäßig), und in Rust wurden auf Sprachebene Einschränkungen geschaffen, damit sich komfortables nebenläufiges Rechnen anstreben lässt.
Zusammengefasst sind funktionale Sprachen gute Sprachen und eine gute Methodik, aber ich denke, sie sind im „evolutionären Sinne“ nicht überlegen, sondern eher wie Go oder Rust: Sprachen, die sich bemühen, potenzielle Fehler bereits auf Sprachebene auszuschließen, dabei aber schwer zu verwenden sind.
Meinen Sie, dass auch in prozeduralen Sprachen so etwas wie Funktionskomposition möglich ist?
Wenn man die Definition von „Funktionskomposition“ eng fasst, könnte man meinen, dass sie nur in funktionalen Sprachen möglich ist. Aber wenn man genauer darüber nachdenkt, läuft die Ausführung letztlich ohnehin auf Maschinensprache oder Assembler, also auf prozeduralen Sprachen. Es geht also nicht um „möglich oder unmöglich“, sondern um die „Schwerpunkte, Vorlieben und Philosophie einer Sprache“. Wenn man die Definition von „Funktionskomposition“ nicht eng als „bestimmtes Feature einer bestimmten Sprache“, sondern weiter als „Komposition zwischen logischen Funktionen“ versteht, ist das ohne Weiteres möglich. Und die Vorteile funktionaler Sprachen gibt es ganz klar, weshalb Dinge wie
rxjsodersparkdiese aktiv aufgegriffen haben.Wie wir alle im Informatikstudium gelernt haben, liefern die folgenden Beispiele dasselbe Ergebnis; unterschiedlich ist nur die Ausdrucksform. Und Präfixnotation wird oft als funktional bezeichnet.
Präfixnotation: + 1 1
Infixnotation: 1 + 1
Postfixnotation: 1 1 +