Kann mit funktionaler Programmierung eine vollständige Unternehmensanwendung entwickelt werden?

Ich fange gerade erst an, Functional Programming (FP) zu lernen. Ich komme aus einer OOP-Welt, in der alles Objekte sind und die meisten von ihnen veränderlich sind. Es fällt mir schwer, mich mit dem Konzept auseinanderzusetzen, dass Funktionen keine Nebenwirkungen haben.

Wenn etwas nicht veränderbar ist, wie werden allgemeine Dinge wie Mitarbeiter oder Person in FP dargestellt?

Kann FP verwendet werden, um eine vollständige Unternehmensanwendung zu erstellen?

Die Frage ist nicht Kann FP in der Enterprise verwendet werden? Aber sollten wir FP in der Enteprise verwenden?

Natürlich kannst du. Sie können jede Art von Anwendung mit jeder Art von Programmiersprache entwickeln, deshalb werden sie "Turing complete" genannt.

Nun zu der Frage "Sollte es in der Enterprise verwendet werden?" Es liegt an Ihnen oder Ihren Arbeitgebern, wie nützlich FP für bestimmte Anwendungen ist. Tatsächlich wird es häufig eingesetzt: Haskell in der Branche

Jetzt könnten Sie fragen: "Warum wird nicht mehr verwendet?" hauptsächlich, weil andere Imperative / OO-Sprachen häufiger vorkommen und Unternehmen sich weigern, auf eine "exotischere" Sprache umzusteigen, weil sie Java oder C ++ verwenden.

Ich habe vor ein paar Jahren angefangen, FP-Sprachen zu lernen (Haskell, Scala, Scheme), und obwohl ich weit davon entfernt bin, ein Experte zu sein, habe ich herausgefunden, dass sie mich für bestimmte Aufgaben über C ++ oder Java hinaus extrem produktiv machen können .

IMO, einige der Stärken der FP-Sprachen sind:

• Sie sind in der Regel sehr prägnant, behalten jedoch eine klare Semantik bei.
• Sie können einen deklarativen Stil verwenden und müssen nicht zu viel über Implementierungsdetails nachdenken.
• Ein Rich-Type-System wie das von Haskell kann sehr früh (zur Kompilierungszeit) viele logische Fehler erkennen. Soweit ich weiß (eigentlich nicht sehr viel), bieten SML und Ocaml ähnliche Vorteile.

Bis jetzt fand ich den Wechsel zum FP-Paradigma ziemlich aufregend und nicht allzu schwierig, wenn Sie genug Zeit darauf verwendet haben. (Aber wie viel Zeit habe ich damit verbracht, C oder C ++ zu lernen? Sehr viel!)

Aus technischer Sicht halte ich es für absolut sinnvoll, eine vollständige Unternehmensanwendung mit einer funktionalen Programmiersprache zu entwickeln.

Leider ist dieses Paradigma kein Mainstream: Die meisten Unternehmen tendieren dazu, nur erprobte Technologien zu übernehmen. Daher werden sie sich von FP fernhalten, bis sie genügend Beweise dafür haben, dass es tatsächlich funktioniert, dass es genügend Entwickler, Tools, Bibliotheken und Frameworks gibt. Daher ist es (viel) schwieriger, einen Job zu finden, bei dem Sie die FP-Programmierung jetzt in Vollzeit durchführen können.

Vielleicht wird sich die aktuelle Situation ändern, wenn der zunehmende Einsatz von Multi-Core-Prozessoren dazu anregt, mehr in FP-Sprachen zu investieren, die für das Schreiben von gleichzeitiger Software recht stark zu sein scheinen.

Es besteht auch die Tendenz, einige FP-Funktionen in nicht funktionsfähige Hauptsprachen wie C #, C ++ einzuführen, damit Programmierer einige FPs verwenden können, ohne dass ein vollständiger Paradigmenwechsel erforderlich ist. Vielleicht werden diese Sprachen in zehn Jahren genug FP-Features abdecken, dass der Wechsel zu einer rein funktionalen Sprache viel einfacher wird.

Ich denke nicht, dass es unbedingt die beste Idee ist. Dies hängt jedoch von der Art der spezifischen Anwendung ab.

Ich glaube fest an die Philosophie von Eric Evans, wie sie in seinem Buch Domain-Driven Design beschrieben ist , dass Sie ein Domain-Modell erstellen sollten, das das vorliegende Problem darstellt und Ihnen bei der Lösung Ihres Problems helfen kann. Evans schlägt vor, eine Programmiersprache zu finden, die für das jeweilige Problem geeignet ist, z. B. nennt er Fortran als Mittel zur Lösung mathematischer Probleme. Oder Sie erstellen spezielle domänenspezifische Sprachen für das jeweilige Problem.

Wenn es Ihnen gelungen ist, ein gutes Domänenmodell zu erstellen, stellt sich heraus, dass der Präsentationscode eine dünne Hülle über der Domänenschicht ist.

Bei Unternehmensanwendungen bedeutet dies häufig, dass der Status von Entitäten, deren Identität von Bedeutung ist, geändert und die geänderten Entitäten in einer Datenbank beibehalten werden. Diese sehr verallgemeinerte Art von Problem wird meiner Meinung nach durch die Verwendung eines objektorientierten Modells viel besser gelöst als durch ein Funktionsmodell.

Dies bedeutet nicht, dass es Bereiche einer Unternehmensanwendung gibt, die durch ein Funktionsparadigma nicht besser gelöst werden könnten. Zum Beispiel ein Risikoanalysemodul einer Bankenanwendung oder ein Routenplanungsmodul in einer Versandanwendung. Und vielleicht könnten einige Unternehmensanwendungen vollständig unter Verwendung eines Funktionsparadigmas implementiert werden.

Generell denke ich jedoch, dass das objektorientierte Paradigma die Erstellung nützlicherer Domänenmodelle für die meisten Unternehmensanwendungen ermöglicht.

Bearbeiten

Aufgrund einiger Überstimmungen wurde ich auf diese Antwort aufmerksam - und seit ich sie geschrieben habe, habe ich viel mehr über FP gelernt - und ich bin mir nicht ganz sicher, ob ich mit meiner eigenen Antwort mehr einverstanden bin. Einige funktionale Sprachen können Anwendungsfälle sehr gut beschreiben. Aber Sie müssen eine völlig andere Denkweise lernen.

Ja, kann es. Google ein bisschen und Sie werden echte Software finden, die in reinen Funktionssprachen codiert ist.

Was Ihre Frage zu Geschäftsobjekten betrifft, so liegt Ihr eigentliches Problem vermutlich in der Unveränderlichkeit. Beachten Sie in diesem Fall, dass Sie jedes Mal eine neue "Person" zurückgeben, wenn Sie sie mutieren würden, wenn Sie eine imperative Sprache verwenden.

Beachten Sie, dass diese Technik auch mit imperativen Sprachen implementiert werden kann!

Funktionsprogrammierung (FP) wie objektorientierte Programmierung (OOP) sind Paradigmen. Sie repräsentieren unterschiedliche Muster oder Ansätze für Programmierprobleme. Diese unterschiedlichen Ansätze machen es nicht unmöglich, skalierbare, wartbare und erweiterbare Software zu erstellen. Das heißt nicht, dass die Ansätze für alle Problemtypen gleich sind. sie sind nicht. Bestimmte Probleme passen sich besser (oder schlechter) an bestimmte Paradigmen an, zum Beispiel wäre FP nicht meine erste Wahl für ein Programm, das eine abhängige Abfolge von Operationen mit Nebenwirkungen aufweist. Solche Programme können und wurden jedoch gut geschrieben.

Ja, FP kann in Unternehmensanwendungen verwendet werden. Clojure ist ein Beispiel für eine FP-Sprache mit Erfolg im Unternehmen: http://cognitect.com/clojure#successstories

Die Repräsentation des Staates kann eine Herausforderung für die FP sein, und der Paradigmenwechsel zur Anpassung an die FP kann ein bisschen verrückt werden. Einige FP-Sprachen erlauben keinerlei Nebeneffekte und keinen veränderlichen Zustand. Clojure erlaubt beides, aber entmutigt oder isoliert diese Paradigmen.

Kurz gesagt, die Zustandsdarstellung kann OO sehr ähnlich sein. Es ist eine Zustandsänderung, die sehr unterschiedlich ist. So kann beispielsweise im FP-Zustand durch Listen und Karten dargestellt werden. Eine Liste der Mitarbeiter kann folgendermaßen aussehen:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

Mir sind zwei Möglichkeiten bekannt, mit Statusänderungen in FP umzugehen. Man ist so etwas wie eine funktionale reaktive Programmierung. In diesem Paradigma wird der gesamte Status nur auf höchster Ebene behandelt. Beispielsweise enthält eine HTML-Ansicht Ihrer Anwendung den Status (wie Name, Adresse usw. der Person). Wenn Sie nun auf "Name aktualisieren" klicken, wird eine Funktion aufgerufen, die alle Aspekte einer Namensaktualisierung behandelt, mit Ausnahme der tatsächlichen Änderung des Namens. Das mag komisch klingen ... aber ertrage es mit mir. Der geänderte Name wird dann von der Funktion zurückgegeben und die Ansicht (oder der persistente Datenspeicher usw.) zeigt den neuen Namen an. Alternativ wird eine neue Struktur mit dem aktualisierten Namen zurückgegeben. Was macht die Funktion? Es validiert den Namen und gibt den neuen Namen zurück, wenn er gültig ist. Ist dies nicht der Fall, tritt ein Fehler auf. und möglicherweise eine neue Ansicht oder einen neuen Navigationslink. Bei etwas Komplexerem als einer Namensänderung kann dies viel mehr bewirken.

Für FRP ist das von der Funktion zurückgegebene Objekt also der neue Status und kann direkt an die Ansicht übergeben werden, oder was auch immer sich auf der hohen Ebene befindet. In einigen Fällen übergibt FRP den gesamten Status an die Funktion und gibt den gesamten Status zurück.

Bei diesem Paradigma muss der Container oder das Framework die Aktualisierung der Anzeige, der Datenbank oder aller anderen Elemente abwickeln, die vom neuen Status aus aktualisiert werden müssen. Sie können sich also ein Framework vorstellen, das die Anwendung auf dem Bildschirm zeichnet. Wenn ein Benutzer auf etwas klickt, werden Funktionen aufgerufen und der neue Status wird zurückgegeben. Das Framework aktualisiert dann den Bildschirm, indem entweder alles neu gezeichnet oder Teile der Anzeige intelligent neu gezeichnet werden. Sehen http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure verwendet das zweite Paradigma, auf das ich gestoßen bin, und zwar, um Zustandsänderungen zu isolieren, aber nicht notwendigerweise auf die höchste Ebene zu beschränken. Mit Clojure muss jeder veränderbare Status von einem Atom, Agenten oder Verweis "gehalten" werden (es sei denn, Sie verwenden Java-Objekte für den Status). Die Art und Weise, wie dies funktioniert, ist das Objekt, auf das das Atom / Agent / Ref verweist (wie auch immer Sie es nennen möchten). Das Atom / Agent / Ref kann sich jedoch ändern, um auf ein neues Objekt zu verweisen. In diesem Fall verwenden Sie spezielle Methoden für das Atom / Agent / Ref, die sagen: "Aktualisieren Sie das Objekt hier, indem Sie so oder so vorgehen und das Atom / Agent / Ref einem neuen Objekt zuweisen".

Warum ist das vorteilhaft, fragen Sie sich? Da das unveränderliche Objekt, auf das von diesen Clojure-Konstrukten verwiesen wird, möglicherweise an eine Funktion übergeben wird, die etwas tut, und während diese Funktion ausgeführt wird, wird die Referenz auf das Objekt garantiert nicht geändert. Das Atom / Agent / Ref wird also nicht an die Funktion übergeben, sondern das unveränderliche Objekt, auf das sie zeigen. Atome, Agenten und Refs haben spezielle Eigenschaften, die Aktualisierungen und Parallelität auf sichere Weise und als Teil der Sprache handhaben. Siehe http://clojure.org/state

Ich hoffe das hilft. Ich empfehle, mehr über den Clojure-Staat und FRP zu lesen, um ein besseres Verständnis dafür zu erhalten, wie Mitarbeiter und Personen in FP vertreten sein können. Obwohl die tatsächliche Darstellung der objektorientierten Programmierung ähnelt ... ist es die Veränderbarkeit, die sich wirklich unterscheidet.