it-swarm-eu.dev

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

Während meiner vier Jahre an der Universität haben wir viel funktionale Programmierung in mehreren funktionalen Programmiersprachen verwendet. Aber ich habe auch viel objektorientierte Programmierung 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 oft, ich würde bei diesen Projekten in einer funktionalen Programmiersprache programmieren.

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

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

61
Jonas

Ich würde sagen, dass einer der Gründe dafür, dass funktionale Programmierung nicht häufiger vorkommt, das Fehlen einer Wissensbasis ist. Ich habe die Erfahrung gemacht, dass Unternehmen in Bezug auf die Implementierung von Technologien, die nicht zum Mainstream gehören, sehr risikoscheu sind und lieber in bewährte Frameworks (Java, c ++, c #) investieren möchten. Nur wenn ein Geschäftsbedarf besteht (wie bei Ericsson), werden neue Paradigmen berücksichtigt. Aber selbst in Ericssons Fall hörte ich, dass das Management die Verwendung von c ++ verlangte und Joe Armstrong gezwungen war, erlang-Aufrufe in c ++ zu codieren !! Dies sollte zeigen, wie ungern Unternehmen neue Technologien implementieren!

38
ennuikiller

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

Funktionale Programmierung ist so ein Zug. Sicher, es gibt viele nette 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 ausführen, und Ideen müssen nicht neu sein, um interessant zu sein. Es ist auch eine gute Fähigkeit zu haben.

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

Mein Problem mit der Informatik-Akademie ist das mangelnde praktische Zusammenspiel mit der Industrie, um festzustellen, was in der Praxis tatsächlich Sinn macht, d. H. Die Qualitätskontrolle. Wenn diese Qualitätskontrolle vorhanden wäre, könnte es einen anderen Schwerpunkt geben, Probleme und deren Lösungsbereiche mit Kompromissen zu klassifizieren, anstatt nur die neuesten Bandwaggons.

67
Mike Dunlavey

Denn das größte Problem bei der Softwareentwicklung ist heutzutage die Fähigkeit, die Komplexität zu verwalten. Dies ist nicht der Schwerpunkt der meisten funktionalen Programmiersprachen. Als solche neigen Sprachen, die do zu einer Priorität machen (nämlich die populäreren OOP Sprachen)) dazu, nur einige der cooleren Funktionen zu stehlen, die aus den akademischeren hervorgehen funktionale Sprachen und bleiben so auf dem Laufenden.

25
Fishtoaster

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

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

  • Produktivität - Lernen FP ist schwer, aber sobald Sie den Dreh raus haben, ist es sehr schwer zu schlagen Ich schreibe wahrscheinlich ungefähr 1/10 der Anzahl von 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 sind viel einfacher zu überlegen und zu testen als zustandsbehaftete Objekte. Daher können Sie viel einfacher bessere Tests schreiben und die Richtigkeit Ihres Codes überprüfen.

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

  • Kompositionsfähigkeit/Modularität - Funktionssprachen scheinen sich dazu zu eignen, Komponenten leichter zusammenzufügen als komplexe OO Systeme. Ich immer noch Ich habe 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 herumschleppen. Das Gespräch on Radical Simplicity von Stuart Halloway untersucht diese Ideen viel ausführlicher.

[~ # ~] edit [~ # ~] : Als Antwort auf Despertars Kommentar ein Beispiel für die "zufällige Komplexität" von OOP Systeme, die die Modularität einschränken, sind die Probleme beim tiefen Klonen im Vergleich zum flachen Klonen: Sie können Objekte nicht zusammensetzen und als zusammengesetzte Strukturen weitergeben, ohne die Semantik des Klonens und der Mutation sehr sorgfältig zu analysieren. In kleinen Fällen ist überschaubar, aber in komplexen Systemen wird es schnell zu einem erheblichen Problem. Dieses Problem tritt überhaupt nicht auf, wenn Sie sich auf reine funktionale Datenstrukturen verlassen.

24
mikera

Fehlende Killer-App

Hey, dieser hier sieht frisch aus. (Dig dig Dig)

Ich denke, die meisten Programmiersprachen lebten von einer "Killer-App" - etwas Überzeugendes, das exklusiv für die Sprache war (oder so gesehen wurde). Dies bedeutet nicht, dass die gesamte Aufnahme diese Anwendung war, sondern dass dies die Sprache zu einer größeren Akzeptanz führte.

Hier ist meine nicht besonders genaue Ansicht darüber, welche Nische die Übernahme einiger der Sprachen, die wir heute haben, vorangetrieben hat:

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

Abgesehen davon sind viele proprietäre Sprachen durch leistungsstarke Vertriebsorganisationen (Oracle und in geringerem Maße die Sprachen von Microsoft) in die Tür gelangt und haben effektiv ihre eigene Nische geschaffen.

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

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

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

Die einzige wichtige Sprache, die ich aus dieser Diskussion herausgelassen habe, ist Python. Python hat etwas sehr Interessantes getan; es ist gelungen, ohne der Gewinner in einer größeren Nische zu sein. Dies könnte Das bedeutet, dass ich völlig falsch liege, wenn ich die Popularität von Sprachen auf diese Weise betrachte. Es könnte auch bedeuten, dass eine ausreichend gute Sprache ohne eine Killer-App populär werden kann Adoption und Akzeptanz voranzutreiben, 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 vielleicht heutzutage spielen) - JVM ohne Java

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

12
Jesse Millikan

Aus dem gleichen Grund, den LISP nie wirklich verstanden hat (lassen Sie die Flammenkriege beginnen!). Funktionale Programmierung ist im Vergleich zur imperativen und objektorientierten Programmierung ein sehr fremdes Paradigma. Wenn Sie, wie die große Mehrheit der CS-Studenten, mit C angefangen haben und zu C++/Java übergegangen sind, möchten Sie in der Regel nicht lernen, auf eine Weise zu denken, die völlig orthogonal zu Ihrer normalen Denkweise ist.

9
Chinmay Kanchi

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. Wenn sie zu etwas anderem wechseln, sparen sie weniger als $ X, wenn alles gut läuft, und verlieren wirklich viel, wenn alles schlecht läuft.

Darüber hinaus ist es in Unternehmen in der Regel am billigsten, das zu tun, was sie gestern getan haben. Änderungen sind jedoch wünschenswert und teuer. Wenn ein Unternehmen beispielsweise von einer C # /. NET-Lösung zu F # wechseln würde, hätte es Probleme. Ihre Programmierer (die wahrscheinlich nicht die schärfsten Programmierer da draußen 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 würden oder wenn sie überhaupt 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 C # -Programmierer und Microsoft-Support geben. Auf die gegenwärtigen IT-Praktiken kann man zählen. Es gibt nicht das gleiche Maß an institutioneller Unterstützung oder Zusicherung einer kontinuierlichen Verfügbarkeit von Programmierern.

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

6
David Thornley

Sie schreiben bereits Code im funktionalen Stil, wissen es aber nicht.

Wenn Sie Unit-Tests für Ihren Code durchführen müssen, schreiben Sie in der Regel testbare Funktionen, die keine Nebenwirkungen verursachen oder von diesen abhängen, und geben immer dasselbe Ergebnis mit denselben Argumenten zurück (sogenannte reine Funktionen). 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 Verschlüsse und Lambdas.

2
Calmarius

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

Hier ist es:

  • Softwarearchitekten bieten Lösungen an, von denen sie überzeugt sind, dass sie funktionieren.
  • Die meisten Architekten arbeiten 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.

1
John Fisher

Das eigentliche Problem ist der Zustand.

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

Wir führen jedoch Code auf Von-Neuman-Architekturmaschinen aus, die von Natur aus voll sind. Wir haben also den Status nicht wirklich losgeworden, die funktionalen Sprachen verbergen nur die Komplexität des Status vor dem Entwickler. Dies bedeutet, dass Sprache/Compiler sich hinter den Kulissen mit dem Status befassen und ihn verwalten muss.

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

Dann stellt sich die Frage, ob die Sprache den Zustand hinter dem Sinn effizient handhaben kann. Insbesondere wenn die Datengröße die Größe der Architektur bei weitem überschreitet.

Betrachtet man es von der Hardware-Seite

Das Betriebssystem hat in den letzten Jahren viel zur Visualisierung des Adressraums beigetragen, sodass sich Anwendungen offiziell nicht darum kümmern müssen. Anwendungen, die sich keine Sorgen machen, geraten jedoch in die Falle, die Hardware zu beschädigen, wenn der Speicherdruck hoch wird (das Verdrängen der Hardware verlangsamt Ihre Prozesse bis zum Crawlen).

Da der Programmierer keine direkte Kontrolle über den Status in der Funktionssprache hat, muss er sich auf den Compiler verlassen, um dies zu handhaben, und ich habe keine funktionalen Sprachen gesehen, die dies gut handhaben.

Auf der anderen Seite der Münze hat der State-Full-Programmierer eine direkte Kontrolle über den Zustand und kann somit niedrige Speicherbedingungen ausgleichen. Obwohl ich nicht viele Programmierer gesehen habe, die tatsächlich klug genug sind, dies zu tun.

Von der Industrieseite aus betrachtet:

Die Industrie hat viele ineffiziente staatliche Programmierer.

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

Bei funktionalen Programmen sind die Verbesserungen eher schwer zu messen, da Sie die Tools verbessern müssen, mit denen die Programme verbessert werden (wir sehen uns hier nur an, 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 stehen viele statistische Programmierer zur Verfügung. Funktionale Programmierer sind schwer zu finden. Ihr grundlegendes Angebots- und Nachfragemodell würde sich also durchsetzen, wenn die Industrie auf funktionale Programmierung umsteigen würde, und das ist nicht das, was sie wollen (Programmierer sind so teuer wie sie sind).

0
Martin York