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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

Weil es schwieriger ist, FP zu debuggen.