Warum ist funktionale Programmierung in der Branche nicht beliebter? Fängt es jetzt an? [geschlossen]

61

Während meiner vier Jahre an der Universität haben wir viel funktionales Programmieren in mehreren funktionalen Programmiersprachen verwendet. Aber ich habe auch viel objektorientiertes Programmieren verwendet, und tatsächlich verwende ich objektorientierte Sprachen mehr, wenn ich mein eigenes kleines Projekt mache, um mich auf meinen ersten Job vorzubereiten. Aber ich wünschte mir oft, ich hätte bei diesen Projekten in einer funktionalen Programmiersprache programmiert.

Auf der Suche nach einem Job ist es jedoch sehr selten, einen Job zu finden, bei dem Kenntnisse einer funktionalen Programmiersprache erforderlich sind.

Warum werden in der Branche keine funktionalen Programmiersprachen mehr verwendet? Heutzutage gibt es ziemlich viele Neuigkeiten über funktionale Programmiersprachen. Ich frage mich also, ob sich funktionale Programmierung in der Branche jetzt durchsetzt.

Jonas
quelle
3
In gewissem Maße bin ich mit der Prämisse Ihrer Frage nicht einverstanden. Von "funktionalen Sprachen" inspirierte Sprachfunktionen werden Sprachen wie Java und JavaScript hinzugefügt. Tatsächlich war JavaScript immer (in gewisser Weise) eine funktionale Sprache, obwohl viele Leute es bis vor kurzem nicht verstanden haben.
MatrixFrog
1
@MatrixFrog: Man könnte sich fragen: "Warum sollte man nur auf halbem Weg funktional werden, indem man ein paar funktionale Konzepte zu nicht funktionalen Sprachen hinzufügt, anstatt eine vollwertige FP-Sprache zu übernehmen? Schließlich gibt es das Paradigma schon seit vielen Jahren und es ist sehr ausgereift."
Giorgio
world wechselt aus verschiedenen Gründen nicht zu überlegenen Alternativen (und pure FP ist eine überlegene Alternative), z. B. aus Gründen der Abwärtskompatibilität, Trägheit usw. Betrachten Sie das DVORAK-Tastaturlayout: Es ist effizienter für das Eingeben von Berührungen, aber wir alle bleiben bei QWERTY, nur weil es so viel Software gibt mit qwerty-freundlichen Verknüpfungen.
KolA

Antworten:

38

Ich würde sagen, dass einer der Gründe, warum funktionale Programmierung nicht mehr vorherrscht, der Mangel an Wissensbasis ist. Ich habe die Erfahrung gemacht, dass Unternehmen sehr risikoscheu sind, wenn es darum geht, Technologien zu implementieren, die kein Mainstream sind und lieber in bewährte Frameworks (Java, C ++, C #) investieren. Nur wenn ein Geschäftsbedürfnis besteht (wie bei Ericsson), werden neue Paradigmen in Betracht gezogen. Aber auch in Ericssons Fall hörte ich, dass das Management die Verwendung von c ++ forderte und Joe Armstrong gezwungen war, Lang-Aufrufe in c ++ zu codieren !! Dies soll zeigen, wie wenig Unternehmen bereit sind, neue Technologien umzusetzen!

Ennuikiller
quelle
9
Wie ist funktionale Programmierung in irgendeiner Weise "neu"?
Evan Plaice
7
Ich denke, er meinte "unbenutzt" statt "neu".
Vinko Vrsalovic
9
Also ist es unbenutzt ... weil es unbenutzt ist? Hm.
Alex Baranosky
21
@ Alex - Genau. Scheiße, nicht wahr?
KeithS
5
@ Stargazer712: Was sind diese Gründe? Ich kenne viele Entwickler, die sich mit funktionaler Programmierung nicht auskennen, daher macht Unwissenheit für mich Sinn. Gab es in der Vergangenheit einen massiven Fehler in der funktionalen Programmierung, der die Branche davon ablenkte, was mir nicht bewusst war?
Sean McMillan
67

Ich war Professor und genau wie Programmierer suchen Professoren immer nach dem nächsten großen Ding. Wenn sie glauben, sie hätten einen gefunden, machen sie ihn zu einem Zug, und alle stapeln sich weiter. Da sie Studenten predigen, die glauben, Professoren müssten wirklich schlau sein, sonst bekommen sie keinen Widerstand, warum sollten sie Professoren sein?

Funktionale Programmierung ist so ein Zug. Klar, es gibt viele interessante Fragen zu untersuchen und viele interessante Konferenzartikel zu schreiben. Es ist keine besonders neue Idee, und Sie können sie in nahezu jeder modernen Sprache machen, und Ideen müssen nicht neu sein, um interessant zu sein. Es ist auch eine gute Fähigkeit zu haben.

Angesichts dessen ist die funktionale Programmierung nur ein Pfeil in Ihrem Köcher, nicht der einzige, genauso wie OOP nicht der einzige ist.

Mein Rindfleisch an der Informatik-Akademie ist das Fehlen eines praktischen Zusammenspiels mit der Industrie, um festzustellen, was in der Praxis Sinn macht, dh die Qualitätskontrolle. Wenn diese Qualitätskontrolle vorhanden wäre, könnte es eine andere Betonung geben, nämlich die Klassifizierung von Problemen und deren Lösungsmöglichkeiten mit Kompromissen und nicht nur mit den neuesten Bandwaggons.

Mike Dunlavey
quelle
1
Das ist ein wirklich guter Kommentar. +1 auf Pfeile in Ihrem Köcher und Lösungsbereiche mit Kompromissen.
user21007
2
+1 für QC. Dieser MSc wäre bei speziellen Themen wie Testen, Codeüberprüfung, Codekomplexität und Ähnlichem viel nützlicher gewesen. In der Lage zu sein, automatisch zu überprüfen, ob ein Programm nach dem letzten Patch das tut, was es sollte, ist eine beliebige Anzahl von "es sollte jetzt funktionieren" -Handwellen-Kauderwelschen wert.
10.
5
@ l0b0: Danke, obwohl ich eigentlich über die Qualitätskontrolle nachgedacht habe, was unterrichtet wird und wie. So wie es ist, lehren CS-Professoren nur, was sie persönlich am interessantesten finden. Vergleichen Sie das mit dem Ingenieurwesen, wo es ein Zusammenspiel mit der Industrie gibt, oder mit der Medizin, wo die Relevanz für die Praxis sehr hoch ist. IME, CS Profis gehen davon aus, dass die reale Welt das lehrt, worauf es in der realen Welt ankommt, aber die Schüler sind nicht darauf aus, etwas zu lernen - sie sind vielmehr darauf bedacht, zu propagieren, worüber die Profis am meisten aufgeregt waren.
Mike Dunlavey
@ Mike: so ziemlich jede moderne Sprache? Beziehen Sie C ++ und Java mit ein?
Kevin Cline
+1. Ich hätte es nicht besser sagen können.
Riwalk
25

Weil das größte Problem in der Softwareentwicklung heutzutage die Fähigkeit ist, mit Komplexität umzugehen. Dies ist nicht der Schwerpunkt der meisten funktionalen Programmiersprachen. Als solche neigen Sprachen, die dies zu einer Priorität machen (namentlich die populäreren OOP-Sprachen), dazu, nur einige der cooleren Funktionen zu stehlen, die aus den akademischeren funktionalen Sprachen hervorgehen, und so an der Spitze zu bleiben.

Fischtoaster
quelle
48
Ich stimme dir nicht zu. Funktionale Programmiersprachen versuchen, die Verwendung eines Zustands zu minimieren und dadurch weniger komplex zu werden. Programme, die in einer funktionalen Sprache programmiert sind, lassen sich auch einfacher testen und umgestalten.
Jonas
7
@Jonas: Vielen Programmierern fällt es extrem schwer, ein Programm ohne Status zu schreiben (auch mir). Aus dieser Sicht ist es tatsächlich komplexer. (Bitte beachten Sie, dass ich die Nützlichkeit der funktionalen Programmierung in keiner Weise diskutiere!)
ShdNx
3
@ShdNx: Ja, ich weiß. Sogar ich dachte, funktionale Programmierung sei schwierig, als ich sie an der Universität zum ersten Mal lernte. Aber nach einer Weile zog ich es dem imperativen Programmieren und spezifischeren OOP vor. An meiner Universität wurde funktionale Programmierung vor imperativer Programmierung unterrichtet, und Studenten, die vor der Universität keine Programmierung durchgeführt hatten, hielten imperative Programmierung anfangs für sehr schwierig und funktionale Programmierung für mathematischer Natur.
Jonas
16
Es gibt einen Unterschied zwischen Schwierigkeit und Komplexität. OOP ist definitiv schwieriger als strukturierte Programmierung, weil es mehr Konzepte hinzufügt. Bei ausreichend großen Codemengen reduzieren sie die Komplexität, indem sie dem Code eine Struktur geben. FP ist dasselbe: Wenn Sie nur zwei Zeilen schreiben, scheint es übertrieben, aber wenn Ihr Code groß genug ist, verbessert die Strukturierung von Code als zustandslose Untereinheiten die Skalierbarkeit und verringert die Komplexität des Codes.
Muhammad Alkarouri
6
Einer der Hauptschwerpunkte der funktionalen Programmierung ist die Kompositionsfähigkeit. Wenn das kein Werkzeug zum Verwalten von Komplexität ist, weiß ich nicht, was es ist.
dan_waterworth
23

Die funktionale Programmierung fängt definitiv an, sich durchzusetzen - langsam aber sicher.

Das Startup, das ich baue, verwendet beispielsweise aus den folgenden Gründen eine funktionale Sprache (Clojure) als primäre Entwicklungssprache:

  • Produktivität - FP zu lernen ist schwer, aber wenn man erst einmal den Dreh raus hat, ist es sehr schwer, an Kraft und Ausdruckskraft zu gewinnen. Ich schreibe wahrscheinlich ungefähr 1/10 der Anzahl der Zeilen, um eine bestimmte Funktionalität zu implementieren, verglichen mit dem, was ich in C # oder Java benötigt hätte

  • Zuverlässigkeit - reine Funktionen lassen sich viel einfacher beurteilen und testen als zustandsbehaftete Objekte. So können Sie viel einfacher bessere Tests schreiben und die Richtigkeit Ihres Codes überprüfen.

  • Parallelität - Funktionssprachen betonen die Unveränderlichkeit, was enorme Vorteile für gleichzeitige Anwendungen hat, als auf mehreren Kernen effektiv ausgeführt zu werden. Und ob es Ihnen gefällt oder nicht, das Laufen auf mehreren Kernen ist die Zukunft. Siehe http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey für eine brillante Erklärung, warum dies so wichtig ist

  • Zusammensetzbarkeit / Modularität - funktionale Sprachen bieten sich an, um Komponenten einfacher zusammenzufügen als komplexe OO-Systeme. Ich habe immer noch nicht alle Gründe dafür herausgefunden, aber ein Teil davon rührt von der Tatsache her, dass Sie nicht die ganze "zufällige Komplexität" haben, die OO-Modelle mit sich ziehen. Der Vortrag von Stuart Halloway über Radical Simplicity untersucht diese Ideen viel eingehender.

BEARBEITEN : Als Reaktion auf Despertars Kommentar ist ein Beispiel für die "zufällige Komplexität" von OOP-Systemen, die die Modularität einschränkt, das Problem des tiefen Klonens im Vergleich zum flachen Klonen: Sie können Objekte nicht zusammensetzen und als zusammengesetzte Strukturen weitergeben, ohne eine sehr sorgfältige Analyse der Klonierungs- und Mutationssemantik. In kleinen Fällen ist dies beherrschbar, in komplexen Systemen wird es jedoch schnell zu einem signifikanten Problem. Dieses Problem besteht nicht in erster Linie, wenn Sie sich auf reine funktionale Datenstrukturen verlassen.

mikera
quelle
+1, ich wäre sehr daran interessiert, Ihren Entscheidungsprozess zu erfahren, warum Sie sich für Clojure entschieden haben. (Ich bin nicht für oder gegen Clojure, ich bin nur interessiert).
dan_waterworth
4
"FP lernen ist schwer": Ein Paradigma zu lernen ist schwer. Ich erinnere mich, wie viele Stunden ich mit imperativem Code (Pascal) verbracht habe, bevor ich genug Erfahrung hatte, um einigermaßen produktiv zu sein. Ich denke, FP ist weniger bekannt, weil viele Programmierer zuerst eine imperative Sprache gelernt haben und nachdem sie erst einmal gelernt hatten, wie man programmiert, hatten sie keine Zeit, sich etwas anderes anzuschauen. Ich bin ein Vollzeit-C ++ - Programmierer und lerne derzeit am Abend nach der Arbeit Scala. Wenn ich eine Familie hätte, um die ich mich kümmern müsste, könnte ich das einfach vergessen.
Giorgio,
1
Ich denke, die ersten 3 sind großartige Fälle, aber ich bin nicht einverstanden mit der 4.. OOP ist extrem modular und kompositorisch; Für mich ist dies eine der größten Stärken. Es ist auch großartig, Komplexität durch Verkapselung und Abstraktion zu verbergen.
Despertar
1
@ Giorgio. Genau. "FP zu lernen ist schwer, OOP zu lernen ist einfach" ist so absurd wie "Spanisch zu lernen ist schwer, aber Chinesisch ist einfach". Es kommt darauf an, welche deine Muttersprache war. Und ich habe Chinesisch nicht als willkürliches Analogon zu OOP gewählt - weil OO-Redewendungen wie Hieroglyphen sind: einfach zu lernen, aber schwer zu merken und unmöglich zu komponieren. FP ist viel mehr wie eine Sprache mit einem Alphabet: getrennte Buchstaben sind für sich genommen nutzlos, erlauben aber, alles mit einigermaßen kleinen Regeln zu komponieren
KolA
1
(Fortsetzung) Warum ist es aus den gleichen Gründen noch nicht beliebt? Hieroglyphen existierten lange bevor das erste Alphabet erfunden und gereift wurde. Vielleicht
braucht
12

Mangel an Killer-App

Hey, der hier sieht frisch aus. (dig dig dig)

Ich denke, dass die meisten Programmiersprachen mit einer "Killer-App" gediehen sind - etwas, das die Sprache ausschließt (oder so betrachtet). Dies soll nicht heißen, dass die gesamte Akzeptanz dieser Anwendung zu verdanken war , sondern dass sie die Sprache zu einer größeren Akzeptanz geführt hat.

Hier ist meine nicht sonderlich genaue Vorstellung davon, welche Nische die Akzeptanz einiger der Sprachen, die wir heute haben, vorangetrieben hat:

  • C: Funktioniert überall (Dies war in den späten 70ern und 80ern)
  • C ++: GUI-Frameworks (Anfang der 90er Jahre)
  • Java: Applets und Servlets (Ende der 90er Jahre)
  • Ziel-C: iOS-Apps (Vorher OS X-Apps)
  • Ruby: Schienen
  • C #: ASP.NET, WinForms
  • PHP: Wordpress usw.
  • Javascript: AJAX, insbesondere über Frameworks
  • lua: Game Scripting, insbesondere WoW

Abgesehen davon haben viele proprietäre Sprachen durch leistungsstarke Vertriebsorganisationen (Oracle und in geringerem Maße auch Microsoft-Sprachen) Eingang gefunden und so effektiv ihre eigene Nische geschaffen.

Ein sehr wichtiger Hinweis zu dieser Liste: Die "Nische" der Sprache, wie sie in der Killer-App angezeigt wird, wird im Laufe der Jahrzehnte immer spezifischer. Beachten Sie den letzten Eintrag in der Liste: Game Scripting . Es wird für Sprachen immer schwieriger, Aufmerksamkeit zu erregen, da eine Liste von Dingen bereits von einer anderen Sprache gut genug erledigt wird.

Was also jede funktionale Sprache braucht, um sich wirklich zu verbessern, ist eine Nische. In Wirklichkeit gibt es noch keine großen funktionalen Sprachen, aber es gibt eine ganze Menge in kleineren Nischen:

  • Emacs Lisp: Ständige Verwendung seit den 80er Jahren in Emacs durch Entwickler. ( Kaum irgendwo anders verwendet.)
  • Erlang: Überall, wo Sie viele Agenten gleichzeitig haben möchten.
  • Schema: Bildung
  • APL / J / K: Finanzen (Nennen wir diese Funktionen aus Gründen des Arguments)
  • Common Lisp: "AI" - Dies ist, was die Leute sagen, es wird verwendet, was ein Segen und ein Fluch ist.

Die einzige Hauptsprache, die ich aus dieser Diskussion herausgelassen habe, ist Python. Python hat etwas sehr Interessantes gemacht; Es ist gelungen, ohne in einer großen Nische als Sieger hervorzutreten. Dies könnte bedeuten, dass ich absolut falsch liege, wenn ich die Popularität der Sprache auf diese Weise betrachte. Es könnte auch bedeuten, dass eine Sprache, die gut genug ist , ohne eine Killer-App populär wird, um Akzeptanz und Akzeptanz zu fördern, aber es ist sehr schwierig und kann sehr lange dauern. (Perl hat eine ähnliche Geschichte, kam aber einige Jahre früher und hat jetzt weniger Akzeptanz.)

Daraus kann ich ableiten, welche funktionalen Sprachen meiner Meinung nach auf dem Vormarsch sind:

  • Clojure: Webprogrammierung, insb. durch Heroku
  • Scala: Lift (oder heutzutage vielleicht Play) - JVM ohne Java

Wenn Sie mich fragen, wo ich als Nächstes nach gängigen funktionalen Sprachen suchen soll, würde ich sagen, dass ich nach einer funktionalen Sprache mit schlüsselfertiger Cloud-Entwicklung (a la Heroku oder GAE) oder schlüsselfertiger mobiler App-Entwicklung Ausschau halten soll.

Jesse Millikan
quelle
Ich würde Perl auch als Hauptsprache betrachten. Ich würde sagen, dass es sich um eine ältere Sprache handelt, die am häufigsten bei Unix-ähnlichen Systemen verwendet wird. Obwohl Python eine modernere Alternative zu sein scheint. Es ist immer noch eine beliebte Sprache, die viel Beachtung gefunden hat und eine große Community hat.
Despertar
1
@Despertar - Ich habe mich nicht besonders bemüht, egalitär zu sein, welche Sprachen ich erwähnte :) Und ich stimmte zu, dass die Geschichte Python sehr ähnelt, außer ein paar Jahren in der Vergangenheit.
Jesse Millikan
1
Perl hatte ein paar Nischen. Die früheste fand sich in älteren Versionen der Dokumentation wieder, in denen der Name als Akronym für "praktische Extraktions- und Berichterstattungssprache" bezeichnet wurde. Die zweite kam etwas später und war CGI-Scripting - für viele Jahre war Perl die Sprache des Webs. Offensichtlich hat es jetzt viel an Popularität verloren, aber werfen Sie einen Blick auf alte Websites, die immer noch mit derselben Software laufen, mit der sie ursprünglich erstellt wurden, und Sie werden eine Menge Perl sehen (ich denke gerade an slashdot.org) , aber es gibt noch einige mehr).
Jules
8

Aus dem gleichen Grund, den Lisp nie wirklich verstanden hat (lass die Flammenkriege beginnen!). Funktionale Programmierung ist ein sehr fremdes Paradigma im Vergleich zu imperativer und objektorientierter Programmierung. Wenn Sie, wie die große Mehrheit der CS-Studenten, mit C begonnen und zu C ++ / Java übergegangen sind, möchten Sie nicht lernen, auf eine Weise zu denken, die völlig orthogonal zu der Art ist, wie Sie normalerweise denken.

Chinmay Kanchi
quelle
2
Alien-Paradigma? Es ist der Mathematik näher als die imperative Programmierung. Hier in Schweden denke ich, dass die meisten CS-Studenten an der Universität zuerst die funktionale Programmierung studieren. ZB haben wir mit Standard ML begonnen, vor C, Erlang und Java.
Jonas
4
Fair genug. Ich weiß, dass viele Ingenieurstudenten in Großbritannien und Indien zuerst in C unterrichtet werden, gefolgt von C ++ und / oder Java. Oft wird ihnen überhaupt keine funktionale Sprache beigebracht.
Chinmay Kanchi
13
@Jonas Für eine Reihe von Leuten da draußen ist Mathematik ein fremdes Paradigma und alles, was die Programmierung weiter von der Mathematik entfernt, erleichtert das Verständnis.
Scriptocalypse
5
Ich habe von Leuten gehört, die noch nie von Bäumen gehört haben, geschweige denn von der Funktionsprogrammierung, die ihren Abschluss gemacht haben.
Dan_waterworth
1
@ Tux-D, eigentlich nein, ich spreche über Studenten in Großbritannien.
Dan_waterworth
6

Betrachten wir Unternehmen und Programmierung.

Es gibt Unternehmen, die ihre Software als strategisches Kapital einsetzen. Das ist nicht typisch. Für die meisten Unternehmen unterstützt die IT das eigentliche Geschäft des Unternehmens. Es ist eine notwendige Ausgabe. Sie sind konservativ, weil sie wissen, dass sie für $ X die IT bekommen können, die sie benötigen, und wenn sie auf etwas anderes wechseln, sparen sie weniger als $ X, wenn alles gut läuft, und verlieren sehr viel, wenn alles schlecht läuft.

Darüber hinaus ist das günstigste, was in Unternehmen zu tun ist, normalerweise das, was sie gestern getan haben. Eine Änderung ist jedoch wünschenswert und teuer. Wenn ein Unternehmen beispielsweise von einer C # /. NET-Lösung zu einer F # -Lösung wechseln würde, hätte es Probleme. Ihre Programmierer (die wahrscheinlich nicht die schärfsten Programmierer sind) müssten eine neue Sprache lernen, beide beherrschen und beide häufig verwenden. In beiden würde es lange Zeit Routinen geben. Wenn sie zu etwas wie Haskell wechseln oder C ++ / MFC verwenden würden, würden sie sich viel mehr ändern, und das wäre viel teurer.

Außerdem wird es noch lange Zeit eine Reihe von C # -Programmierern und Microsoft-Support geben. Auf die derzeitigen IT-Praktiken kann man zählen. Es gibt nicht das gleiche Maß an institutioneller Unterstützung oder Zusicherung, dass Programmierer weiterhin verfügbar sind.

Daher wäre eine Änderung der funktionalen Programmierung für die meisten Unternehmen von vornherein teuer, und sie macht sich nur bezahlt, wenn die Reduzierung der IT-Kosten auf lange Sicht ausreicht, mit der Ausnahme, dass auf lange Sicht möglicherweise Bedenken bestehen.

David Thornley
quelle
2

Sie schreiben bereits Code im funktionalen Stil, kennen ihn aber nicht.

Wenn Sie für Ihren Code Komponententests durchführen müssen, tendieren Sie dazu, testbare Funktionen zu schreiben, die keine Nebenwirkungen hervorrufen oder von diesen abhängen und immer dasselbe Ergebnis mit denselben Argumenten (so genannten reinen Funktionen) zurückgeben. Dies ist der Hauptvorteil von Funktionsprogrammen.

Ich denke, funktionale Sprachen sind zu einschränkend. Anstatt imperative Sprachen durch funktionale zu ersetzen, erhalten imperative Sprachen funktionale Merkmale. Heutzutage hat fast jede Programmiersprache Closures und Lambdas.

Calmarius
quelle
1

Ich glaube, es gibt nur eine echte Antwort auf Ihre Frage. Sie können auf viele verwandte Gründe stoßen, warum dies der Fall ist, aber das sind unterschiedliche Fragen.

Hier ist es:

  • Softwarearchitekten bieten Lösungen, von denen sie überzeugt sind, dass sie funktionieren.
  • Die Mehrheit der Architekten arbeitet nicht in funktionalen Sprachen.
  • Sobald Technologien und Sprachen ausgewählt sind, finden Unternehmen Menschen, die mit ihnen arbeiten können.

Fängt es an? Das hängt alles davon ab, ob Menschen, die mit funktionalen Sprachen vertraut sind, Architekten werden und diese für die Projekte verwenden, an denen sie arbeiten.

John Fisher
quelle
0

Das eigentliche Problem ist der Zustand.

Funktionale Sprachen haben keinen globalen Status. Die meisten industriellen Probleme erfordern einen Status im großen Maßstab (wie stellen Sie ein Ledger oder eine Gruppe von Transaktionen dar), auch wenn einige Funktionen im kleinen Maßstab dies tatsächlich nicht erfordern (Verarbeitung eines Ledgers).

Wir führen jedoch Code auf Maschinen mit Von-Neuman-Architektur aus, die inhärent staatlich voll sind. Wir haben also den Staat nicht wirklich losgeworden, die funktionalen Sprachen verbergen dem Entwickler nur die Komplexität des Staates. Dies bedeutet, dass Sprache / Compiler mit dem Status hinter den Kulissen umgehen und ihn verwalten müssen.

Obwohl funktionale Sprachen keinen globalen Status haben, werden ihre Statusinformationen als Parameter und Ergebnis übergeben.

Die Frage ist also, ob die Sprache den Staat hinter dem Sinn effizient handhaben kann. Insbesondere wenn die Datengröße die Größe der Architektur bei weitem übersteigt.

Betrachtet man es von der Hardware-Seite

Das Betriebssystem hat in den letzten Jahren viel dazu beigetragen, den Adressraum zu visualisieren, sodass sich Anwendungen offiziell nicht darum kümmern müssen. Aber Anwendungen, die sich keine Sorgen machen, geraten in die Falle, die Hardware zu zerstören, wenn der Speicherdruck zu hoch wird (wenn Hardware zerstört wird, werden Ihre Prozesse langsam kriechen).

Da der Programmierer keinen direkten Einfluss auf den Status in der funktionalen Sprache hat, muss er sich darauf verlassen, dass der Compiler dies erledigt, und ich habe keine funktionalen Sprachen gesehen, die dies gut beherrschen.

Auf der Gegenseite der Münze hat der zustandsreiche Programmierer eine direkte Kontrolle über den Zustand und kann so niedrige Speicherbedingungen ausgleichen. Obwohl ich nicht viele Programmierer gesehen habe, die schlau genug sind, dies zu tun.

Betrachtet man von der Branchenseite:

In der Industrie gibt es viele ineffiziente staatliche Programmierer.

Es ist jedoch einfach, Verbesserungen in diesen Programmen im Laufe der Zeit zu messen. Sie werfen ein Team von Entwicklern auf das Problem, dass sie den Code verbessern können, indem sie den Status des Programms verbessern.

Bei funktionalen Programmen ist es schwieriger, die Verbesserungen zu messen, da Sie die Tools zur Verbesserung der Programme verbessern müssen (wir betrachten nur, wie Anwendungen den zugrunde liegenden Status effizient handhaben, nicht die allgemeine Verbesserung des Programms).

Für die Industrie kommt es meiner Meinung nach auf die Fähigkeit an, Verbesserungen im Code zu messen.

Aus Sicht der Einstellung

Es gibt viele stat-volle Programmierer, die gemietet werden können. Funktionale Programmierer sind schwer zu finden. Ihr grundlegendes Angebots- und Nachfragemodell würde sich also durchsetzen, wenn die Industrie auf funktionales Programmieren umsteigen würde, und das ist nicht das, was sie wollen (Programmierer sind so teuer genug).

Martin York
quelle
2
Funktionssprachen, insbesondere "unreine" Funktionssprachen, können mit dem globalen Zustand einwandfrei umgehen. Ich finde, dass sich Programme oft in abwechselnde Ebenen aufteilen: zB globaler Zustand ... aber funktionale Zustandsübergänge ... mit gelegentlichem lokalen (maskierten) Zustand, um leistungskritische Teile dieser Übergänge usw. zu implementieren. Das Problem mit imperativen Sprachen, IMO ist, dass sie Programmierer oft dazu veranlassen, den Status unangemessen zu verwenden, wenn Funktionsmuster besser funktionieren würden. Die Sprachen scheinen sich jedoch dahingehend zu entwickeln, dass sie beide Stile gut unterstützen.
Ryan Culpepper
1
Es ist sehr einfach, mit Zuständen in funktionalen Sprachen umzugehen, aber es erfordert eine Verschiebung der Betonung. Während Sie in imperativen Sprachen Prozeduren schreiben, die den Status ändern, schreiben Sie in funktionalen Sprachen Funktionen, die Prozeduren zurückgeben, die den Status ändern.
dan_waterworth
"Funktionale Sprachen haben keinen globalen Status" - Sie benötigen keinen globalen Status. Fast alle Staatsverwaltung kann durch Monaden erfolgen.
Arunav Sanyal
-3

Diese Frage hat etwas falsche Prämisse. Aus den folgenden Gründen:

  1. Funktionale Programmierung ist in der Industrie eigentlich ziemlich verbreitet. Es wird jedoch nur verwendet, wenn erfahrene Programmierer verfügbar sind. Anfänger können nicht erwarten, dass sie es wissen. Fast alle großen Programmierprojekte verwenden es, aber sie bewahren es nur in Bereichen auf, die von erfahrenen Programmierern bearbeitet werden. Anfänger werden sich mit den einfachen Modulen befassen, die keine funktionale Programmierung erfordern.
  2. Angesichts dieser Realität können Unternehmen, die Leute einstellen (normalerweise junge Leute von der Universität), nicht wirklich nach funktionaler Programmiererfahrung fragen. Wer in Projekten funktionale Programmierung benötigt, ist bereits seit 15 Jahren im selben Unternehmen.
  3. Universitäten fangen an, es zu unterrichten, weil sie bereits jetzt wissen, dass funktionale Programmierkenntnisse in 30 Jahren sehr nützlich sein werden. Ihre Zeitspanne beträgt 30 Jahre, nicht das normale halbe Jahr wie in Unternehmen.
  4. Diese Punkte sind der Grund, warum die Menschen enttäuscht sind, wenn sie in die Arbeitswelt eintreten und feststellen, dass die Dinge, die sie an der Universität gelernt haben, nicht verwendet werden. Aber sie wurden für eine Zeitspanne von 30 Jahren entwickelt, und es wird irgendwann nützlich sein - es ist nur so, dass Unternehmen die einfachen Dinge verwenden - die Dinge, von denen sie erwarten können, dass sie die Leute kennen.
  5. Sie wären auch arrogant, wenn Sie denken, dass Sie nach ein paar Jahren Universität die funktionale Programmierung gut genug kennen, um sie in tatsächlichen Softwareprojekten zu verwenden. Beginnen Sie zuerst mit den einfachen Dingen. Sie müssen nicht unbedingt die komplexeste Software als erste Aufgabe ausführen, wenn Sie mit der Arbeit beginnen. Sie werden schließlich zu den komplexen Sachen kommen, aber es braucht Zeit.
tp1
quelle
2
1) "Fast alle großen Programmierprojekte verwenden es". Ich habe die Erfahrung gemacht, dass dies alles andere als real ist. Sehr wenige Unternehmen verwenden funktionale Programmierung als das, was ich weiß. Die meisten verwenden nur Java und C # (obwohl C # in den letzten Jahren mehr funktionale Konstrukte hatte), C ++ und C.
Jonas
2
2) Meine Erfahrung ist das Gegenteil. Menschen von Universitäten scheinen die einzigen zu sein , die sich mit funktionaler Programmierung auskennen. Hier in Schweden unterrichten die meisten Universitäten ab dem ersten Jahr funktionale Programmierung. Und Universitäten wie das MIT haben in ihrem ersten Programmierkurs (Schema) bis vor kurzem funktionale Programmierung eingesetzt.
Jonas
@jonas: nein, die programmiersprache hat nichts damit zu tun. Natürlich wird C und C ++ und Java usw. von einer großen Anzahl von Projekten verwendet. Die funktionale Programmierung funktioniert auch in C ++ - Code. Die derzeitige Praxis scheint zu sein, dass ein Teil des Projekts OO und ein Teil funktionale Programmierung verwendet. Beide Teile verwenden dieselbe Sprache (normalerweise c / c ++)
tp1
Ja, du könntest OO auch in C machen. Aber es wird nicht empfohlen. C und C ++ haben nicht viele Konstrukte für die funktionale Programmierung, zB nicht standardmäßig unveränderlich, keine gute Unterstützung für den Mustervergleich, keine enthaltenen unveränderlichen Datenstrukturen und so weiter ...
Jonas
Deshalb sind erfahrene Programmierer erforderlich. Da es so gut wie unmöglich ist, die Programmiersprache von den Standard-Programmiersprachen zu unterscheiden, ist es das nächstbeste, funktionale Programmierung in c ++ durchzuführen. Auch C ++ hat Dinge wie const, die sehr helfen.
tp1
-10

Weil es schwieriger ist, FP zu debuggen.

interstar
quelle
11
Ich stimme dir nicht zu. Ohne Nebeneffekte ist der Debug-Prozess einfacher. Vielleicht denken Sie, dass es schwieriger ist, weil das Funktionsparadigma anders ist und Erfahrung benötigt, um sich mit neuen Methoden, einschließlich Debugging, vertraut zu machen.
Maniero
2
Funktionale Programmiersprachen sind tatsächlich einfacher zu testen, da reine Funktionen zustandslos sind.
Jonas
4
Jonas, ich habe nicht "test" gesagt, sondern "debug". Finde einen Fehler, den du gemacht hast. Testen ist ein Teil davon, aber auch die Argumentation über das Programm usw. ist groß - ich stehe dazu. Es ist eine Funktion der Leistung von FP. Je mehr Arbeit eine bestimmte Codezeile leistet, desto schwerer ist es zu erkennen, welche Codezeile ein Problem verursacht. Die Zuordnung zwischen Codezeile und Effekt ist diffuser, z. Eine einzelne Funktion höherer Ordnung kann Dutzende von Verhaltensweisen des Programms berühren und umgekehrt. Die Symptome können zwischen verschiedenen Punkten für den gleichen Fehler stark variieren.
Interstar
Nach meiner Erfahrung ist es überhaupt nicht schwer zu debuggen. Ich verwende F # und kann keinen Grund finden, warum das Debuggen für Sie schwieriger ist als beispielsweise C #. Möglicherweise ist das Debuggen in Haskell aufgrund der Faulheit schwieriger (ich habe keine Ahnung), aber eifrige FP-Programmierung ist einfacher, weil es keinen Status gibt, wie Jonas sagte. Mit anderen Worten, FP-Code ist vorhersehbarer, da Sie wissen, dass das Ergebnis nicht von unsichtbaren Variablen beeinflusst wird.
Muhammad Alkarouri
2
Solange Ihre Funktionen rein sind, ist das Debuggen einfach. Wenn Sie durch Hinzufügen von Komponententests kein Debugging durchführen können, können Sie keine ausreichenden Tests schreiben.
Dan_waterworth