Was ist Ihre stärkste Meinung gegen funktionale Programmierung? [geschlossen]

Funktionale Programmierung ist eines der ältesten Programmierparadigmen. Es wird jedoch in der Industrie im Vergleich zu populäreren Paradigmen nicht viel verwendet. Aber es wurde in der Wissenschaft weitgehend betont.

Was ist Ihre stärkste Meinung gegen funktionale Programmierung?

Das Problem ist , dass die meist gemeinsame Code von Natur Zustand beinhaltet - Business - Anwendungen, Spiele, UI, etc. Es gibt kein Problem mit einigen Teilen einer App rein funktional zu sein; Tatsächlich könnten die meisten Apps in mindestens einem Bereich davon profitieren. Aber das Paradigma überall durchzusetzen, fühlt sich kontraintuitiv an.

Das Problem mit der funktionalen Programmierung ist nicht die funktionale Programmierung selbst - es sind die meisten Leute, die dies tun und (noch schlimmer) die meisten Leute, die Sprachen entwerfen, in denen dies getan werden soll.

Das Problem ergibt sich aus der Tatsache, dass viel zu viele der Leute, obwohl sie sehr schlau (manchmal geradezu brillant) sind, ein wenig zu fanatisch in Bezug auf Reinheit, Perfektion und die Durchsetzung ihrer eigenen (oftmals ziemlich engen) Sicht auf die Welt und das Programmieren auf die Welt sind Sprache und jeder, der sie benutzt.

Eines der Ergebnisse ist das Scheitern von Kompromissen. Dies führt (unter anderem) zu ungefähr 10.000 Sprachen und Dialekten, die unterschiedlich genug sind, um zu nerven, aber nur selten genug, um einen wirklich signifikanten Vorteil gegenüber den anderen zu haben. Viele schauen sich auch die reale Welt an und stellen fest, dass sie einfach falsch ist und am besten ignoriert wird, da sie nicht sehr gut zum Funktionsmodell passt.

Die Unfähigkeit, Kompromisse einzugehen, hat auch zu einigen Sprachen geführt, die für eine bestimmte Art von Problem (oder für einige bestimmte Arten von Problemen) absolut schön sind, aber für viele andere wirklich zum Kotzen sind . Ein Teil davon ist wahrscheinlich auf das Funktionsmodell selbst zurückzuführen, aber viel mehr scheint (zumindest für mich) auf den grundlegenden Persönlichkeitstyp zurückzuführen zu sein, der von Anfang an von diesem Bereich angezogen wird.

Das führt zu einer Reihe von Problemen. Erstens ist das Erlernen der "funktionalen Programmierung" meistens von philosophischem Wert. Bei den meisten anderen Arten von Sprachen ist die Kenntnis einer Sprache eines bestimmten Genres eine wichtige Hilfe beim Erlernen einer anderen. Wenn mein Projekt die Sprache X verwendet, kann ich normalerweise jemanden einstellen, der die Sprache Y (aber nicht X) ziemlich sicher beherrscht. Bei funktionalen Sprachen ist das viel weniger der Fall. Sie kennen Erlang vielleicht recht gut, finden aber Haskell-Monaden völlig fremd und unverständlich.

Wenn Sie die Anzahl der Sprachen mit der eingeschränkten Portabilität der Talente kombinieren, entsteht eine hässliche Situation: Es ist fast unmöglich, dass eine Sprache oder ein Dialekt die "kritische Masse" bildet, die erforderlich ist, um einen angemessenen allgemeinen Gebrauch daraus zu machen. Das ist langsam zu ändern, aber es ist immer noch eine Menge , wie Linux das dominierende Desktop - Betriebssystem immer - jedes Jahr Menschen mit überzeugenden Argumenten kommen, die schließlich das sein wird, das Jahr - und ebenso wie die Menschen , die die Vorhersage haben , dass jeder Jahr für Jahrzehnte werden sie wieder falsch liegen. Das soll nicht heißen, dass es (beides) niemals passieren kann - nur, dass die Leute, die sich die Vorhersagen ansehen und "nein, nicht in diesem Jahr" denken, die waren, die bisher Recht hatten.

Ich denke, der Grund, warum funktionale Programmierung nicht sehr verbreitet ist, liegt darin, dass sie Ihnen zu viel im Weg steht. Es ist schwer, zum Beispiel Lisp oder Haskell ernsthaft zu betrachten, ohne zu sagen, "diese ganze Sprache ist eine große Abstraktionsinversion." Wenn Sie Basisabstraktionen festlegen, unter die der Codierer bei Bedarf nicht geraten kann, legen Sie Dinge fest, die die Sprache einfach nicht kann, und je funktionaler die Sprache ist, desto mehr davon hat sie tendenziell.

Nehmen Sie zum Beispiel Haskell. Im Namen der funktionalen Reinheit müssen Sie bahnbrechende Abstraktionsinversionen verwenden, die niemand versteht, um Status und E / A zu verwalten, die beiden grundlegendsten Teile eines jeden Computerprogramms, das mit irgendetwas interagiert! Das wird schnell alt.

Bei allem Respekt denke ich, dass Ihre Frage schlecht gestellt ist. Funktionale Programmierung ist ein Werkzeug oder vielmehr eine Reihe von Werkzeugen, die zur Lösung bestimmter Arten von Problemen nützlich sind. Eine Meinung dazu zu haben, ist nur im Zusammenhang mit einem bestimmten Problem oder einer bestimmten Anwendung sinnvoll. Eine Meinung dagegen zu haben ist wie eine Meinung gegen Zangen oder Schraubenschlüssel.

Selbst wenn ich es gemeistert hätte, wäre ich möglicherweise nicht geneigt, eine funktionale Sprache für ein kommerzielles Produkt zu verwenden, weil sie nicht allgemein verstanden wird. Wenn ich ein Wachstum des Geschäfts erwarten würde, wäre ich besorgt, andere Entwickler zu finden, die dazu in der Lage sind zu pflegen oder im Laufe der Zeit zu erweitern.

Es ist nicht unvorstellbar, und Sie würden wahrscheinlich einen höheren Entwicklerstandard erhalten, da ein Java-Student ohne echte Hacking-Kenntnisse nicht wissen würde, wo er mit einem Projekt dieser Art beginnen soll, aber der begrenzte Pool an fähigen Entwicklern wäre sicherlich eine notwendige Überlegung aus betriebswirtschaftlicher Sicht.

Zeit zum Markt

Es ist schwierig, eine vollständige IT-Landschaft von Verfahrenscode und Mantras zu befreien.

zuallererst akzeptiere ich keines der argumente bezüglich state-ful programming und fp. Wenn Sie sich die staatliche Monade in Haskell ansehen, werden Sie eine Reihe interessanter neuer Möglichkeiten finden, um die Auswirkung des Staates auf Ihren Code zu bewerten.

wenn ich ein aussagekräftiges argument gegen fp machen würde, wäre es, dass das lernen einer seriösen funktionalen sprache wie haskell wie das lernen, ein formelauto zu fahren ... aufregend und lehrreich, aber leider nutzlos für die alltägliche industrielle codierung, weil im durchschnitt Ihre Mitarbeiter fahren Kamera und sind sehr froh, dies zu tun. es ist immer noch extrem schwierig, arbeit in einem fp-freundlichen umfeld zu finden, und ich sehe das nicht anders, wenn man nicht bereit ist, selbst zuzuschlagen oder einige der bekannten fp-praktiker aufzusuchen.

ich nehme an, meine antwort zeigt mich als fp fanboy. ich schlage vor, einer echten fp-sprache wie haskell eine ernste drehung zu geben, bevor ich mir überlege, warum du das nicht tun solltest.

Ich bin ein großer Fan und Verfechter der funktionalen Programmierung. Aber hier sind meine Punkte:

• einfach zu lernen
  Programmiersprachen wie Python und Ruby (und viele andere Sprachen) sind einfach zu lernen. Fortgeschrittene funktionale Programmierung mit Sprachen wie Haskell, Agda, Coq, ATS usw. ist ziemlich schwer zu lernen. Einige verwenden den Begriff "mathematisch strukturierte Programmierung". Es ist einfach, wenn Sie mit Kategorietheorie und abstrakter Mathematik vertraut sind, aber einige Arbeiten, wenn Sie keine Ahnung haben, was zum Beispiel "Monaden" sind.

• Programmieren mit einer Skriptsprache kann zu mehr Produktivität führen.
  In einigen Situationen kann die Verwendung von Skriptsprachen wie Python und Ruby zu mehr Produktivität führen. Dies bedeutet schnelles Prototyping und Zusammenkleben verschiedener Pakete oder Bibliotheken. Auch die Verwendung dynamischer Sprachen (zB dynamische objektorientierte Programmierung) kann in diesem Zusammenhang von Vorteil sein. In der Regel ist statisches Schreiben besser, aber das Schreiben mit dynamischen Typen kann sich positiv auswirken.

• Geschäftliche Überlegungen
  Programmierung ist nur eine kleine Auswahl erfolgreicher Softwareprojekte. Software muss funktionieren, Benutzer müssen glücklich sein und das hängt nicht unbedingt von der verwendeten Programmiersprache ab. Manager müssen bei der Bewertung neuer Technologien und Programmiersprachen die Vorteile und Risiken berücksichtigen. Können neue Programmierer die neue Programmiersprache schnell erlernen? Hat das Unternehmen Erfahrung mit der Technologie? Gibt es ein Risiko und ist dies mit dem oberen Management nur schwer zu diskutieren?

Im geschäftlichen Kontext kann die funktionale Programmierung in Systemen verwendet werden, die die Kernsoftwarekomponenten ergänzen, z. B. Komponenten, die nicht so geschäftskritisch sind. Zum Beispiel eine Bank, die die Kernsoftware kaum ändert, aber neue Teile (GUI, Überwachungssoftware usw.) in einer neuen Programmiersprache hinzufügt. (Vielleicht gibt es Ausnahmen, aber das ist meine Erfahrung mit Banken.)

Darüber hinaus ist die funktionale Programmierung sehr nützlich, wenn eine formale Verifizierung ein Vorteil oder ein Muss ist.

Ich bin nicht gegen FP als nützliches Paradigma, aber ich bin dagegen als das einzige Paradigma, das in einer Programmiersprache verfügbar ist.

Es bietet Vorteile bei der Lösung vieler Probleme. FP kann und wurde jedoch in Verfahrenssprachen wie C angewendet.

1. (und bei weitem das Wichtigste) Die Belegschaft des Programmierers ist nicht in diesen Sprachen oder Stilen geschult
2. Viele der funktionalen Evangelisten kommen als A-Holes oder Obstkuchen heraus, weil sie versuchen, funktional zu verkaufen. Niemand mag ein Loch, und niemand wird Geld hinter einen Obstkuchen werfen. Wohlgemerkt, ich mag die funktionalen Dinge wirklich und würde sie gerne anwenden, aber ich weiß, dass ich an meinem Arbeitsplatz die einzige Person sein würde, die sie entwickeln könnte, ohne Geld für Schulungen auszugeben (harter Verkauf), und fast alles Gute Hinweise beim Leser aufrütteln.

Funktionsfähig wird es sein, wenn wir Hunderte von Kernen haben und feststellen, dass Sperren nicht skalierbar sind. Dann sind parallel geschachtelte Daten der einzige Weg, um "große Eisen" -Programme zu entwickeln, und dies mit herausragenden Funktionen.

FP ist cool in der Wissenschaft, weil es cool ist, nette Kurzprogramme zu schreiben und dabei die Leistung zu ignorieren. In der realen Welt gibt es keine Verschwörung dagegen. Auch das Implementieren einiger Dinge (zum Beispiel der Radix-Sortierung) scheint wie totaler Schmerz in der FP. Oh und generierter Code ist IMHExperience slooooooooooooooooow.

Einige haben eine ziemlich steile Lernkurve, die viel Zeit in Anspruch nimmt (vor allem, wenn Sie von OOP kommen; Sie werden ein paar Mal den Kopf zerbrechen, bevor Sie den Paradigmenwechsel erleben).

Obwohl ich angefangen habe, funktionale Programmierung zu bekommen (von Java kommend und zu Clojure gehend), finde ich es immer noch ziemlich schwierig. Die Community scheint keinen so aussagekräftigen Code wie Java zu schreiben.

Es scheint, als gäbe es einen kleinen Verlust an Ausdruckskraft und eine kleine Zunahme an Komplexität.

Obwohl ich wenig Erfahrung mit funktionalen Programmiersprachen habe (ich kenne einige Haskell- und Lisp-Sprachen), finde ich das FP-Paradigma sehr mächtig und oft eleganter als andere Paradigmen. Ich wünschte, ich hätte die Gelegenheit, mit FP an einem ernsthaften Projekt zu arbeiten.

Der einzige Bereich, in dem ich ernsthafte Zweifel an der Wirksamkeit von FP habe, ist der Umgang mit komplexen Datenstrukturen, die nicht induktiv definiert werden können, z. B. Grafiken. Wenn ich zum Beispiel einen Algorithmus implementieren muss, der an einem großen Graphen arbeitet, möglicherweise den Graphen durchläuft und kleine lokale Änderungen vornimmt, frage ich mich, ob ein FP-Ansatz einem imperativen Ansatz entsprechen kann, bei dem das Programm vom Knoten zum Knoten wechseln darf Knoten mit Zeigern.