WikiDer > Funktionale Programmierung

In dem Informatik ist funktionale Programmierung ein Programmierstil und ein Programmierparadigma. Hiermit die Informationsverarbeitung in Form von Funktionen ausgedrückt, ähnlich wie MathematikerFunktionen. Mit diesem Stil (vorzugsweise alle) Änderungen von Variablen außerhalb der Funktion (genannt "Nebenwirkungen") und sparen Programmstatus und veränderbare Variablen zu vermeiden. Variablen für ua Akkumulator, Zähler, Global- oder Kontrollvariable kommen nicht in Frage.
Beispiele für mehr oder weniger rein Programmiersprachen für funktionale Programmierung sein APL, Erlang, F♯, Haskell, lispeln, ML, Reichweite und planen, von denen Haskell die reinste ist.

Ein höheres Berechnungskonzept

Imperative Programmierung

EIN Computer führt eine Berechnung gemäß einem vorbestimmten Muster von Schritten durch; Jeder Schritt in diesem Muster ist eine kleine, einfache Teilrechnung. Eine Berechnung als eine Reihe kleiner Schritte zu betrachten, ist ein mögliches Modell zur Durchführung einer Berechnung.

Funktionale Programmierung

Ein weiteres Modell – das auf eine höhere Ebene des Denkens, Verstehens und Rechnens fokussiert – ist das Modell der Lambda-Kalkül von Alonzo-Kirche und Stephen Cole Kleene. In diesem Modell erfolgt eine Berechnung durch Anwendung Funktionen zu Argumenten: "wenn ich funktioniere ${displaystyle {mathfrak {f}}}$ auf Argumente anwenden ${Anzeigestil a}$ bekomme ich als antwort ${displaystyle b}$". Wie die Anwendung von ${displaystyle {mathfrak {f}}}$ auf ${Anzeigestil a}$ genau zu ${displaystyle b}$ führt, egal – darum geht es ${displaystyle b}$ die Antwort ist. In rein funktionalen Programmiersprachen können Funktionen nicht so genannt werden Nebenwirkungen Ursache. Dies sind Effekte, die mehr als das Ergebnis der Funktion betreffen, z. B. das Ändern einer globalen Variablen. Das Ändern einer solchen Variablen wird als destruktive Neuzuweisung bezeichnet.

Abstraktion und Anwendung

Die beiden Hauptmechanismen innerhalb der Lambda-Kalkül zu einer Berechnung zu gelangen sind die Abstraktion und die Anwendung.

Für die Programmierung besteht Abstraktion darin, eine Funktion zu definieren: "Für jeden Term A mit den Eigenschaften, die zu A gehören, gibt es eine Antwort B, die so und so davon abhängt, was genau A ist". Zum Beispiel die Funktion

${displaystyle {mathfrak {f}}:mathbb {R} mapto mathbb {R} }$

${displaystyle {mathfrak {f}}(x)=x^{2}-2x 3}$

Diese Funktion ${displaystyle {mathfrak {f}}}$ definiert eine Verbindung zwischen zwei Werten aus dem Set ${displaystyle mathbb {R} }$. Diese Verbindung kann auf jedes Element von angewendet werden ${displaystyle mathbb {R} }$ und liefert dann auch noch ein weiteres, zugehöriges Element von ${displaystyle mathbb {R} }$ auf. Wie das passiert und was a Computer (oder der Mensch) muss sich die Mühe machen herauszufinden, dass das zugehörige Element keine Rolle spielt, wichtig ist, dass die Verbindung existiert und angewendet werden kann.

Neben der Abstraktion gibt es auch die Anwendung. Für Programmierzwecke läuft dies darauf hinaus, eine Funktion auf ein Argument anzuwenden. Beispielsweise:

${displaystyle {mathfrak {f}}(7)mapsto 38}$

Das Anwenden einer Funktion auf ein bestimmtes Argument, das die allgemeine Beschreibung der Argumente für diese Funktion erfüllt, gibt eine Antwort zurück. Wie und warum spielt keine Rolle, es wird nur die Antwort produziert.

Referenzielle Transparenz

Viele Features in funktionalen Programmiersprachen sind referenziell transparent. Dies bedeutet, dass a Ausdruck kann durch seinen Wert ersetzt werden, ohne die Funktionsweise des Programms zu ändern. Ein Beispiel dafür sind Arithmetik Bearbeitungen, wie z 1 1; das kann ersetzt werden durch 2 ohne das Programm zu ändern. Viele mathematische Funktionen sind auch referentiell transparent, wie z Sünde(x) (dieser liefert für eine gegebene X immer der gleiche Wert).

Rekursion

Ein weiterer wichtiger Aspekt der Lambda-Kalkül ist, dass Funktionen in Bezug auf andere Funktionen definiert werden können (zumindest soweit es für die Programmierung in funktionalen Sprachen von Bedeutung ist) – auch in Bezug auf sich selbst. Das bedeutet, dass der Lambda-Kalkül einen enormen Spielraum an Definitionsmöglichkeiten hat. So sehr, dass der Lambda-Kalkül ein Modell für alle berechenbaren Probleme da draußen ist. Funktionale Sprachen können alles berechnen, was berechenbar ist.

Ein Beispiel für eine Definition in Bezug auf Funktionen (insbesondere eine rekursive Definition) ist folgendes:

${displaystyle {mathit {fact}}:mathbb {N} mapto mathbb {N} }$

${displaystyle {mathit {fact}}(n)=leftlbrace { egin{array}{ccl}n=0&ightarrow &1/n>0&ightarrow &n*{mathit {fact}}(n-1)end{array}}ight.}$

Funktionen höherer Ordnung

Ein wichtiges Merkmal einer funktionalen Sprache ist, dass eine Funktion auch eine andere Funktion als Argument annehmen kann. Das wird sein Funktionen höherer Ordnung erwähnt. So existiert in Haskell und andere funktionale Sprachen die Funktion Mappe. Die Funktion Mappe wendet eine weitere Funktion F auf alle Elemente einer Liste L an. Die Argumente der Funktion Mappe sind also die Funktion F und die Liste L.

Funktionsmodell zu Funktionssprache

Ein solches Berechnungsmodell auf hohem Niveau ist natürlich schön und vor allem einfach, aber es ist nicht direkt auf die Hardware- wie es in der Moderne vorkommt Computers. Funktionale Sprachen sind daher stark auf fortgeschrittene und vor allem komplexe Sprachen angewiesen Compiler und Dolmetscher die die Übersetzung von der Funktionsanwendung in das Schritt-für-Schritt-Modell der Prozessor.

Diese Übersetzung ist viel größer als bei der zwingende Sprachen, was sich in der (oft begrenzten) Geschwindigkeit widerspiegelte, mit der viele funktionale Programme ausgeführt wurden (dies war sicherlich in den ersten Generationen von Entwicklungsumgebungen für diese Sprachen ein erhebliches Problem). Dies spiegelt sich in der Popularität funktionaler Sprachen außerhalb der Forschungsumgebungen von . wider Universitäten.

Heutzutage nimmt die Popularität funktionaler Sprachen rasant zu. Sie sind wegen der Abwesenheit von Nebenwirkungen viel besser als zwingende berechnungsfähige Sprachen parallelisiert ausgetragen werden. Die Berechnung erfolgt dann durch mehrere Prozessoren von einem Computer gleichzeitig oder sogar von mehreren Computern gleichzeitig. Seit etwa 2005 sind Multiprozessor-Rechner stark im Preis gefallen und das Interesse an funktionaler Programmierung ist gestiegen.

Unterscheiden Sie sich von anderen Arten von Programmiersprachen

Der größte auffällige Unterschied besteht zweifellos zwischen den funktionalen Programmiersprachen und den zwingende Sprachen. Verwenden funktionale Sprachen das High-Level-Modell der Lambda-Kalkül, sind die imperativen Sprachen vollständig auf das Rechenmodell des zugrunde liegenden Prozessors aufgepfropft: Schritt für kleinen Schritt, jeder Schritt wird buchstäblich als einzelner Befehl in das imperative Programm aufgenommen. Während eine Funktion in einer funktionalen Sprache ein Programm an sich ist, ist in einer imperativen Sprache jede Funktion in diese kleinen, separaten Schritte unterteilt. Ein weiterer großer Unterschied besteht darin, dass es in den rein funktionalen Sprachen keine explizite Variablendeklaration oder Speicherreservierung gibt. Dies gewährleistet einen transparenten, kompakten Code. Dies macht es auch leicht, über diesen Code nachzudenken und beispielsweise die Richtigkeit nachzuweisen. In der Tat, weil Sie genau wissen, wann einem Wert etwas passiert (etwas, das in der zwingenden Welt aufgrund der Möglichkeit von possibility Nebenwirkungen) können Sie automatisch herausfinden, wann bestimmte Funktionen parallel ausgeführt werden können.

Außerdem unterscheiden sich die funktionalen Sprachen von den logische Sprachen. In dieser Sprachkategorie geht es nicht um Funktionen und Funktionsanwendungen, sondern um Beweisobjekte und Prädikatslogik. Die logischen und funktionalen Sprachen sind sich jedoch insofern sehr ähnlich, als sie eine Abstraktion auf hoher Ebene als Modell annehmen und zusammen diametral der zwingende Sprachen; aus diesem Grund funktional und logisch Sprachen zusammen auch genannt die deklaratives Paradigma erwähnt.

Schließlich herrscht in all dem viel Uneinigkeit über die Position objektorientierter Programmiersprachen; diese Sprachen teilen eine Berechnung in mehrere Teile auf, wobei jeder Teil in der Verantwortung eines in sich geschlossenen Programmobjekts liegt. Diese Objekte selbst werden jedoch intern auf der Grundlage eines (oder mehrerer) der oben genannten Modelle erstellt, sodass die Frage bleibt, ob dieses Modell als vollständig separates Modell angesehen werden kann.

Externe Links

• (und) Achmechet, Slava, defmacro - Funktionale Programmierung für den Rest von uns (19. Juni 2006). Zugegriffen unter 24. Februar 2013.
• (und) Dijkstra, Edsger Wybe, Wie die Informatik einen neuen mathematischen Stil geschaffen hat (4. März 1990). Zugegriffen unter 4. Februar 2014.
• (und) Ford, Neal, Funktionelles Denken (13. Januar 2012). Zugegriffen unter 22. Februar 2013. Videopräsentation über funktionale Programmierung in Java

IBM Functional Thinking-Serie

(und) Ford, Neal, Funktionales Denken: Funktional denken, Teil 1. IBM EntwicklerWorks (3. März 2011). Zugegriffen unter 22. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktional denken, Teil 2. IBM EntwicklerWorks (31. Mai 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktional denken, Teil 3. IBM EntwicklerWorks (28. Juni 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Unveränderlichkeit. IBM EntwicklerWorks (27. Juli 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Kopplung und Komposition, Teil 1. IBM EntwicklerWorks (30. August 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Kopplung und Komposition, Teil 2. IBM EntwicklerWorks (4. Oktober 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Features in Groovy, Teil 1. IBM EntwicklerWorks (12. November 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Features in Groovy, Teil 2. IBM EntwicklerWorks (20. Dezember 2011). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Features in Groovy, Teil 3. IBM EntwicklerWorks (31. Januar 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Designmuster, Teil 1. IBM EntwicklerWorks (6. März 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Designmuster, Teil 2. IBM EntwicklerWorks (3. April 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Designmuster, Teil 3. IBM EntwicklerWorks (15. Mai 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Funktionale Fehlerbehandlung mit Entweder und Option. IBM EntwicklerWorks (12. Juni 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Entweder Bäume und Musterabgleich. IBM EntwicklerWorks (10. Juli 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Versand neu denken. IBM EntwicklerWorks (21. August 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Tonnen von Transformationen. IBM EntwicklerWorks (25. September 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Transformationen und Optimierungen. IBM EntwicklerWorks (16. Oktober 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Faulheit, Teil 1. IBM EntwicklerWorks (20.11.2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Faulheit, Teil 2. IBM EntwicklerWorks (19. Dezember 2012). Zugegriffen unter 24. Februar 2013.

(und) Ford, Neal, Funktionales Denken: Warum funktionale Programmierung auf dem Vormarsch ist. IBM EntwicklerWorks (29. Januar 2013). Zugegriffen unter 22. Februar 2013.