La programmation fonctionnelle peut-elle être utilisée pour développer une application d'entreprise complète?

Je commence tout juste à apprendre la programmation fonctionnelle (FP). Je viens d'un monde OOP, où tout est objet, et la plupart d'entre eux sont mutables. J'ai du mal à comprendre le concept selon lequel les fonctions n'ont pas d'effets secondaires.

Si quelque chose n'est pas modifiable, comment les objets communs comme Employé ou Personne sont-ils représentés dans FP.

FP peut-il être utilisé pour créer une application d'entreprise à part entière?

La question n'est pas Peut-on utiliser FP dans l'entreprise? mais devrions-nous utiliser FP dans l'Entreprise?

Bien sûr vous pouvez. Vous pouvez développer tout type d'application avec tout type de langage de programmation, c'est pourquoi ils sont appelés "Turing complete".

Maintenant, à la question "Devrait-on l'utiliser dans l'entreprise?" Cela dépend de vous ou de vos employeurs, la PF peut être vraiment utile dans certaines sortes d'applications, et en fait, elle est très utilisée: Haskell dans l'industrie

Maintenant, vous demandez peut-être "Alors pourquoi n'est-il pas utilisé plus?" principalement parce que d'autres langages Imperative / OO sont plus courants, et les entreprises refusent de passer à un langage plus "exotique" car ils sont habitués à Java ou C ++.

J'ai commencé à apprendre les langages FP il y a quelques années (Haskell, Scala, Scheme) et, même si je suis loin d'être un expert, j'ai découvert qu'ils peuvent me rendre extrêmement productif, pour certaines tâches plus que C ++ ou Java .

OMI, certaines des forces des langages de PF sont:

• Ils ont tendance à être très concis, tout en conservant une sémantique claire.
• Vous pouvez utiliser un style déclaratif et ne pas trop penser aux détails de l'implémentation.
• Un système de type riche comme celui de Haskell peut détecter de nombreuses erreurs logiques très tôt (au moment de la compilation). Pour autant que je sache (pas vraiment, en fait), SML et Ocaml offrent des avantages similaires.

Jusqu'à présent, j'ai trouvé le passage au paradigme FP assez excitant et pas trop difficile une fois que vous y avez passé suffisamment de temps. (Mais combien de temps ai-je passé à apprendre le C ou le C ++? Beaucoup!)

Je pense donc que d'un point de vue technique, il est parfaitement logique de développer une application d'entreprise complète en utilisant un langage de programmation fonctionnel.

Malheureusement, ce paradigme n'est pas courant: la plupart des entreprises ont tendance à adopter uniquement des technologies bien testées, donc elles resteront à l'écart de la PF jusqu'à ce qu'elles aient suffisamment de preuves que cela fonctionne réellement, qu'il y a suffisamment de développeurs, d'outils, de bibliothèques, de cadres. Par conséquent, il est (beaucoup) plus difficile de trouver un emploi dans lequel vous pouvez faire de la programmation FP à plein temps en ce moment.

Peut-être que la situation actuelle changera si l'utilisation croissante des processeurs multicœurs encouragera à investir davantage dans les langages FP, qui semblent assez forts pour écrire des logiciels simultanés.

En outre, il y a une tendance à introduire certaines fonctionnalités de FP dans les langages traditionnels non fonctionnels comme C #, C ++ afin que les programmeurs puissent utiliser certains FP sans avoir besoin d'un changement de paradigme complet. Peut-être que dans dix ans, ces langages couvriront suffisamment de fonctionnalités FP pour que le passage à un langage purement fonctionnel soit beaucoup plus facile.

Je ne pense pas que ce soit nécessairement la meilleure idée. Mais cela dépend de la nature de l'application spécifique.

Je crois beaucoup dans la philosophie d'Eric Evans telle que décrite dans son livre, Domain-Driven Design , que vous devez créer un modèle de domaine qui soit une représentation du problème actuel qui peut vous aider à résoudre votre problème. Evans suggère de trouver un langage de programmation adapté au problème particulier à résoudre, par exemple, il mentionne Fortran comme un moyen de résoudre des problèmes de nature mathématique. Ou même créer des langages spécialisés spécifiques au domaine pour le problème à résoudre.

Lorsque vous avez réussi à créer un bon modèle de domaine, vous constaterez que le code de présentation finit par être une fine coque au-dessus de la couche de domaine.

Maintenant, le problème avec l'application d'entreprise est que ce type d'application (si vous pouvez généraliser sur les applications d'entreprise) implique souvent de modifier l'état des entités dont l'identité est importante et de conserver les entités modifiées dans une base de données. Ce type de problème très généralisé est à mon humble avis beaucoup mieux résolu en utilisant un modèle orienté objet qu'un modèle fonctionnel.

Cela ne signifie pas qu'il existe des domaines d'une application d'entreprise qui ne pourraient pas être mieux résolus par un paradigme fonctionnel. Par exemple, un module d'analyse des risques d'une application bancaire, ou un module de planification d'itinéraire dans une application d'expédition. Et peut-être que certaines applications d'entreprise pourraient être implémentées entièrement en utilisant un paradigme fonctionnel.

Mais en général, je pense que le paradigme orienté objet permet de créer des modèles de domaine plus utiles pour la majorité des applications d'entreprise.

Éditer

En raison de quelques votes positifs, mon attention a été attirée sur cette réponse - et depuis que je l'ai écrite, j'en ai appris beaucoup plus sur la PF - et je ne suis pas tout à fait sûr d'être d'accord avec ma propre réponse. Certains langages fonctionnels peuvent très bien décrire les cas d'utilisation. Mais vous devez apprendre un état d'esprit complètement différent.

Oui il peut. Google un peu et vous trouverez de vrais logiciels codés dans des langages fonctionnels purs.

Quant à votre question sur les objets métier, je suppose que votre problème réel concerne l'immuabilité. Dans ce cas, considérez que vous renvoyez une nouvelle «personne» à chaque fois que vous la muteriez si vous utilisiez un langage impératif.

Notez que cette technique peut également être implémentée en utilisant des langages impératifs!

La programmation de fonctions (FP) comme la programmation orientée objet (POO) sont des paradigmes. Ils représentent différents modèles ou approches des problèmes de programmation. Ces différentes approches n'empêchent pas la capacité de produire des logiciels évolutifs, maintenables et extensibles. Cela ne veut pas dire que les approches sont équivalentes pour tous les types de problèmes; ils ne le sont pas. Certains problèmes s'alignent mieux (ou pire) sur des paradigmes particuliers, par exemple FP ne serait pas mon premier choix pour un programme qui a une séquence dépendante d'opérations avec des effets secondaires. Cependant de tels programmes peuvent et ont été écrits, et bien écrits.

Oui, FP peut être utilisé dans les applications d'entreprise. Clojure est un exemple de langage FP avec succès en entreprise: http://cognitect.com/clojure#successstories

Représenter l'État peut être un défi dans la PF et changer les paradigmes pour s'adapter à la PF peut être un peu une déformation mentale. Certains langages FP interdisent complètement les effets secondaires et l'état mutable. Clojure permet les deux mais décourage ou isole ces paradigmes.

En bref, la représentation de l'État peut être très similaire à l'OO. C'est une modification d'état qui est très différente. Ainsi, par exemple, dans l'état FP peut être représenté par des listes et des cartes. Une liste d'employés peut ressembler à:

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

Je connais deux façons de gérer la modification d'état dans FP. L'un est quelque chose comme la programmation réactive fonctionnelle. Dans ce paradigme, tous les états sont gérés au plus haut niveau uniquement ... par exemple, une vue HTML de votre application a un état dans la vue (comme le nom, l'adresse, etc.) de la personne. Maintenant, lorsque vous cliquez sur "mettre à jour le nom", une fonction est appelée qui gère tout ce qui concerne une mise à jour de nom, sauf en réalité le changement de nom. Cela peut sembler bizarre ... mais supportez-moi. Le nom modifié serait alors renvoyé par la fonction et la vue (ou le magasin de données persistantes, etc.) affichera le nouveau nom. Ou bien, une nouvelle structure entière avec le nom mis à jour sera retournée. Alors, que fait la fonction? Il valide le nom et renvoie le nouveau nom s'il est valide, une erreur s'il ne l'est pas, et éventuellement une nouvelle vue ou un nouveau lien de navigation à suivre. Pour quelque chose de plus complexe qu'un changement de nom, cela peut faire beaucoup plus.

Ainsi, pour FRP, l'objet renvoyé par la fonction est le nouvel état et peut être donné directement à la vue ou à tout ce qui se trouve au niveau supérieur. Dans certains cas, FRP prend tout l'état, le transmet à la fonction et récupère tout l'état.

Avec ce paradigme, le conteneur ou le framework doit gérer la mise à jour de l'affichage, de la base de données ou de tout autre élément à mettre à jour à partir du nouvel état. Vous pouvez donc imaginer un cadre qui dessine l'application à l'écran. Lorsqu'un utilisateur clique sur quelque chose, les fonctions sont appelées et le nouvel état est renvoyé. Le cadre met ensuite à jour l'écran en redessinant tout ou en redessinant intelligemment des parties de l'affichage. Voir http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure utilise le deuxième paradigme que j'ai rencontré et qui est d'isoler les changements d'état mais pas nécessairement de les restreindre au plus haut niveau. Avec Clojure, tous les états mutables doivent être "maintenus" (sauf si vous utilisez des objets Java pour l'état) par un atome, un agent ou une référence. La façon dont cela fonctionne est l'objet détenu ou pointé ou référencé (comme vous voulez l'appeler) par l'atome / agent / ref est immuable, mais l'atome / agent / ref peut changer pour pointer vers un nouvel objet. Dans ce cas, vous utilisez des méthodes spéciales sur l'atome / l'agent / ref qui disent "mettre à jour l'objet ici en faisant telle ou telle chose et en réaffectant l'atome / l'agent / ref à un nouvel objet".

Pourquoi est-ce bénéfique que vous pourriez demander? Parce que l'objet immuable référencé par ces constructions Clojure peut être passé à une fonction qui fait quelque chose et pendant que cette fonction exécute sa référence à l'objet est garanti de ne pas changer. Autrement dit, l'atome / agent / ref n'est pas transmis à la fonction mais l'objet immuable pointé par eux est transmis. Les atomes, les agents et les références ont des propriétés spéciales qui gèrent les mises à jour et la concurrence de manière sûre et faisant partie du langage. Voir http://clojure.org/state

J'espère que ça aide. Je suggère de lire davantage sur l'état de Clojure et le FRP pour mieux comprendre comment les employés et les personnes peuvent être représentés dans la PF. Cependant, la représentation réelle serait similaire à la programmation orientée objet ... c'est la mutabilité qui est vraiment différente.