Diskussion:Funktionale Programmierung

message: Speziell an funktionalen Sprachen ist unter anderem, dass hier lokale Funktionen definiert werden können, wie dies in imperativen Sprachen mit lokalen Variablen möglich ist.
: ist falsch, zwar in FORTRAN geht es nicht, aber in den Jahrzehnten danach ist es doch ziemlich allgemein möglich geworden Ptrs 00:14, 26. Apr 2003 (CEST)
replies: text: Sowohl Pascal (im Unterschied zu C) als auch Python unterstützen lokale Funktionen; beides sind imperative Sprachen. Ich glaube kaum, daß man so weit gehen kann, Pascal auch als funktionale Sprache zu bezeichnen, oder? --Tobias 18:43, 12. Jun. 2009 (CEST)

text: Ich bin auch der Meinung, dass eine Charakterisierende Eigenschaften funktionaler Programmiersprachen die Tatsache ist, dass Funktionen Werte erster Ordnung sind (d.h. functions are first class values). Diese lassen sich meist auch in Form von Lambda Ausdrücken überall im Code (um genau zu sein, überall, wo Ausdrücke stehen können) definieren (und haben dann eventl. keinen Namen). Diese lokalen Funktionen haben dann die Möglichkeit, auf ihren statischen Kontext (d.h. die Varialben, die an der Stelle, an der die Funktion definiert wurde) zuzugreifen, auch wenn diese Funktionen dann z.B. mithilfe von Funktionsparametern an ganz andere Stelle des Programm ausgeführt werden. Diese Eigenschaft, dass die Funktionen zusammen mit Ihren Variablen an andere Funktionen übergeben werden, ist sehr zentral bei der Funktionalen Programmierung. Dies ist auch eine Ursache dafür, dass den Sprachen vorgeworfen wird, sie seien langsam. Denn das Verwalten der Closers ist nicht auf dem Stack möglich, wie bei imperativen Sprachen, sondern muss im Heap geschehen (oder man muss ne statische Analyse machen, wie das der Ocaml Compiler tut (deshalb ist Ocaml auch recht schnell im Vergleich zu anderen funktionalen Sprachen). Denn i.A. müssen die lokalen Variablen ja später noch zur Verfügung stehen). --Phillip 16:27, 28. Mai 2008 (CEST)
replies: text: In Python sind Funktionen First-class citizens (oder Bürger erster Klasse, Werte erster Ordnung, en:first-class objects, first-class values, Funktionen höherer Ordnung/„HOFs“, vollwertige Objekte …; in der deutschen Wikipedia gibt es offenbar leider noch keinen entsprechenden Artikel) und können zur Laufzeit aus dynamisch generiertem Code erzeugt werden. Ist Python also, als imperative Sprache mit funktionalen Elementen – Funktionsobjekte, einfache Lambda-Funktionen, die aus Haskell entlehnte Listennotation –, auch eine funktionale Programmiersprache? --Tobias 18:43 und 20:05, 12. Jun. 2009 (CEST)
thread_title:  Lokale Funktionsdefinitionen 

message: Fehlt hier nicht noch die Programmiersprache des Mathematik-Programms 'Maple'? --Mikroprozessor 20:01, 2. Apr 2005 (CEST)
replies: text: Nein. Die Maple-Programmiersprache hat soweit ich weiß Seiteneffekte und verletzt damit eine wichtige Eigenschaft funktionaler Sprachen, nämlich die Werttreue. --fschoenm 02:02, 3. Apr 2005 (CEST)
thread_title:  Maple 

message: bitte zumindestens erstmal die einleitung verständlich machen.--Archiv 14:51, 15. Nov 2005 (CET)
replies: text:  Volle Zustimmung! Ich möchte dringend nahelegen, die Änderungen vom 4. November rückgängig zu machen. Die neue Einleitung hat kaum mehr Informationen als die alte, ist aber viel unverständlicher und umständlicher geschrieben. Begriffe wie "zuvorderst" und "faßlicher" klingen, als stammte der Text aus einem Lehrbuch der 70er Jahre. -- --Einmaliger 09:45, 18. Nov 2005 (CET)
thread_title:  Überarbeiten 

message: OK, mein erster Wikipedia-Hilfsversuch... ist die Einleitung jetzt besser (ich fand die alte Fassung gar nicht so graesslich, ehrlich gesagt...)? Der Artikel ist immer noch sehr unvollstaendig; waere es stilistisch akzeptabel, mehr Beispiele zu verwenden und diese nicht in einen separaten Absatz einzusperren, oder wuerde das eher in eines der anderen Wiki-Projekte gehoeren?
--Creichen 05:51, 23. Nov 2005 (CET)
replies: text: ich hatte die einleitung bereits bearbeitet... aber nach wie vor sollte sie noch mal geändert werden, da begriffe wie Interpretation, Kompilierung, Normalform, λ-Kalkül, operationale und denotationale Semantik, referentiellen Transparenz den lesefluss stören für leute die sich nur informieren wollen. ich denke in der einleitung sollten keine fachtermini auftauchen und wenn - allgemeinverständlich erklärt werden. ein knappes aussagekräftiges beispiel in den absätzen mit erklärung ist aber immer gut. viel spass in der wikipedia. --Archiv 12:10, 23. Nov 2005 (CET)
thread_title:  Überarbeitung 

message: Das Problem mit dem obigen Beispiel aus der Lazy Evaluation ist im Kern der Unterschied zwischen "call by need" (mit sharing) und "call by name" (ohne sharing). Im imperativen Bereich ist die Unterscheidung wichtig (wg. Seiteneffekten) aber im Funktionalen nimmt man i.A. einfach "call by need" (cf. Peyton Jones, Impl. of Functional Programming Languages, 1987). Grund dafuer ist, dass es sich im Wesentlichen um Graphenreduktion handelt (ist nett in einigen der Clean-Papers erklaert, aber i.A. spricht alle Literatur, die "lambda graphs" erwaehnt, davon).
Macht es Sinn, diese Info in den Artikel nachzuruesten?
--Creichen 06:10, 23. Nov 2005 (CET)
thread_title:  Lazy evaluation 

message: Der Artikel enthält so viele Fach und Fremdwörter, dass man ein halbes Informatikstudium benötigt um ihn zu verstehen, zumindest muss man soviel wissen, dass man schon weiß was Funktionale Programmierung ist. Ich bin zwar eigentlich Skeptisch, wenn „Oma-Kompatibilität” von Artikeln gefordert wird, aber ich finde es schlecht dass der Artikel nicht mal „Programmierer”-Kompatibilität hat.
Ich denke unser Ziel muss sein den Artikel wieder auf ein verständliches Niveau zu bringen. Deshalb hab ich mal die Abgrenzung zur imperativen Programmierung hinzugefügt. Ich bin zwar noch nicht ganz zufrieden mit dem Stück, aber ich glaube solch ein Beispiel macht einiges verständlicher.--Rbb 17:41, 14. Feb 2006 (CET)
thread_title:  Hauptproblem des Artikels 

message: Ich finde den Artikel zu fundamentalistisch. Er geht sehr detailliert auf die Vorstellung von Haskell und Lisp ein, lässt aber Smalltalk außen vor. Aus Smalltalksicht bedeutet funktionale Programmierung: Funktionen dürfen als Parameter übergeben werden und Schleifen werden (syntaktisch) durch fast gleichlautende funktionale Ausdrücke ersetzt. 
:Der Artikel lässt auch Python, PHP, JavaScript und C++ aussen vor, obwohl man hier Sprachbestandteile finden kann, die aus der funktionalen Programmierung stammen und das ist genau richtig! 
:Die Präsentation der Ideen eines Programmierparadigmas sollte an Hand einer Programmiersprache erfolgen, 
:* die speziell für dieses Paradigma designt wurde (möglichst ein reiner Vertreter und kein Vertreter multipler Paradigmen), weil das Paradigma klar erarbeitet werden soll und
:* es sollte eine aktuelle, gängige Programmiersprache sein, wo noch ein wenig Leben bzw. gar Wachstum herrscht (aktuell) und viele Leute damit arbeiten (gängig)! Entweder wird noch dran geforscht oder die Sprache hat eine hohe Relevanz in der Industrie, so dass dort noch Neuentwicklungen stattfinden oder es gibt eine starke Open Source Gemeinde.
:Deshalb wäre Smalltalk bereits kein guter Kandidat für das OOP Paradigma, da es die erste Bedingung erfüllt, aber die zweite schon nicht mehr. Smalltalk für die Illustration funktionaler Programmierung verwenden zu wollen ist Trolling.
::--Smalltalk ist zwar nicht funktional, aber gewiss nicht tot. Bspw. hat kürzlich die Deutsche Bahn DaRT (Fahrzeugverwaltung) u.A. in VisualWorks entwickelt. (anonym 12:50, 2. Juli 2006 (CEST)
replies: text: --Marc van Woerkom 09:52, 13. Jun 2006 (CEST)
replies: text: --Blabla. Und anderes des Trollens zu bezichtigen ist Trollbezeichning. igel+- 10:57, 14. Jun 2006 (CEST)

text: --S.o. Smalltalk hat Seiteneffekte und verletzt damit eine wichtige Eigenschaft funktionaler Sprachen, nämlich die Werttreue. (anonym 12:46, 2. Juli 2006 (CEST)
replies: text: Richtig. Smalltalk kann man imperativ programmieren oder funktionsal, genau wie Perl oder Ruby. Das ist eben nicht die volle Dosis funktional, wie sie Haskell bietet, aber auch funktional. Man MUSS ja keine Seiteneffekte auslösen. (mal von Zugriffen auf die Hardware abgesehen, aber das Problem hat Haskell ja irgendwie auch. Nomaden oder so) igel+- 09:26, 28. Jul 2006 (CEST)
thread_title:  Überarbeiten 

message: Inzwischen habe ich einige Artikel über Objektorientierte Weiterentwicklungen gelesen. Wäre nicht schlecht, wenn dies auch erwähnt würde. 
Zusätzlich fehlt mir persönlich noch ein Hinweis auf den - praktischen - Unterschied von funktionalen Programmiersprachen. z.B. leichter für parallele Ausführungen optimierbar sind, oder der Programmierer damit einen höheren Grad an Parallelität verwalten kann, als in in Prozuduralen/Objektorienten möglich wäre.
(Vorstehender nicht signierter Beitrag stammt von 84.144.236.24 (Diskussion • Beiträge) 00:40, 27. Jun 2006)
:OO-Weiterentwicklungen werden im FPL-Bereich meist als eher überflüssig angesehen. Die besonderen Vorzüge von OO (Kapselung, polymorphe Container) werden durch andere Sprachmittel erreicht (Modularisierung, Closures statt Daten in den Containern).
:Es gibt einige FPLs, für die OO-Erweiterungen existieren, aber das Echo zumindest in comp.lang.functional ist zumeist: "Gibt es, hab ich bisher noch nicht gebraucht."
:D.h. wenn, dann ist das Thema nur einen Nebensatz wert.
:Joachim Durchholz 11:25, 8. Jun. 2007 (CEST)
thread_title:  Hinweis auf Objektorientierte Weiterentwicklungen und "praktische" Parallität 

message: Ich finde es könnten einfachere Beispiele verwendet werden. Wie die obig aufgeführten map und die Fakultät. Die hat man dann meist auch schon gelesen und verstanden.
Die Programmiersprachen SML und Joy mögen zwar nach der reinen Lehre funktional sein; eine große Verbreitung scheinen sie mir aber nicht zu haben. Deshalb habe ich ein Beispiel aus XSLT hinzugefügt, einer Sprache, die zur Transformation von XML nach XHTML im Internet weit verbreitet ist und die ich täglich bei der Arbeit an XML-Transformationen verwende.
Jürgen Regel 17:11, 29. Mär. 2008 (CET)
thread_title:  Beispiele 

message: Eine funktionale Programmiersprache ist eine Programmiersprache, die funktionale Programmierung unterstützt, indem sie Sprachelemente zur Kombination und Transformation von Funktionen anbietet. Hört sich an wie: Der Ball ist rund....-- Kölscher Pitter 15:19, 19. Jun. 2008 (CEST)
thread_title:  Stil 

message: Der logische Ausdruck x = x + 1 \Leftrightarrow 0 = 1 ist nicht falsch sondern wahr. Man sollte den entsprechenden Satz im Artikel dahingehend verändern, dass es nicht zu Missverständnissen kommt.
: Zugegeben etwas unglücklich formuliert. Wenn du aber schon eine neue gute Idee hast, ändere du es doch gleich. Fragen und Ähnliches immer unterschreiben =) Grüße --WissensDürster 12:04, 10. Jan. 2009 (CET)
thread_title:  Hinweis 

message: Die Verständlichkeit der Beispiele könnte vielleicht durch Hervorhebung der Schlüsselwörter verbessert werden (für die funktionalen Sprachen scheint es leider kaum entsprechende Unterstützung zu geben, im Unterschied zu XML, was sich für XSLT verwenden läßt). Ich vermute mal folgende Schlüsselwörter (die dann „händisch“ hervorgehoben werden könnten):
;Haskell
:Floating
;SML
:local, val, in, fun, end
;Joy
:DEFINE, dup, swap
Das Joy-Beispiel ist ohne derartige Unterstützung (und ohne Kenntnis der Sprache, natürlich) ziemlich unverständlich. Könnten sich die Kenner der jweiligen Sprachen mal äußern? Danke! --Tobias 19:13, 12. Jun. 2009 (CEST)
thread_title:  Verständlichkeit der Beispiele 

message: Ich weiß nicht, ob ich der Einzige bin, der hier vergeblich die Antwort auf die Frage gesucht hat, was denn der Zweck des (rein) funktionalen Paradigmas ist; ich bin sicher, es gibt einen.
Aber die bisherigen Beispiele zeigen nur simple Funktionen, mit denen man keinen pascalprogrammierenden Hund hinterm Ofen hervorlockt; das ist schlicht strukturierte Programmierung (und auch Rekursion gibt es vermutlich in so gut wie jeder imperativen Programmiersprache).  In Python könnte ich das Ringflächenbeispiel wie folgt schreiben:
def ringarea(r1, r2):
    from math import pi
    return pi * (r1**2 - r2**2)
... aber es wäre mir nicht im Traum eingefallen, das als Beispiel für Funktionale Programmierung in Python zu sehen.  Auch mit dem Beispiel der Fakultät oder, als Negativbeispiel für besser nicht rekursiv zu lösende Probleme, der Fibonacci-Zahlen, überzeugt man niemanden.  Kann denn niemand ein Beispiel einbringen, das auf überzeugend einfache Weise funktional zu lösen ist? Die Türme von Hanoi sind wohl ein Beispiel für Rekursion; gibt es eins, für das man Funktionsobjekte braucht? --Tobias 16:55, 22. Jun. 2009 (CEST)
thread_title:  Sinn und Zweck 

message: Ich habe mich mal daran gemacht, die Berechnung der Quadratwurzel nach Newton-Raphson (das Beispiel aus dem verlinkten Artikel von John Hughes, Seiten 9 bis 11) in Python umzusetzen, um zu sehen, inwieweit das funktionale Paradigma unterstützt wird. Natürlich wird man in Python üblicherweise, wenn es nur um diese konkrete Berechnung geht, alles in eine Funktion stecken, in der rekursiven Variante z. B. so:
def sqrt(N, x, eps):
    nv = (x + N/x) / 2
    # print '...', nv               # (zur Ausgabe der Zwischenergebnisse)
    if abs(nv-x) < eps:
        return nv
    return sqrt(N, nv, eps)
Es geht aber auch folgendes:
def next(N, x):                     # (1)
    return (x + N/x) / 2
def repeat(f, first):               # (2)
    while True:
        yield first
        first = f(first)
def within(eps, seq):               # (3)
    x = None
    for nv in seq:
        # print '...', nv           # (auskommentiert)
        if x is None:               # leider nötig (siehe unten)
            pass
        elif abs(nv-x) < eps:
            return nv
        x = nv
def sqrt(N, eps, first):            # (4)
    return within(eps,
                  repeat(lambda x: next(N, x),  # (5)
                         first))
N = 2.0                             # (6)
eps = 0.000001
startwert = 1.0
print 'sqrt(%f, %f, %f) -> %r' % (N, eps, startwert, sqrt(N, eps, startwert))
# Die Funktion next generiert die nächste Iteration an+1, basierend auf dem Eingabewert N und an
# Die Funktion repeat generiert eine Sequenz, indem sie einen Startwert first ausgibt und dann die übergebene Funktion f wiederholt auf diesen Startwert bzw. das Ergebnis der vorigen Iteration anwendet. Es wäre z. B. möglich, mit repeat(lambda n: n+1, 1) die natürlichen Zahlen zu generieren (bis die nächste Zahl durch den aufrufenden Code nicht mehr angefordert wird)
# Die Funktion within liest die (z. B. mit Hilfe von repeat) generierte Sequenz und gibt das erste Element zurück, das sich von seinem Vorgänger um weniger als eps (Epsilon) unterscheidet
# Die Funktion sqrt setzt nun die bis hierher definierten Funktionen zusammen, um die Quadratwurzel zu berechnen:
#* Es wird mit Hilfe von repeat eine Sequenz mit dem Startwert first generiert;
#* die Funktion within filtert aus dieser Sequenz den gewünschten Näherungswert.
# Da für repeat eine Funktion mit nur einem Argument benötigt wird und N über alle Aufrufe gleich bleibt, wird eine Funktion erzeugt und übergeben, die diesen Wert N bereits kennt (Closure); „lambda x: next(N, x)“ entspricht Hughes' „(next N) x“
# Verwendung der Funktion zur Berechnung der Quadratwurzel von 2:
#* Die 2 wird als Fließkommazahl angegeben, damit nicht irrtümlich ganzzahlig dividiert wird
#* Das Ergebnis wird als %r formatiert, um Rundung zu vermeiden (z. B. für Experimente mit Epsilon)
Abgesehen davon, daß repeat und within nicht rekursiv definiert sind, sondern mit Hilfe von Generatoren, entspricht diese Python-Implementierung genau Hughes' Beispiel; so ist es hier gleichermaßen möglich, durch Verwendung einer anderen within-Funktion das Abbruchkriterium zu ändern.
Nun weiß ich nicht, ob Hughes' Miranda-Beispiele hier aufgeführt werden dürften; aber möglicherweise ist das hier ja schon hilfreich – zumindest ist es ganz gut lesbar, und es kann sicher bei der Entscheidung helfen, ob Python nun eine funktionale Programmiersprache ist... Vielleicht ist es ja funktional, aber nicht deklarativ? Sind rein funktionale Sprachen generell deklarativ? --Tobias 16:15, 23. Jun. 2009 (CEST)
thread_title:  Quadratwurzel in Python 

message: Obige within-Funktion ließe sich natürlich auch in Python rekursiv definieren; allerdings klappt das leider nur für Sequenzen bekannter Länge:
>>> seq = list()
>>> for i, e in zip(range(9), repeat(lambda x: x/2, 1.0)):
...     seq.append(e)
...
>>> seq
[1.0, 0.5, 0.25, 0.125, 0.0625, 0.03125, 0.015625, 0.0078125, 0.00390625]
>>> def within(eps, seq):
...     first = seq[0]         #     (Variablen nur zur
...     second = seq[1]        # besseren Verständlichkeit)
...     if abs(second-first) < eps:
...         return second
...     return within(eps, seq[1:])
...
>>> within(0.01, seq)          # oben erzeugte Sequenz bekannter Länge
0.0078125
>>> within(0.01, repeat(lambda x: x/2, 1.0))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in within
TypeError: 'generator' object is unsubscriptable
>>>
Daher oben der Umweg über den Vergleich mit None.
--Tobias 16:15, 23. Jun. 2009 (CEST)
thread_title:  Einschränkungen in Python 

message: Ich habe die Überarbeiten-Vorlage entfernt. Diese war sehr lange am Artikel und ich glaube, dass die nicht mehr nötig ist. Sollte jemand anderer Meinung sein, dann bringt sie wieder an und begründet das. --Qbi 16:59, 29. Okt. 2009 (CET)
thread_title:  Überarbeiten entfernt 

message: "Der Begriff der Funktion wird in Informatik und Mathematik mit unterschiedlicher Bedeutung verwendet" Das ist so sicherlich gerade nicht richtig. Der Link auf das Lemma der "Funktion (Programmierung)" macht dies garantiert nicht besser, sondern verleitet den Laien dazu, dass "Informatik" und "Programmieren" das Gleiche ist. Vielmehr besteht zwischen den wissenschaftlichen Fachrichtungen Informatik und Mathematik mit Sicherheit bei dieser Begrifflichkeit Einigkeit. Informatik und Programmieren ist nunmal nicht das Gleiche. (nicht signierter Beitrag von 84.59.12.159 (Diskussion | Beiträge) 01:46, 4. Jan. 2010 (CET)
thread_title:  Funktionenbegriff Informatik bzw. Mathematik 

message: Das gezeigt Programm berechnet nicht den Flächeninhalt eines Rings. -- Traxer 14:40, 17. Feb. 2010 (CET)
thread_title:  Scala: Überarbeiten-Baustein 

message: Sollte man die Paradigmen der funktionalen Programmierung nicht in einem eigenen Abschnitt aufführen. Ich wollte mir einen Überblick über die funktionale Programmierung verschaffen, fand dies aber schwierig, da die Paradigmen zwar mehrfach erwähnt, aber nirgens explizit genannt werden.
Da ich nur geringe Erfahrungen auf dem Gebiet habe, traue ich mir diese Ergänzung momentan auf die Schnelle nicht zu -- KoniPaka 11:28, 15. Sep. 2010 (CEST)
thread_title:  Paradigmen der funktionalen Programmierung 

message: Ich bin doch etwas erstaunt ob der Trivialität des gegebenen Beispiels. Daran kann man nicht verstehen, was funktionale Programmierung bedeutet. Für Anfänger ist es am wichtigsten zu verstehen, dass Variablen nicht modifiziert werden können, und dass man mittels Rekursion oder Kombinatoren Zwischenwerte weiterberechnet, bis das Endergebnis erreicht ist, und dass es dabei von einer Variablen beliebig viele "Versionen" von Werten gibt. Eine Gegenüberstellung eines Faltungsoperators mit einer imperativen for-Schleife wäre hier zur Abgrenzung von der imperativen Programmierung hilfreicher.
Das Beispiel "Makefile" ist schlicht falsch. Makefiles modifizieren den Zustandsraum, der im Wesentlichen aus dem Dateisystem besteht. Makefiles sind nicht funktional, sondern eine deskriptive Form imperativer Algorithmen.
-- Gerd Stolpmann (nicht signierter Beitrag von 84.58.57.23 (Diskussion) 15:54, 22. Feb. 2012 (CET)
thread_title:  Die Beispiele sind schlecht 

message: Jetzt lese ich doch mal genauer. Ich glaube, die Autoren haben gar keine Ahnung, was FP eigentlich ist. Das fängt mit der Definition im ersten Abschnitt an: "Sprachelemente zur Kombination und Transformation von Funktionen" sollen charakteristisch sein. Das ist eine Wischiwaschi-Definition! Es ist doch kein Wunder, dass sich Leute beschweren, warum denn ihre Lieblingssprache nicht hier als funktional aufgeführt wird!
Eine bessere Definition: Eine FP ist eine Sprache, die (im Kern) den Lambda-Kalkül auf von-Neumann-Maschinen emuliert. Darum geht's nämlich: Wir haben einen mathematisch streng definierten Kalkül, aber Computer, die auf ganz andere Weise funktionieren. Eine (reale, zur praktischen Programmierung bestimmte) FP ist immer dadurch gekennzeichnet, dass sie diesen konzeptionellen Unterschied überbrückt, und dabei eine Reihe von Kompromissen eingeht. Warum gibt es denn nicht-pure FP-Sprachen? Weil nicht-pure Elemente auf einfache Weise auf Computern ausführbar sind, und man den Performance-Vorteil nutzen will. Um reale FP-Sprachen zu verstehen, muss man sich dieser Schwierigkeit bewusst sein.
Eine reine FP-Sprache ist übrigens eine Sprache, die keine Zuweisung von Variablen in irgendeiner Form kennt.
Zum Abschnitt "Funktionen in Mathematik und Programmierung": Das ist der größte Unsinn, den ich je gelesen habe. Zusammengereimt! Eine Funktion in der Mathematik hat nichts mit Algorithmik zu tun! Man kann ja Funktionen auf überabzählbaren Mengen definieren - wie wollt ihr das denn mit Lambda-Abstraktionen vergleichen? Das ist unterste Schublade.
Ich vermisse in dem Artikel wesentliche Definitionen, die für FP essentiell sind, etwa Variable, Closure (=Implementierung einer Lambda-Abstraktion mit Hilfe von gemerkten Environments), Rekursion, Abstraktion, Applikation.
Den ganzen Abschnitt über typisierte Sprachen sollte man eindampfen. Ein Verweis darauf, dass sich Typ-Kalküle angeben lassen sollte reichen. Das Thema ist nämlich endlos, und hat nur begrenzt mit FP zu tun. Typinferenz ist zwar vorherrschend bei FP, aber grundsätzlich nicht darauf beschränkt. SQL hat auch Typinferenz, und es gibt keinen Grund, warum man Typinferenz nicht für imperative Sprachen entwickelt können sollte. Interessant wäre hier eher noch, dass die Typisierung rekursiver Funktionen schwierig ist, und alle FP-Sprachen hier Kompromisse machen (z.B. Beschränkung auf regulär typisierte Rekursion).
Eine Funktion höherer Ordnung heißt übrigens Kombinator.
Der Stil des Artikels ist anfängerhaft: "Die theoretische Informatik hat gezeigt, ...". Das gehört sich nicht für Lexikon-Artikel. Schreibe das Faktum auf, und belege mit Quelle.
Ich glaube, der ganze Artikel krankt daran, dass er ein sehr abstraktes Konzept herunterbrechen will auf die Denkweise der einfachen Programmierer. Damit ist aber nichts gewonnen: Die Definitionen werden beliebig, und Abgrenzungen können nicht gezogen werden. Die einfachen Programmierer haben dann auch nichts davon. Ich würde es begrüßen, den Artikel umzuschreiben, und das Niveau hochzusetzen, so dass eine echte Charakterisierung möglich wird. Ein Lexikon-Artikel ist ja nicht als Einführung in ein Thema gedacht, sondern als Übersicht über das vorhandene Wissen.
Sorry für den Verriss. Wer sich ungerecht behandelt fühlt, beschwere sich bei mir (gerd@gerd-stolpmann.de). -- Gerd Stolpmann (nicht signierter Beitrag von 84.58.57.23 (Diskussion) 17:17, 22. Feb. 2012 (CET)
thread_title:  Peinlicher Artikel 

message: Ich kann mich dem vorhergehenden Kommentator nur anschließen: Der Beitrag ist schlicht peinlich. Funktionen sind in der Mathematik Zuordnungen, die auf verschiedene Weise dargestellt werden können, zB. als Teilmengen eines cartesischen Produkts oder unter Rückgriff auf eine formale Sprache. Darstellung und Dargestelltes bringt der Autor komplett durcheinander. (nicht signierter Beitrag von Hebold (Diskussion | Beiträge) 07:26, 7. Mär. 2014 (CET)
thread_title:  Funktionen in der Mathematik und der Programmierung 

message: Folgender Absatz stößt mir sauer auf:
:"Die Mächtigkeit einer Programmiersprache ist definiert durch die Menge an Problemen, die in dieser Programmiersprache entscheidbar sind. Die theoretische Informatik hat gezeigt, dass eine reine funktionale Programmiersprache mit Rekursion gleich mächtig ist wie eine imperative Programmiersprache, die Schleifen und Zuweisungen erlaubt (siehe Turing-Vollständigkeit). Dies zeigt, dass das Einhalten des funktionalen Paradigmas keinerlei Einschränkungen mit sich bringt, auch wenn dies auf den ersten Blick so scheinen mag."
Mit dem Hinweis darauf, dass auch Brainfuck Turing-vollständig ist -- und mir mit Sicherheit niemand erzählen will, dass BF "keinerlei Einschränkungen mit sich bringt" -- stelle ich die obige Aussage in Frage und fordere Quellen, die genau das (Turing-vollstandig also folgt keine Einschränkungen) belegen. Da der Absatz ansonsten nicht viel zum Artikel beiträgt, und der folgende Absatz sehr viel weniger theoretisch Vor- und Nachteile aufzählt, würde ich den Absatz ansonsten löschen. -- 145.228.61.5 12:00, 2. Jun. 2015 (CEST)
thread_title:  Abschnitt "Mächtigkeit" 

message: Ich halte die Beispiele XSLT und Makefile für irreführend. Sie tragen nicht dazu bei FP zu erläutern. Beim Makefile habe ich Zweifel, ob die Behauptung stimmt, also ob diese den Lambda-Kalkül abbilden können.
- Benutzer:West of House (21:21, 6. Jan. 2017 (CET)
thread_title:  Irreführende Beispiele 

message: Ich habe die fraglichen Abschnitte "Funk in mathematik und infor." sowie "Mächtigkeit..." entfernt sowie einen Absatz der eine weiter oben schon erklärtes Konzept wiederholt hat.
Ich werde jetzt den mathematischen Teil seiner Programmiersprachenunabhängikeit wegen nach und nach ergänzen. 
Mir ist aufgefallen, dass die Programmierbeispiele alle ein Beispiel behandeln, das nicht im engeren Sinne funktional ist und darum eher ungeeignet ist, das wesen von FP klar zu machen. Das ist schade, da viele Leute daran mitgewirkt haben. Ein besseres Beispiel wäre etwas mit map oder reduce oder noch besser ein ganzer Hylomorphismus. Und dann ein paar P-Sprachen weniger. Man muss nicht von jeder Codierform nachweisen, dass sie auch irgendwie ein bisschen funktional ist (Hat auch oben schon ein anderer Autor angemahnt).
West of House (Diskussion) 17:01, 18. Jan. 2017 (CET)
thread_title:  Abschnitte entfernt 

message: Ich wollte mal schnell nachschauen, was "Funktionale Programmierung" ist. Habe aber null verstanden. Wer das verstehen kann, der weiss sowieso schon, was funktionale Programmierung ist.... --2.246.98.178 12:21, 11. Mai 2017 (CEST)
thread_title:  nicht zu verstehen 

message: In der Hoffnung das zu verbessern, habe ich die Einleitung abgeändert.
West of House (Diskussion) 15:05, 11. Mai 2017 (CEST)
thread_title:  Danke für die Kritk 

message: Ich habe mir die Beispiele angeschaut. Sollte da nicht noch C++ mit hin?
auto pi = 3.14;
auto squared = [](auto x) { return x * x; };
auto ringarea = [squared](auto r1, auto r2) { return pi * (squared(r1) - squared(r2)); };
--JAS (Diskussion) 11:28, 23. Jul. 2019 (CEST)
thread_title:  C++ Beispiel 

message: Die Definition bzw. Beispiele im Artikel passen mit "Populäre Sprachen, die keinerlei Möglichkeiten zur funktionalen Programmierung bieten, sind zum Beispiel C" überhaupt nicht zusammen. Ein C-Programm besteht ja schon primär aus der main()-Funktion, welche eigentlich standardkonform eine beliebige Liste an Parametern entgegen nimmt, und einen int-Wert bei Beendigung zurückgibt. Und Rekursion ist sowieso für eine mächtige Programmiersprache unerlässlich.
Überhaupt sollte man überdenken, ob die Grenzen zwischen den Programmierparadigmen so fundamental dargestellt werden sollten. Ein "stdout.print("Hallo Welt");" ist z.B. schließlich genauso imperativ wie "printf("Hallo Welt");", es wird nur objektorientiert verpackt. Grundsätzlich kann man so ziemlich alle Programmierparadigmen mit C verfolgen, es ist nur umständlich und der Compiler erzwingt natürlich keinen "guten Stil".--Mr. B.B.C. (Diskussion) 12:46, 18. Jun. 2020 (CEST)
replies: text: Nein, das ist nicht so.  In funktionalen Programmiersprachen agieren Funktionen als "first class citizens" und können nicht nur in Variablen gespeichert werden, sondern auch zur Laufzeit algebraisch verknüpft werden (Das untersucht unter anderem die Kategorientheorie). Das kann C definitiv nicht. Da C auch keine lokalen Funktionen kennt, noch weniger eine lexikalische Bindungen abschließen (Closure bilden) kann, ist C alles andere als funktional. --West of House (Diskussion) 11:32, 14. Dez. 2022 (CET)
thread_title:  C geht nicht funktional - irgendwas stimmt da nicht... 

message: Ich kenne sie nicht, aber Idris
https://en.wikipedia.org/wiki/Idris_(programming_language)
(gibt es in der dt. Wikipedia noch nicht) scheint eine rein funktionale Programmiersprache zu sein.
Sie wurde einem Bekannten jüngst empfohlen, so komme ich drauf.
Da ich nicht weiß, wie ich "gut" Links ins Englischsprache mache, packe ich es hier hin, statt in den Artikel selbst
-- 87.78.73.45 08:59, 21. Jan. 2021 (CET)
thread_title:  Weiteres Beispiel rein funktionaler Programmiersprache: Idris