Warum bringt Funktionale Programmierung sehr viel mehr Sicherheit?
Aus der Bool'schen Algebra und Prädikatenlogik ist bekannt, dass man damit nicht nur beliebige Sachverhalte in der Welt beschreiben, sondern komplexe Ausdrücke auch durch einen mathematischen Formalismus vereinfachen kann. Bedingung dafür aber ist, dass die Funktionen 'pure', also wechselwirkungsfrei, 'side effect free' sind.
Hierzu ein Beispiel. Ich definiere:
f(t): Programmierer hat Funktionale Programmierung am Zeitpunkt t verstanden.
h(t): Programmierer hat zum Zeitpunkt t Hunger.
d(t): Zeitpunkt ist am Tag.
n(t): Zeitpunkt ist nachts.
t₁ < t₂: Zeitpunkt t₁ trat irgendwann vor t₂ ein.
Interessanterweise kann man nur damit - also mit nur ganz wenigen, prädikatenlogischen Formeln - erstaunliche Sachverhalte des täglichen Lebens damit ausdrücken:
1. Immer wenn der Programmierer Hunger hat, versteht er nichts von Funktionaler Programmierung.
2. Es kommt vor, dass der Programmierer nachts Hunger hat.
3. Es gibt einen erleuchtenden Moment, ab dem der Programmierer Funktionale Programmierung für immer verstehen wird.
4. Zwischen zwei bestimmten Zeitpunkten hat der Programmierer ein Funktionales Blackout (versteht also nix mehr), aber vorher und auch hinterher versteht er schon.
Hier nun die Übersetzung obiger Phrasen in die 'mathematische Sprache':
∀t: h(t) => ¬f(t) (Für alle Zeiten gilt: Wenn Hunger, dann nix funktional!)
∃t: n(t) ^ h(t) (Es existiert eine Zeit t, wo "Nacht und Hunger" zusammenfallen!)
∃t₀: ?t : (t₀ < t) => f(t)
∃t₀: ∃t₁: ∀t: (t₀ < t) ^ (t < t₁) <=> ¬f(t)
Funktionale Programmiersprachen enthalten eine ganze Reihe von Reduktionsmechanismen, entlang des griechischen Alphabets bezeichnet. Die Einfachste ist die sogenannte "β reduction". Sie wird, wie alle anderen Reduktionen auch, mit dem λ Operator (oft auch als "\" geschrieben) angewendet und beschreibt schlicht das von der Mathematik her bekannte "Einsetzen" eines Wertes in eine Formel:
(λx -> 2*x*x + y)
λx definiert hier eine anonyme Funktion, die allerding zwei Platzhalter (x und y) für 2 Werte zum Einsetzen bereit hält, die - wegen 'pure' der Reinheit und Kompossibilität (math. Zusammensetzbarkeit) - nacheinander übergeben werden müssen. Das bezeichnet man als "Currying". Wir übergeben als erstes mal die 7:
(λx -> 2*x*x + y)(7)
Mit dem Resultat:
2*7*7 + y
Hoppla, das ist aber nicht das Endergebnis, sondern wieder eine Funktion, die ich weiter reduzieren kann:
(λy -> 2*7*7 + y)(2)
mit dem erwarteten Endergebnis 100. Der λ Calculus ist zur Ruhe gekommen und hat seinen finalen Status erreicht. Vgl. der 'fleissige Biber':
https://de.wikipedia.org/wiki/Fleißiger_Biber
Man kann aber die beiden Schritte aber auch zusammenfassen:
(λx.λy -> 2*x*x + y)(7)(2)
Das λ-Kalkül ist also ein riesiger Legobaukasten, aus dem man mit wohldefinierten Bausteinen - den wohlbekannten, gut untersuchten Gesetzen und Formalismen der Mathematik, Prädikatenlogik und Bool'schen Algebra folgend - besonders in großen Teams - hoch komplexe Programme in nur kurzer Zeit bauen kann. Alles ist additiv im mathematischen Sinne, alles folgt 'generischen Regeln'. Es gibt in Haskell eine ganze Reihe von 'Reductions', die alle - auf magische Weise - miteinander kombinierbar sind. Siehe Quellcode des GHC Compilers.
Das bezeichnet man als 'Orthogonalität': Alles ist mit allem kombinierbar. Voraussetzung allerdings ist, dass sich alle daran halten und nur reine, also 'pure functions' verwenden. Zudem laufen die so entstandenen Programme zumeist beim ersten Anlauf bereits - fehlerfrei.
Eine - vielleicht noch sehr viel wichtigere - Eigenschaft angesichts des Cloud - Zeitalters, in dem wir uns befinden:
Die Programme sind mathematisch/formal verifizierbar. was bei anderen Programmiersprachen (imperativ / prozedural / objektorientiert) wegen der 'Side effects' prinzipiell unmöglich ist.
Was für Überraschungen Interpreter allgemein so bereit halten, hierzu das berühmte, sehr lustige Video 'WAT!" von Gary Bernhardt:
https://www.destroyallsoftware.com/talks/wat
Ein einziger Schrotthaufen! Alles außerhalb funktionaler Programmierung kann man getrost als 'unproduktiven und extrem fehleranfälligen Müll' bezeichnen.
Pure Zeitverschwendung, weil man sich zu 90% in der Fehlersuche befindet, Produktivität -> Null!
Meine Empfehlungen:
https://elm-lang.org/docs/syntax
https://jordanmartinez.github.io/purescript-jordans-reference-site/
https://haskell-miso.org/
Have fun!