Warum wurde die funktionale Programmierung noch nicht übernommen?


197

Ich habe einige Texte über deklarative / funktionale Programmierung (Sprachen) gelesen, Haskell ausprobiert und selbst einen geschrieben. Nach allem, was ich gesehen habe, hat die funktionale Programmierung gegenüber dem klassischen imperativen Stil mehrere Vorteile:

  • Staatenlose Programme; Keine Nebenwirkungen
  • Parallelität; Spielt sich sehr gut mit der aufstrebenden Multi-Core-Technologie
  • Programme sind normalerweise kürzer und in einigen Fällen leichter zu lesen
  • Die Produktivität steigt (Beispiel: Erlang)

  • Imperative Programmierung ist ein sehr altes Paradigma (soweit ich weiß) und möglicherweise nicht für das 21. Jahrhundert geeignet

Warum sind Unternehmen, die in funktionalen Sprachen geschrieben oder programmiert sind, immer noch so "selten"?

Warum verwenden wir bei der Betrachtung der Vorteile der funktionalen Programmierung immer noch zwingende Programmiersprachen?

Vielleicht war es 1990 zu früh dafür, aber heute?


1
HINWEIS: diese Frage auf Meta wurde zweimal zumindest diskutiert, und der Konsens ist , dass es sollte gehalten werden, wenn auch über die „historische Bedeutung“ lock archiviert oben erwähnt. Ich empfehle jedem, der dies mit Blick auf das Entsperren betrachtet, nachdrücklich anzuhalten und sich dafür zu bedanken, dass er nicht an einer weiteren langwierigen Diskussion über diese Frage teilnehmen muss, die Antworten so zu genießen, wie sie sind, und sein Geschäft fortzusetzen.
Shog9

Antworten:


530

Denn all diese Vorteile sind auch Nachteile.

Staatenlose Programme; Keine Nebenwirkungen

In realen Programmen dreht sich alles um Nebenwirkungen und Mutationen. Wenn der Benutzer eine Taste drückt, möchte er, dass etwas passiert. Wenn sie etwas eingeben, möchten sie, dass dieser Status den Status ersetzt, der früher vorhanden war. Wenn Jane Smith in der Buchhaltung heiratet und ihren Namen in Jane Jones ändert, sollte sich die Datenbank, die den Geschäftsprozess unterstützt, der ihren Gehaltsscheck druckt, besser mit dieser Art von Mutation befassen. Wenn Sie das Maschinengewehr auf den Außerirdischen abfeuern, modellieren die meisten Menschen dies nicht mental als den Bau eines neuen Außerirdischen mit weniger Trefferpunkten. Sie modellieren dies als Mutation der Eigenschaften eines vorhandenen Außerirdischen.

Wenn die Konzepte der Programmiersprache grundsätzlich gegen die zu modellierende Domäne arbeiten, ist es schwierig, die Verwendung dieser Sprache zu rechtfertigen.

Parallelität; Spielt sich sehr gut mit der aufstrebenden Multi-Core-Technologie

Das Problem wird nur herumgeschubst. Mit unveränderlichen Datenstrukturen haben Sie eine günstige Thread-Sicherheit auf Kosten der möglichen Arbeit mit veralteten Daten. Mit veränderlichen Datenstrukturen haben Sie den Vorteil, dass Sie immer an neuen Daten arbeiten müssen, ohne komplizierte Logik schreiben zu müssen, um die Daten konsistent zu halten. Es ist nicht so, dass einer von ihnen offensichtlich besser ist als der andere.

Programme sind normalerweise kürzer und in einigen Fällen leichter zu lesen

Außer in den Fällen, in denen sie länger und schwerer zu lesen sind. Zu lernen, wie man Programme liest, die in einem funktionalen Stil geschrieben sind, ist eine schwierige Fähigkeit. Menschen scheinen Programme viel besser als eine Reihe von Schritten zu verstehen, die wie ein Rezept zu befolgen sind, als als eine Reihe von Berechnungen, die durchgeführt werden müssen.

Die Produktivität steigt (Beispiel: Erlang)

Die Produktivität muss stark steigen, um die massiven Kosten für die Einstellung von Programmierern zu rechtfertigen, die wissen, wie man in einem funktionalen Stil programmiert.

Und denken Sie daran, Sie möchten kein funktionierendes System wegwerfen. Die meisten Programmierer erstellen keine neuen Systeme von Grund auf neu, sondern warten vorhandene Systeme, von denen die meisten in nicht funktionierenden Sprachen erstellt wurden. Stellen Sie sich vor, Sie versuchen dies gegenüber den Aktionären zu rechtfertigen. Warum haben Sie Ihr bestehendes Lohn- und Gehaltsabrechnungssystem verschrottet, um ein neues zu bauen, das Millionen von Dollar kostet? "Weil funktionale Programmierung großartig ist" wird die Aktionäre wahrscheinlich nicht begeistern.

Imperative Programmierung ist ein sehr altes Paradigma (soweit ich weiß) und möglicherweise nicht für das 21. Jahrhundert geeignet

Auch die funktionale Programmierung ist sehr alt. Ich sehe nicht, wie das Alter des Konzepts relevant ist.

Versteh mich nicht falsch. Ich liebe funktionale Programmierung, ich bin diesem Team beigetreten, weil ich helfen wollte, Konzepte aus der funktionalen Programmierung in C # zu bringen, und ich denke, dass Programmierung in einem unveränderlichen Stil der Weg der Zukunft ist. Die Programmierung in einem funktionalen Stil ist jedoch mit enormen Kosten verbunden , die nicht einfach wegzuwünschen sind. Der Übergang zu einem funktionaleren Stil wird über Jahrzehnte hinweg langsam und schrittweise erfolgen. Und genau das wird es sein: eine Verlagerung hin zu einem funktionaleren Stil, keine umfassende Berücksichtigung der Reinheit und Schönheit von Haskell und der Aufgabe von C ++.

Ich baue Compiler, um meinen Lebensunterhalt zu verdienen, und wir setzen definitiv auf einen funktionalen Stil für die nächste Generation von Compiler-Tools. Das liegt daran, dass die funktionale Programmierung grundsätzlich gut zu den Problemen passt, mit denen wir konfrontiert sind. Bei unseren Problemen geht es darum, Rohdaten - Zeichenfolgen und Metadaten - aufzunehmen und in verschiedene Zeichenfolgen und Metadaten umzuwandeln. In Situationen, in denen Mutationen auftreten, wie z. B. wenn jemand die IDE eingibt, eignet sich der Problembereich von Natur aus für Funktionstechniken wie das schrittweise Neuerstellen nur der Teile des Baums, die sich geändert haben. Viele Domains haben diese netten Eigenschaften nicht, die sie offensichtlich für einen funktionalen Stil zugänglich machen .


41
"Wenn Jane Smith in der Buchhaltung heiratet und ihren Namen in Jane Jones ändert, sollte sich die Datenbank, die den Geschäftsprozess unterstützt, der ihren Gehaltsscheck druckt, besser mit dieser Art von Mutation befassen." Es wird eine Aufzeichnung von Jane Smiths früherem Namen geben, wir aktualisieren nicht rückwirkend alle Instanzen von Janes früherem Namen auf ihren neuen Namen;)
Julia

40
@ Julia: Sicher. Mein Punkt ist, dass wenn Sie ein Objekt haben, das einen Mitarbeiter darstellt, es sinnvoll ist, sich die Operation "Namen des Mitarbeiters ändern" als eine Mutation des Objekts vorzustellen, das den Mitarbeiter darstellt , der die Objektidentität nicht ändert . Wenn Jane Smith ihren Namen ändert, erstellen Sie keine andere Mitarbeiterin namens Jane Jones, die ansonsten identisch ist. Es gibt nicht zwei Mitarbeiter mit zwei unterschiedlichen Namen. Es ist natürlich, diesen Prozess als Mutation eines Objekts zu modellieren, nicht als Konstruktion eines neuen Objekts.
Eric Lippert

24
Dies ist eine gute Antwort, aber ich denke, Sie übertreiben Ihren Fall manchmal. Wie Juliet sagte, obwohl die Leute es vielleicht als Namensänderung betrachten, ist es wirklich ein Namensersatz auf einer tieferen Ebene. Und obwohl funktionale Programme für Menschen möglicherweise schwieriger zu lesen sind (weil es sich um eine erlernte Fähigkeit handelt), liegt dies im Allgemeinen nicht daran, dass sie länger sind. Ein Haskell-Programm ist fast immer knapper als beispielsweise ein Java-Programm - selbst in einer "Bad Fit" -Domäne mit vielen inhärenten Zuständen.
Chuck

29
+1 Es war so ein Hauch frischer Luft, diese Antwort zu lesen. Es ist fantastisch, solchen Pragmatismus (mit einer Leidenschaft für funktionale Programmierung) von jemandem in Ihrer Position zu hören.
Auspuff

11
"Weil all diese Vorteile auch Nachteile sind. Staatenlose Programme; keine Nebenwirkungen": Soweit ich weiß (ich weiß nicht genug über FP, um eine maßgebliche Antwort zu schreiben), ist dies nicht korrekt . Bei der funktionalen Programmierung geht es um referenzielle Transparenz, nicht um das Vermeiden von Status (obwohl der Status angemessen behandelt werden muss, um referenzielle Transparenz zu gewährleisten). Haskell erlaubt Zustand und Mutation. Es bietet nur verschiedene (man könnte argumentieren, bessere) Werkzeuge, um darüber nachzudenken.
Giorgio

38

Masterminds of Programming: Gespräche mit den Machern der wichtigsten Programmiersprachen

[Haskell]

Warum hat Ihrer Meinung nach keine funktionierende Programmiersprache den Mainstream erreicht?

John Hughes: Schlechtes Marketing! Ich meine nicht Propaganda; wir haben viel davon gehabt. Ich meine eine sorgfältige Auswahl einer zu dominierenden Zielmarktnische, gefolgt von einem entschlossenen Bemühen, die funktionale Programmierung bei weitem zum effektivsten Weg zu machen, um diese Nische anzugehen. In den glücklichen Tagen der 80er Jahre dachten wir, funktionale Programmierung sei für alles gut - aber neue Technologien als "gut für alles" zu bezeichnen, ist dasselbe wie "besonders gut für nichts". Was soll die Marke sein? Dies ist ein Problem, das John Launchbury in seinem eingeladenen Vortrag auf der ICFP sehr deutlich beschrieben hat. Galois Connections ging fast unter, als ihre Marke "Software in funktionalen Sprachen" war, aber sie haben an Stärke gewonnen, seit sie sich auf "hochsichere Software" konzentriert haben.

Viele Menschen haben keine Ahnung, wie technologische Innovationen stattfinden, und erwarten, dass bessere Technologien einfach von alleine dominieren (der "bessere Mausefallen" -Effekt), aber die Welt ist einfach nicht so.


36
Haskell: Nach 20 Jahren ein Erfolg über Nacht!
Julia

Folgen Sie dem Link und lesen Sie die Bewertungen für eine ziemlich amüsante Dis von Grady Booch. Keine Ahnung, wer Booch ist, aber es hat mich trotzdem zum Lachen gebracht.
Angst vor Hackplanet

4
Grady Booch ist letztendlich zusammen mit Jacobson und Rumbaugh für den Gräuel verantwortlich, der UML ist.
NUR MEINE RICHTIGE MEINUNG

27

Die Standardantwort lautet, dass keiner den anderen ersetzen wird oder sollte - es handelt sich um unterschiedliche Tools mit unterschiedlichen Vor- und Nachteilen, und welcher Ansatz den Vorteil hat, hängt vom Projekt und anderen "weichen" Problemen wie dem verfügbaren Talentpool ab.

Ich denke, Sie haben Recht, dass das Wachstum der Parallelität aufgrund von Multi-Core den Prozentsatz (der globalen Reihe von Entwicklungsprojekten) erhöht, wenn die funktionale Programmierung anderen Stilen vorgezogen wird.

Ich denke, das ist heute selten, weil der Großteil des heutigen professionellen Talentpools mit imperativen und objektorientierten Technologien am besten vertraut ist. Zum Beispiel habe ich mehr als einmal Java als Sprache für ein kommerzielles Projekt gewählt, weil es gut genug und unumstritten war und ich weiß, dass mir nie die Leute ausgehen werden, die darin (gut genug) programmieren können.


Das ist sehr aufschlussreich und wunderbar pragmatisch. Auf jeden Fall die beste Antwort, die ich auf diese Frage in all ihren Formen gesehen habe.
Benson

Vielleicht wird durch eine Sprache, für die beide erstklassige Bürger sind, populär.
Kevin Kostlan

1
Stimmen Sie 110% zu. Bei mehreren Gelegenheiten habe ich versucht, in die FP einzusteigen, aber ich habe den Willen verloren, nach ein paar Wochen fortzufahren. Ich programmiere seit über 30 Jahren prozedural und bin einfach zu sehr an imperative Programmierung gewöhnt. Dies gilt für die gesamte IT-Branche. Veränderungen werden weder einfach noch schnell kommen.
Richard Eng

26

Trotz der Vorteile der funktionalen Programmierung wird die imperative und objektorientierte Programmierung niemals vollständig verschwinden.

Imperative und objektorientierte Programmierung ist eine schrittweise Beschreibung des Problems und seiner Lösung. Als solches kann es einfacher zu verstehen sein. Die funktionale Programmierung kann etwas unklar sein.

Letztendlich hat ein nützliches Programm immer Nebenwirkungen (z. B. die Bereitstellung der tatsächlichen Ausgabe für den Benutzer zum Verbrauch), sodass die reinste funktionale Sprache von Zeit zu Zeit immer noch einen Weg in die imperative Welt finden muss.

Der aktuelle Stand der Technik ist, dass imperative Sprachen (wie C #) Merkmale aus der Funktionswelt (wie Lambda-Aussagen) ausleihen und umgekehrt.


3
Ist OOP nicht eine Art Teilmenge der imperativen Programmierung?
Pankrax

9
OOP ist eine Obermenge. OOP ist zu zwingend wie C ++ zu C.
Robert Harvey

10
Ich denke nicht, dass OOP notwendigerweise auf zwingende Programmierung angewiesen ist. Schauen Sie sich eine Clojure oder CLOS an - beide sind funktional und dennoch objektorientiert.
Gabe

9
OO-Sprachen sind in der Regel unerlässlich, müssen es aber nicht sein. OCaml ist eine stark (wenn auch nicht rein) funktionale Sprache, deren gesamte Existenzberechtigung OO ist.
Chuck

7
Ich verstehe nicht, warum OOP eine Obermenge der imperativen Programmierung ist. Nicht jeder zwingende Code ist OOP, und nicht jeder Funktionscode ist nicht OOP. Ich würde eher sagen, dass OOP zu zwingender Programmierung und funktionaler Programmierung gehört, wie aerodynamische Flügel zu Rennwagen oder Flugzeugen oder Raketen oder Lüftern oder Windmühlen, oder ... dh die Konzepte sind verwandt, aber nicht eng miteinander verbunden eine 1-zu-1-Verbindung.
Sebastian Mach

21

Hat es nicht?

Smalltalk war damals ein großartiges objektorientiertes System. Warum hat die objektorientierte Programmierung nicht übernommen? Nun, das hat es. Es sieht einfach nicht nach Smalltalk aus. Mainstream-Sprachen werden mit C ++, Java, C # usw. immer kleiner. Mode und Stil ändern sich langsamer als alles andere. Als OO zum Mainstream wurde, haben wir Teile von OO auf alte Sprachen geklebt, sodass sie so aussahen, als ob C sie schlucken könnte .

Funktional ist der gleiche Weg. Haskell war eine großartige funktionale Sprache. Aber wir haben heute noch mehr Mainstream-Programmierer, die C-ähnliche Syntax verwenden als vor 20 Jahren. Es muss also wie C aussehen. Fertig: Sehen Sie sich einen LINQ-Ausdruck an und sagen Sie mir, dass er nicht funktioniert.


2
Interessanter Punkt, aber wie sind die Mainstream-Sprachen Smalltalk-ähnlicher geworden? C ++, Java und C # basieren beispielsweise nicht auf dem Senden von Nachrichten, was (glaube ich) der wichtigste Teil des Smalltalk-Paradigmas ist.
Jonathan Sterling

4
Jonathan: Wählen Sie eine Smalltalk-Funktion aus und beobachten Sie, wie sie in C ++ (der ältesten) am schwächsten, in Java in Ordnung und in C # besser ist. Zum Beispiel GC (nur Java / C #), Autoboxing (später nur Java / C #), Closures (nur C #) und Reflection (in Java vorhanden, besser in C #). Wenn Sie Nachrichten weitergeben möchten, schauen Sie sich C # 4 an dynamic. Das ist die kleinste dieser Funktionen, daher ist es für mich keine Überraschung, dass sie nur in der neuesten Version der modernsten dieser drei Sprachen vorhanden ist. :-)
Ken

Javascript, Python und Ruby sind gute Beispiele dafür, wie es tatsächlich
funktioniert

15

Ich glaube, dass imperative Sprachen nur deshalb häufiger vorkommen, weil mehr Menschen daran gewöhnt sind. Weder die funktionale Programmierung noch das imperative Programmiermodell sind dunkler oder akademischer als das andere. In der Tat sind sie Ergänzungen.

Ein Poster sagte, dass imperativer Code leichter zu verstehen ist als funktionaler Programmiercode. Dies gilt nur, wenn der Leser bereits imperativen Code gesehen hat, insbesondere wenn die vorherigen Beispiele Teil derselben "Familie" sind (z. B. C / C ++, Perl, PHP und Java). Ich würde nicht behaupten, dass es für eine imperative Sprache gilt; Nehmen Sie einen Vergleich von Java und Forth, um ein extremes Beispiel zu geben.

Für einen Laien sind alle Programmiersprachen nicht entzifferbar, außer vielleicht die ausführlichen Sprachen wie Hypertalk und SQL. (Bemerkenswerterweise ist SQL eine deklarative und / oder funktionale Sprache und erfreut sich enormer Beliebtheit.)

Wenn wir von Anfang an in einer Lisp-y- oder Haskell-y-Sprache geschult worden wären, würden wir alle denken, dass funktionale Programmiersprachen völlig normal sind.


"Ein Poster sagte, dass imperativer Code leichter zu verstehen ist als funktionaler Programmiercode. Dies gilt nur, wenn der Leser bereits imperativen Code gesehen hat, insbesondere wenn die vorherigen Beispiele Teil derselben" Familie "sind (zum Beispiel C / C ++, Perl, PHP und Java). ": Sehr wahr (+1): Ich erinnere mich, wie viel Mühe ich investieren musste, um Pascal und C zu lernen, als ich anfing zu programmieren. Und wie einfach es ist, Scala, Haskell oder Scheme zu lesen, nachdem ich Erfahrung mit diesen Sprachen habe.
Giorgio

2
Der einzige Grund, warum ich den veränderlichen Zustand manchmal immer noch für nützlich halte, ist, dass er eine einfache Möglichkeit bietet, schnellen Code zu schreiben (kein Kopieren). Der Grund dafür könnte sein, dass ich nicht genügend funktionale Programmierung kenne und dass Sie in 90% der Situationen schnellen Funktionscode schreiben können, ohne den veränderlichen Status zu verwenden.
Giorgio

3
Eine der am häufigsten verwendeten und langlebigsten Umgebungen für die Organisation von Berechnungen ist die Tabelle. Im Wesentlichen eine funktionale Programmierumgebung mit Zellen anstelle von benannten Variablen. Ich glaube nicht, dass Menschen Programme im Allgemeinen von Natur aus als eine Reihe von Schritten verstehen. Vielleicht Programmierer, die in weit verbreiteten imperativen Sprachen versunken sind.
JPNP

14

Sie haben bereits genug Antworten erhalten, dass ich nur ein paar Dinge erwähne, die ich noch nicht erwähnt habe.

In erster Linie haben prozedurale Sprachen (meiner Meinung nach) stark von ihrem Grad an Gemeinsamkeit profitiert. Zum Beispiel kann fast jeder, der fast jede der gängigen prozeduralen (oder OO-) Sprachen in fast jedem Maße kennt, die meisten anderen einigermaßen gut lesen. Ich vermeide es aktiv, in Java, C #, Cobol, Fortran oder Basic zu arbeiten (für nur einige Beispiele), kann sie aber einigermaßen gut lesen - fast genauso gut wie Menschen, die sie jeden Tag benutzen.

Auf der funktionalen Seite ist das viel weniger wahr. Zum Beispiel kann ich Scheme auch recht vernünftig schreiben, aber das nützt wenig beim Lesen von Ocaml oder Haskell (nur für ein paar Beispiele). Selbst innerhalb einer einzelnen Familie (z. B. Schema vs. Common Lisp) scheint sich die Vertrautheit mit der einen nicht annähernd so gut auf die andere zu übertragen.

Die Behauptung, dass Funktionscode besser lesbar ist, trifft nur unter einem engen Bereich von Bedingungen zu. Für Leute, die mit der Sprache sehr vertraut sind, ist die Lesbarkeit in der Tat ausgezeichnet - aber für alle anderen ist sie oft so gut wie nicht vorhanden. Schlimmer noch, während Unterschiede in prozeduralen Sprachen größtenteils syntaktisch sind und daher relativ leicht zu erlernen sind, sind Unterschiede in funktionalen Sprachen oft viel grundlegender, so dass sie ein beträchtliches Studium erfordern, um sie wirklich zu verstehen (z. B. zu wissen, dass Lisp für das Verständnis von Monaden wenig hilfreich ist).

Der andere wichtige Punkt ist, dass die Idee, dass funktionale Programme kürzer als prozedurale sind, häufig eher auf Syntax als auf Semantik basiert. In Haskell geschriebene Programme (zum Beispiel) sind oft recht kurz, aber ihre Funktionsfähigkeit ist nur ein kleiner Teil davon. Sehr viel, wenn es einfach so ist, dass Haskell eine relativ knappe Syntax hat.

Nur wenige rein funktionale Sprachen können mit APL gut um knappen Quellcode konkurrieren (obwohl APL fairerweise auch die Erstellung von Funktionen auf höherer Ebene unterstützt, ist dies also kein großer Unterschied wie in einigen anderen Fällen). Im Gegensatz dazu können Ada und C ++ (für nur einige Beispiele) in Bezug auf die Anzahl der Operationen, die zur Ausführung einer bestimmten Aufgabe erforderlich sind, durchaus wettbewerbsfähig sein, aber die Syntax ist (zumindest normalerweise) wesentlich ausführlicher.


Hervorragender Kommentar! Ich stimme voll und ganz zu. Ich finde die meisten prozeduralen Sprachen ziemlich leicht zu lesen und zu verstehen, obwohl ich in einigen nur ein echter Experte bin. Ich kann nicht dasselbe über FP-Sprachen sagen.
Richard Eng

1
Ein weiterer wichtiger Punkt ist, dass Sie in jedem Paradigma eine Reihe von Fachkenntnissen finden, von Neulingen bis zu Gurus. FP-Code mag für Experten leicht lesbar und verständlich sein, aber mittelmäßige Programmierer haben möglicherweise immer noch Probleme. Experten machen normalerweise einen sehr kleinen Teil der FP-Community aus.
Richard Eng

11

Keine wahrgenommene Notwendigkeit

Ich erinnere mich an die Antwort meines alten Chefs Rick Cline, als ich ihm eine Kopie von John Backus 'Turing Award-Vortrag mit dem Titel Kann Programmierung vom von Neumann-Stil befreit werden?

Seine Antwort: „Vielleicht sind einige von uns nicht will , von dem von - Neumann - Stil befreit werden!“


10

Warum wurde die funktionale Programmierung noch nicht übernommen?

Funktional ist für einige Dinge besser und für andere schlechter, so dass es niemals "übernimmt". Es ist jedoch in der realen Welt bereits allgegenwärtig.

Staatenlose Programme; Keine Nebenwirkungen

Zustandslose Programme sind einfacher zu testen. Dies wird heute allgemein geschätzt und in der Industrie häufig genutzt.

Parallelität; Spielt sich sehr gut mit der steigenden Multi-Core-Technologie. Programme sind normalerweise kürzer und in einigen Fällen leichter zu lesen. Die Produktivität steigt (Beispiel: Erlang).

Sie verbinden Gleichzeitigkeit und Parallelität.

Parallelität kann mithilfe von CSP (Communicating Sequential Processes) effektiv durchgeführt werden. Der Code in einem CSP kann seinen lokalen Status ändern, aber die zwischen ihnen gesendeten Nachrichten sollten immer unveränderlich sein.

Rein funktionale Programmierung spielt mit Multicore extrem schlecht, weil sie so cache-unfreundlich ist. Kerne konkurrieren um gemeinsam genutzten Speicher und parallele Programme werden nicht skaliert.

Warum sind Unternehmen, die in funktionalen Sprachen geschrieben oder programmiert sind, immer noch so "selten"?

Scala wird oft als funktionale Sprache angesehen, ist aber nicht funktionaler als C #, eine der beliebtesten Sprachen der Welt.

Warum verwenden wir bei der Betrachtung der Vorteile der funktionalen Programmierung immer noch zwingende Programmiersprachen?

Rein funktionale Programmierung hat viele schwerwiegende Nachteile, daher verwenden wir unreine funktionale Sprachen wie Lisp, Scheme, SML, OCaml, Scala und C #.


7

Wenn ich darüber nachdenke, was funktionale Programmierung für meine Projekte bei der Arbeit bedeuten könnte, werde ich immer auf den gleichen Weg geführt:

  1. Um die vollen Vorteile der funktionalen Programmierung nutzen zu können, benötigen Sie Faulheit. Ja, es gibt strenge funktionale Sprachen, aber die wirklichen Vorteile der funktionalen Programmierung kommen im strengen Code nicht so gut zur Geltung. In Haskell ist es beispielsweise einfach, eine Folge von verzögerten Vorgängen für eine Liste zu erstellen, diese zu verketten und auf eine Liste anzuwenden. Z.B. op1 $ op2 $ op3 $ op4 $ someList. Ich weiß, dass es nicht die gesamte Liste erstellen wird, und intern bekomme ich nur eine schöne Schleife, die nacheinander durch die Elemente geht. Auf diese Weise können Sie wirklich modularen Code schreiben. Die Schnittstelle zwischen zwei Modulen kann die Übergabe potenziell großer Datenstrukturen beinhalten, und dennoch muss die Struktur nicht resident sein.

  2. Wenn Sie jedoch faul sind, ist es schwierig, über die Speichernutzung nachzudenken. Durch Ändern der Haskell-Compiler-Flags wird häufig die von einem Algorithmus verwendete Speichermenge von O (N) auf O (1) geändert, außer manchmal nicht. Dies ist nicht wirklich akzeptabel, wenn Sie Anwendungen haben, die den gesamten verfügbaren Speicher maximal nutzen müssen, und es ist selbst für Anwendungen, die nicht den gesamten Speicher benötigen, nicht besonders gut.


Faulheit interagiert auch weniger als ideal mit dem Debuggen.
Brian

3
Da ich feststelle, dass viele der Fehler, die ich in anderen Sprachen jage, auf mangelnde referenzielle Transparenz zurückzuführen sind, mache ich mir weniger Sorgen um die Debugging-Probleme, auch wenn sie manchmal schmerzhaft sein können.
Sigfpe

6

Zwei Dinge:

  1. Es braucht nur Zeit, egal wie gut eine Technologie ist. Die Ideen hinter FP sind ungefähr 70 Jahre alt. Aber seine allgemeine Verwendung in der Softwareentwicklung (in den Gräben, in der Industrie) beträgt wahrscheinlich weniger als 10 Jahre. Entwickler zu bitten, rassistisch neue Denkweisen anzunehmen, ist möglich, braucht aber nur Zeit (viele, viele Jahre). Zum Beispiel wurde OOP in den frühen 1980er Jahren wirklich allgemein verwendet. Es gewann jedoch erst Ende der 90er Jahre an Bedeutung.
  2. Sie müssen Menschen dazu zwingen, sich der Stärke einer Technologie zu stellen, bevor sie groß rauskommt . Derzeit verwenden Benutzer Tools, die keine Parallelität verwenden, und die Dinge funktionieren einwandfrei. Wenn Apps, die keine Parallelität verwenden, unerträglich langsam werden; dann werden viele Menschen gezwungen sein, Parallelitätstools zu verwenden, und FP könnte an Popularität gewinnen. Dies kann auch für die anderen Stärken von FP gelten.

3
FP ist sehr gut in der Wiederverwendung von Code. Wahrscheinlich besser als OO. Ich musste mich bei der Arbeit ein paar Mal damit auseinandersetzen, auf verschiedene Typen und ein neues System migrieren und es war schmerzlos.
Nlucaroni

@Freddy Rios und @nlucaroni. Ich habe den Kommentar umformuliert, um Fehlinterpretationen zu beseitigen.
Phil
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.