Pourquoi la programmation fonctionnelle n'est-elle pas plus populaire dans l'industrie? Est-ce qu'il comprend maintenant? [fermé]

61

Au cours de mes quatre années à l'université, nous avons beaucoup utilisé la programmation fonctionnelle dans plusieurs langages de programmation fonctionnels. Mais j’ai aussi beaucoup utilisé la programmation orientée objet, et en fait j’utilise davantage les langages orientés objet lorsque je fais mon propre petit projet pour préparer mon premier emploi. Mais je souhaite souvent que je code dans un langage de programmation fonctionnel lors de la réalisation de ces projets.

Cependant, lors de la recherche d'un emploi, il est très rare de voir un travail nécessitant la connaissance d'un langage de programmation fonctionnel.

Pourquoi les langages de programmation fonctionnels ne sont-ils pas davantage utilisés dans l'industrie? Il y a beaucoup de nouvelles sur les langages de programmation fonctionnels ces jours-ci, alors je me demande si la programmation fonctionnelle est en train de gagner du terrain dans l'industrie?

Jonas
la source
3
Dans une certaine mesure, je suis en désaccord avec la prémisse de votre question. Des fonctionnalités linguistiques inspirées des "langages fonctionnels" sont ajoutées à des langages tels que Java et JavaScript. En fait, JavaScript a toujours été (à certains égards) un langage fonctionnel, bien que beaucoup de gens ne s'en soient jamais rendu compte.
MatrixFrog
1
@MatrixFrog: On pourrait se demander "Pourquoi n'être fonctionnels qu'à moitié en ajoutant quelques concepts fonctionnels à des langages non fonctionnels au lieu d'adopter un langage à part entière de la PF? Après tout, le paradigme existe depuis de nombreuses années et est très mature."
Giorgio
Le monde ne passe pas à des alternatives supérieures (et le pur FP est une alternative supérieure) pour différentes raisons, telles que la compatibilité ascendante, l'inertie, etc. Pensez à la disposition du clavier DVORAK: c'est plus efficace pour la frappe au clavier, mais nous restons tous coincés avec QWERTY simplement parce qu'il y a tellement de logiciels avec des raccourcis conviviaux.
KolA

Réponses:

38

Je dirais qu'une des raisons pour lesquelles la programmation fonctionnelle n'est pas plus répandue est le manque de base de connaissances. D'après mon expérience, les entreprises sont très réticentes à prendre des risques en ce qui concerne la mise en œuvre de technologies qui ne sont pas le flux principal et qui préféreraient investir dans des cadres éprouvés (java, c ++, c #). C'est seulement lorsqu'il existe un besoin commercial (comme dans Ericsson) que de nouveaux paradigmes sont pris en compte. Mais même dans le cas d'Ericsson, j'ai entendu dire que la direction exigeait que le c ++ soit utilisé et Joe Armstrong était obligé de coder les appels erlang en c ++! Cela devrait montrer à quel point les entreprises hésitent à mettre en œuvre de nouvelles technologies!

ennuikiller
la source
9
Comment la programmation fonctionnelle est-elle «nouvelle»?
Evan Plaice
7
Je pense qu'il voulait dire «non utilisé» au lieu de «nouveau».
Vinko Vrsalovic
10
Donc, il n’est pas utilisé ... parce qu’il est utilisé? Hm.
Alex Baranosky
21
@ Alex - Exactement. Sucks, n'est-ce pas?
KeithS
5
@ Stargazer712: Quelles sont ces raisons? Je connais beaucoup de développeurs qui ne connaissent pas la programmation fonctionnelle. L'ignorance a donc un sens pour moi. La programmation fonctionnelle a-t-elle eu un échec massif dans le passé qui a chassé l'industrie de cette réalité dont je ne suis pas au courant?
Sean McMillan le
67

J'étais professeur et, tout comme les programmeurs, les professeurs sont toujours à la recherche du Next Big Thing. Quand ils pensent en avoir trouvé un, ils en font un train en marche et tout le monde s'entasse bien. Puisqu'ils prêchent aux étudiants qui pensent que les professeurs doivent être vraiment intelligents, sinon, pourquoi seraient-ils professeurs, ils n'auraient aucune résistance.

La programmation fonctionnelle est un tel mouvement. Bien sûr, il y a beaucoup de bonnes questions intéressantes à étudier et beaucoup d'articles de conférence intéressants à écrire. Ce n’est pas une idée particulièrement nouvelle, et vous pouvez le faire dans n’importe quel langage moderne, et il n’est pas nécessaire que les idées soient nouvelles pour être intéressantes. C'est aussi une bonne compétence à avoir.

Cela étant, la programmation fonctionnelle n’est qu’une flèche à avoir dans votre carquois, pas la seule, tout comme la POO n’est pas la seule.

Mon bricolage avec les universitaires en informatique est le manque d'interaction pratique avec l'industrie pour déterminer ce qui a réellement un sens dans le monde réel, à savoir le contrôle de la qualité. Si ce contrôle de la qualité existait, il serait peut-être plus important de classer les problèmes et leurs solutions, avec des compromis, plutôt que de se limiter aux tout derniers modèles.

Mike Dunlavey
la source
1
C'est un très bon commentaire. +1 aux flèches dans votre carquois et gammes de solutions avec compromis.
user21007
2
+1 pour le QC. Cette maîtrise aurait été beaucoup plus utile avec des sujets dédiés couvrant les tests, la révision de code, la complexité du code, etc. Etre capable de vérifier automatiquement qu'un programme fait ce qu'il devrait après le dernier correctif vaut n'importe quel nombre de charabia à la main "ça devrait marcher maintenant".
l0b0
5
@ l0b0: Merci, même si en réalité je pensais au contrôle de la qualité de ce qui est enseigné et comment. Dans l'état actuel des choses, les professeurs de CS enseignent ce qu'ils trouvent personnellement le plus intéressant. Comparez cela à l'ingénierie, où il existe une interaction avec l'industrie ou la médecine, où la pertinence dans le monde réel est très élevée. Les profs IME et CS pensent que le monde réel enseignera ce qui compte dans le monde réel, mais les étudiants ne veulent pas apprendre, mais désirent plutôt savoir ce qui les passionnait le plus.
Mike Dunlavey
@ Mike: à peu près n'importe quelle langue moderne? Incluez-vous C ++ et Java?
kevin cline
+1 Je n'aurais pas dit mieux moi même.
riwalk
25

Parce que le plus gros problème de développement logiciel de nos jours est la capacité de gérer la complexité. Ce n'est pas le sujet de la plupart des langages de programmation fonctionnels. À ce titre, les langues qui font faire une priorité ( à savoir les plus populaires des langages de POO) ont tendance à voler quelques - unes des caractéristiques plus fraîches qui sortent des langages fonctionnels plus académiques et ainsi rester au top.

Fishtoaster
la source
48
Je ne suis pas d'accord. Les langages de programmation fonctionnels essaient de minimiser l'utilisation d'un état et deviennent ainsi moins complexes. Les programmes programmés dans un langage fonctionnel sont également plus faciles à tester et à refactoriser.
Jonas
7
@ Jonas: beaucoup de programmeurs trouvent qu'il est extrêmement difficile d'écrire un programme en utilisant presque aucun état (y compris moi-même). De ce point de vue, il s’agit en réalité d’une plus grande complexité. (Veuillez noter que je ne discute aucunement de l'utilité de la programmation fonctionnelle!)
ShdNx le
3
@ShdNx: Oui, je sais. Même moi, je pensais que la programmation fonctionnelle était difficile quand je l'ai appris pour la première fois à l'université. Mais après un certain temps, j'ai commencé à préférer cela à la programmation impérative et à la programmation orientée objet plus spécifique. À mon université, la programmation fonctionnelle était enseignée avant la programmation impérative et les étudiants qui n'avaient pas fait de programmation avant l'université pensaient que la programmation impérative était très difficile au début et que la programmation fonctionnelle était plus proche des mathématiques.
Jonas
16
Il y a une différence entre difficulté et complexité. La programmation orientée objet est nettement plus difficile que la programmation structurée car elle ajoute plus de concepts. Pour des quantités de code suffisantes, ils réduisent la complexité en fournissant une structure au code. La FP est la même chose: si vous écrivez seulement deux lignes, cela semble excessif, mais si votre code est assez gros, structurer le code en tant que sous-unités sans état améliore l’évolutivité et réduit la complexité du code.
Muhammad Alkarouri
6
L'un des principaux points forts de la programmation fonctionnelle est la composabilité. Si ce n'est pas un outil de gestion de la complexité, je ne sais pas ce que c'est.
dan_waterworth
23

La programmation fonctionnelle commence vraiment à faire son chemin - lentement mais sûrement.

Par exemple, la startup que je construis utilise un langage fonctionnel (Clojure) comme langage de développement principal pour les raisons suivantes:

  • Productivité - apprendre la PF est difficile, mais une fois que vous maîtrisez la chose, il est très difficile de battre en termes de puissance et d'expressivité. J'écris probablement environ 1 / 10ème du nombre de lignes pour implémenter une fonctionnalité donnée par rapport à ce que j'aurais eu besoin en C # ou en Java

  • Fiabilité - les fonctions pures sont beaucoup plus faciles à raisonner et à tester que les objets avec état. Par conséquent, vous pouvez écrire de meilleurs tests et valider beaucoup plus facilement l'exactitude de votre code.

  • La simultanéité - les langages fonctionnels insistent sur l’immuabilité, qui offre d’énormes avantages aux applications concurrentes par rapport à la nécessité de fonctionner efficacement sur plusieurs cœurs. Et qu’on le veuille ou non, l’utilisation de plusieurs cœurs est l’avenir. Voir http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey pour une explication brillante de la raison pour laquelle cela est si important.

  • Composabilité / modularité - les langages fonctionnels semblent se prêter au raccordement de composants plus facilement que les systèmes OO complexes. Je n'ai toujours pas compris toutes les raisons pour cela, mais cela tient en partie au fait que vous n'avez pas toute la "complexité accidentelle" que les modèles d'objets orientés traînent avec eux. L'exposé de Stuart Halloway sur la simplicité radicale explore ces idées de manière beaucoup plus approfondie.

EDIT : En réponse au commentaire de Despertar, les problèmes du clonage en profondeur par rapport au clonage superficiel sont un exemple de la "complexité incidente" des systèmes POO qui limitent la modularité: vous ne pouvez pas composer d'objets ensemble et les faire passer comme des structures composites sans analyse minutieuse de la sémantique du clonage et des mutations. Dans de petits cas, cela est gérable, mais dans les systèmes complexes, cela devient rapidement un problème important. Ce problème n'existera pas si vous vous basez sur des structures de données fonctionnelles pures.

Mikera
la source
+1, j'aimerais connaître votre processus décisionnel concernant les raisons pour lesquelles vous avez choisi Clojure. (Je ne suis pas pour ou anti Clojure, je suis juste intéressé).
dan_waterworth
4
"apprendre la PF, c'est difficile": il est difficile d'apprendre un paradigme. Je me souviens du nombre d'heures que j'ai passées avec le code impératif (Pascal) avant d'avoir suffisamment d'expérience pour être raisonnablement productif. Je pense que FP est moins connu parce que beaucoup de programmeurs ont d'abord appris un langage impératif et qu'une fois qu'ils ont appris à programmer, ils n'ont pas eu le temps de regarder autre chose. Je suis un programmeur C ++ à temps plein et j'apprends actuellement Scala le soir après le travail. Si j'avais une famille à soigner, je pourrais simplement l'oublier.
Giorgio
1
Je pense que les 3 premiers sont de bons cas, mais je ne suis pas d’accord avec le 4ème. La POO est extrêmement modulaire et compositionnelle; pour moi c'est l'une de ses plus grandes forces. C'est aussi un excellent moyen de cacher la complexité grâce à l'encapsulation et à l'abstraction.
Despertar
1
@Giorgio. Exactement. "Apprendre la PF, c'est dur, apprendre la POO, c'est facile" est aussi absurde que "Apprendre l'espagnol, c'est dur, mais le chinois, c'est facile". Cela dépend de laquelle était votre langue maternelle. Et je n'ai pas choisi le chinois comme analogue arbitraire à la POO - parce que les idiomes OO sont comme des hiéroglyphes: faciles à apprendre un par un, mais difficiles à mémoriser tous et impossibles à composer. La PF ressemble beaucoup plus à une langue avec un alphabet: des lettres séparées sont inutiles isolément mais permettent de composer n'importe quoi avec un ensemble de règles assez petit
KolA
1
(suite) alors pourquoi n'est-il pas populaire - pour le moment - pour les mêmes raisons. Les hiéroglyphes existaient bien avant que le premier alphabet soit inventé et mûri. Il faudra peut-être une autre génération de personnes qui ont l'écriture et la lecture alphabétiques. Je parle de la PF comme premier paradigme
KolA
12

Manque d'application tueur

Hé, celui-ci a l'air frais. (dig dig dig dig)

Je pense que la plupart des langages de programmation ont prospéré avec une "application de tueur" - quelque chose de convaincant qui était exclusif au langage (ou vu de cette façon). Cela ne veut pas dire que tous l'absorption était que l' application, mais qu'il a conduit la langue à une acceptation plus grande.

Voici ma vision pas très précise de ce créneau qui a conduit à l'adoption de certaines des langues que nous avons aujourd'hui:

  • C: Fonctionne partout (c'était à la fin des années 70 et 80)
  • C ++: frameworks d'interface graphique (début des années 90)
  • Java: applets et servlets (à la fin des années 90)
  • Objective-C: applications iOS (avant cela, applications OS X)
  • Ruby: Rails
  • C #: ASP.NET, WinForms
  • PHP: Wordpress, etc.
  • Javascript: AJAX, notamment via des frameworks
  • Lua: Script de jeu, en particulier WoW

De plus, de nombreux langages propriétaires sont entrés dans la peau par le biais de puissantes organisations de vente (les langages Oracle et, dans une moindre mesure, les langages de Microsoft), créant ainsi leur propre créneau.

Une note très importante à propos de cette liste: le "niche" de la langue, comme indiqué par l'application killer, devient de plus en plus spécifique au fil des décennies. Notez le dernier sur la liste: Scripting de jeu , en particulier. Il est de plus en plus difficile pour les langues d’attirer l’attention à cause de la liste de choses qui sont déjà assez bien faites par une autre langue.

Ainsi, tout langage fonctionnel doit vraiment décoller, c’est un créneau. En réalité, il n'y a pas encore d'énormes langages fonctionnels, mais il y en a beaucoup dans les plus petites niches:

  • Emacs Lisp: Utilisation constante depuis les années 80 dans Emacs par les développeurs. ( Presque jamais utilisé ailleurs.)
  • Erlang: Partout où vous voulez de nombreux agents simultanés.
  • Régime: Education
  • APL / J / K: Finance (Appelons ces fonctionnels, par souci d'argument)
  • Common Lisp: "AI" - C'est ce à quoi les gens ont tendance à dire qu'il est utilisé, ce qui est une bénédiction et une malédiction.

Maintenant, le seul langage majeur que je pense avoir laissé de côté de cette discussion est Python. Python a fait quelque chose de très intéressant. il a réussi sans paraître être le vainqueur dans aucun créneau majeur. Cela pourrait signifier que je me trompe carrément pour voir la popularité de la langue de cette façon. Cela pourrait également signifier qu'une langue suffisamment bonne peut devenir populaire sans une application révolutionnaire pour favoriser l'adoption et l'acceptation, mais c'est très difficile et peut prendre beaucoup de temps. (Perl a une histoire similaire, mais est arrivé quelques années plus tôt et est maintenant moins utilisé.)

À partir de là, je peux dire quels langages fonctionnels sont à la hausse, à mon avis :

  • Clojure: programmation Web, en particulier à travers Heroku
  • Scala: Lift (ou peut-être jouer, ces jours-ci) - JVM sans Java

Si vous me demandiez où chercher des langages fonctionnels populaires, je vous conseillerais de rechercher un langage fonctionnel avec développement cloud clé en main (à la Heroku ou GAE) ou développement d'applications mobiles clé en main.

Jesse Millikan
la source
Je considérerais également Perl comme une langue majeure. C'est un langage plus ancien que je dirais qui est le plus souvent utilisé avec les systèmes de type Unix. Bien que Python semble être une alternative plus moderne. C'est toujours un langage populaire qui a beaucoup attiré l'attention et qui compte une grande communauté.
Despertar
1
@Despertar - Je n'essayais pas particulièrement d'être égalitaire à propos des langues que j'ai mentionnées :) Et, d'accord, l'histoire ressemble beaucoup à Python, à l'exception de quelques années auparavant.
Jesse Millikan
1
Perl avait quelques niches. La plus ancienne est reflétée dans les anciennes versions de sa documentation, qui désignait ce nom comme un acronyme pour "langage pratique d'extraction et de génération de rapports". La seconde est arrivée un peu plus tard: il s'agissait de scripts CGI - pendant de nombreuses années, perl était la langue du Web. Évidemment, cette popularité a perdu beaucoup de sa popularité maintenant, mais jetez un coup d'œil aux anciens sites Web qui fonctionnent toujours sur le même logiciel que celui avec lequel ils ont été créés, et vous verrez beaucoup de Perl (je pense à slashdot.org, maintenant , mais il y en a quelques autres).
Jules
9

Pour la même raison que Lisp n’a jamais vraiment attiré l’attention (laissez les flammes commencer!). La programmation fonctionnelle est un paradigme très étranger par rapport à la programmation impérative et orientée objet. Si, comme la grande majorité des étudiants CS, vous avez commencé par utiliser C et passé à C ++ / Java, vous ne voudrez généralement pas apprendre à penser de manière totalement orthogonale par rapport à ce que vous pensez normalement.

Chinmay Kanchi
la source
2
Paradigme extraterrestre? C'est plus proche des mathématiques que de la programmation impérative. Ici en Suède, je pense que la plupart des étudiants CS en université sont avant tout des programmes fonctionnels. Par exemple, nous avons commencé avec Standard ML, avant C, Erlang et Java.
Jonas
4
C'est suffisant. Je sais que de nombreux étudiants en ingénierie au Royaume-Uni et en Inde apprennent le C d'abord, suivi du C ++ et / ou de Java. Souvent, on ne leur apprend pas du tout une langue fonctionnelle.
Chinmay Kanchi
14
@Jonas Pour un certain nombre de personnes, les mathématiques sont un paradigme extraterrestre et tout ce qui éloigne les programmes des programmes les rend plus faciles à comprendre.
scriptocalypse
5
J'ai entendu parler de personnes n'ayant jamais entendu parler des arbres, encore moins de la programmation fonctionnelle, ayant obtenu leur diplôme.
dan_waterworth
1
@ Tux-D, en fait, non, je parle d'étudiants au Royaume-Uni.
dan_waterworth
6

Considérons les entreprises et la programmation.

Certaines entreprises utilisent leurs logiciels comme un atout stratégique. Ce n'est pas typique. Pour la plupart des entreprises, l’informatique représente un élément essentiel des activités réelles de l’entreprise. C'est une dépense nécessaire. Ils sont conservateurs, car ils savent que pour X $, ils peuvent obtenir le matériel informatique dont ils ont besoin. En passant à autre chose, ils économiseront moins que X $ si tout va bien et ils perdront gros si tout va mal.

De plus, dans les entreprises, la solution la moins coûteuse est généralement celle qu’elles ont faite hier. Le changement, cependant, souhaitable, coûte cher. Si une entreprise devait passer d'une solution C # / .NET, même à F #, elle aurait des problèmes. Leurs programmeurs (qui ne sont probablement pas les plus perspicaces du monde) devraient apprendre une nouvelle langue, maîtriser les deux langues et les utiliser fréquemment. Il y aurait des routines écrites dans les deux pendant longtemps. S'ils devaient passer à quelque chose comme Haskell, ou s'ils utilisaient C ++ / MFC en premier lieu, ils changeraient beaucoup plus, ce qui coûterait beaucoup plus cher.

En outre, il y aura une réserve de programmeurs C # et une assistance continue de Microsoft pendant encore longtemps. On peut compter sur les pratiques informatiques actuelles. Il n’ya pas le même niveau de soutien institutionnel ou d’assurance de la disponibilité continue des programmeurs.

Par conséquent, pour la plupart des entreprises, une modification de la programmation fonctionnelle coûterait cher au départ et ne serait rentabilisée que si la réduction des coûts informatiques était suffisante à long terme, à moins que celle-ci soit potentiellement incertaine.

David Thornley
la source
2

Vous écrivez déjà du code dans un style fonctionnel, mais vous ne le savez pas.

Lorsque vous devez effectuer des tests unitaires pour votre code, vous avez tendance à écrire des fonctions testables, qui ne créent ni ne dépendent d'effets secondaires, et renvoient toujours le même résultat sur les mêmes arguments (fonctions dites pures). C'est le principal avantage des programmes fonctionnels.

Je pense que les langages fonctionnels sont trop limitants. Ainsi, au lieu de remplacer les langages impératifs par des langages fonctionnels, les impératifs auront des fonctionnalités fonctionnelles. De nos jours, presque tous les langages de programmation ont des fermetures et des lambdas.

Calmarius
la source
1

Je crois qu'il n'y a qu'une seule vraie réponse à votre question. Vous pouvez entrer dans beaucoup de raisons connexes pour lesquelles cette réponse est le cas, mais ce sont des questions différentes.

C'est ici:

  • Les architectes logiciels fournissent des solutions dont ils sont convaincus qu'ils fonctionneront.
  • La majorité des architectes ne travaillent pas dans des langages fonctionnels.
  • Une fois les technologies et les langues choisies, les entreprises trouvent des personnes capables de travailler avec elles.

Est-ce que ça prend? Tout dépend si les personnes qui ont confiance en l'utilisation de langages fonctionnels deviennent des architectes et choisissent de l'utiliser pour les projets sur lesquels ils travaillent.

John Fisher
la source
0

Le vrai problème est l'état.

Les langages fonctionnels n'ont pas d'état global. La plupart des problèmes industriels nécessitent un état à grande échelle (comment représenter un grand livre ou un ensemble de transactions) même si certaines fonctions à petite échelle ne l'exigent pas réellement (traitement d'un grand livre).

Mais nous utilisons du code sur des machines à architecture Von-Neuman qui sont par nature saturées. Nous ne nous sommes donc pas débarrassés de l'état, les langages fonctionnels cachent simplement la complexité de l'état au développeur. Cela signifie que le langage / le compilateur doit gérer et gérer l'état dans les coulisses.

Ainsi, bien que les langages fonctionnels n'aient pas d'état global, leurs informations d'état sont transmises en tant que paramètres et résultat.

La question est donc de savoir si le langage peut gérer efficacement l’État derrière le sens. Surtout quand la taille des données dépasse de loin la taille de l'architecture.

En regardant de côté du matériel

Le système d'exploitation a beaucoup aidé ces dernières années à visualiser l'espace d'adressage, de sorte que les applications n'ont pas à s'en préoccuper officiellement. Mais les applications qui ne craignent rien tombent dans le piège de la destruction du matériel lorsque la pression de la mémoire devient intense (la suppression du matériel ralentira considérablement vos processus).

Comme le programmeur n'a pas de contrôle direct sur l'état dans le langage fonctionnel, il doit s'appuyer sur le compilateur pour gérer cela et je n'ai pas vu de langages fonctionnels qui le traitent bien.

Sur le revers de la médaille, le programmeur à état plein a un contrôle direct sur l'état et peut ainsi compenser les conditions de mémoire insuffisante. Bien que je n’aie pas vu beaucoup de programmeurs assez intelligents pour le faire.

En regardant du côté de l'industrie:

L’industrie a beaucoup de programmeurs inefficaces, pleins d’états.

Mais il est facile de mesurer les améliorations apportées à ces programmes au fil du temps. Vous posez une équipe de développeurs sur le problème, ils peuvent améliorer le code en améliorant la façon dont le programme gère l’état.

Pour les programmes fonctionnels, les améliorations sont plus difficiles à mesurer, car vous devez améliorer les outils qui les amélioreront (nous examinons simplement la manière dont les applications gèrent efficacement l'état sous-jacent, et non l'amélioration globale du programme).

Donc, pour l’industrie, je pense que cela dépend de la capacité de mesurer les améliorations apportées au code.

Du point de vue de l'embauche

Il y a beaucoup de programmeurs stat-full disponibles à la location. Les programmeurs fonctionnels sont difficiles à trouver. Ainsi, votre modèle de base d’offre et de demande entrerait en jeu si l’industrie basculait vers la programmation de style fonctionnel, ce qu’elle ne souhaitait pas (les programmeurs sont assez chers en l’état).

Martin York
la source
2
Les langages fonctionnels, en particulier les langages fonctionnels "impurs", peuvent parfaitement gérer l'état global. Je constate que les programmes se décomposent souvent en couches alternées: par exemple, un état global ... mais des transitions d'état fonctionnels ... avec des états locaux (masqués) occasionnels pour implémenter des parties essentielles à la performance de ces transitions, etc. Le problème des langages impératifs , IMO , c’est qu’ils amènent souvent les programmeurs à utiliser l’état de manière inappropriée, lorsque les modèles fonctionnels fonctionnent mieux. Mais les langues semblent évoluer dans le sens d’une bonne prise en charge des deux styles.
Ryan Culpepper
1
Il est très facile de gérer l'état dans les langages fonctionnels, mais cela nécessite un changement d'emphase. Tandis que dans les langages impératifs, vous écrivez des procédures qui modifient un état, dans des langages fonctionnels, vous écrivez des fonctions qui renvoient des procédures qui modifient un état.
dan_waterworth
"Les langages fonctionnels n'ont pas d'état global" - Vous n'avez pas besoin d'état global. Pratiquement toute la gestion de l’État peut se faire à travers des monades.
Arunav Sanyal
-3

Cette question a une prémisse légèrement fausse. Pour les raisons suivantes:

  1. La programmation fonctionnelle est en fait assez commune dans l'industrie. Mais il n'est utilisé que là où des programmeurs expérimentés sont disponibles. On ne peut s’attendre à ce que les débutants le sachent. Presque tous les grands projets de programmation l'utilisent, mais ils ne la conservent que dans des domaines gérés par des programmeurs expérimentés. Les débutants s’occuperont des modules faciles qui ne nécessitent pas de programmation fonctionnelle.
  2. Compte tenu de cette réalité, les entreprises qui recrutent des personnes (généralement des jeunes venant d'universités) ne peuvent pas vraiment demander une expérience de la programmation fonctionnelle. Toute personne impliquée dans des projets nécessitant une programmation fonctionnelle fait partie de la même entreprise depuis 15 ans.
  3. Les universités commencent à l'enseigner, car elles savent déjà que les connaissances en programmation fonctionnelle seront très utiles dans 30 ans. Leur plage de temps est dans 30 ans, pas le semestre normal comme dans les entreprises.
  4. Ces raisons sont la raison pour laquelle les gens sont déçus lorsqu'ils entrent sur le marché du travail et constatent que les éléments qu'ils ont appris à l'université ne sont pas utilisés. Mais ils ont été conçus pour durer 30 ans et il sera utile à terme - c’est que les entreprises utilisent simplement ce qu’il leur faut - ce qu’elles peuvent s’attendre à ce que les gens sachent.
  5. De plus, vous seriez arrogant si vous pensez qu'après plusieurs années d'université, vous maîtrisez suffisamment bien la programmation fonctionnelle pour l'utiliser dans des projets logiciels réels. Commencez par les choses simples en premier. Lorsque vous commencez à travailler, vous n'avez pas vraiment besoin d'utiliser le logiciel le plus complexe. Vous finirez par arriver à la complexité, mais cela prend du temps.
tp1
la source
2
1) "presque tous les grands projets de programmation l'utilisent". Mon expérience est que ceci est loin de la réalité. Très peu d'entreprises utilisent la programmation fonctionnelle comme je le sais. La plupart utilisent uniquement Java et C # (même si C # ont des constructions plus fonctionnelles ces dernières années), C ++ et C.
Jonas
2
2) Mon expérience est le contraire. Les universitaires semblent être les seuls à connaître la programmation fonctionnelle. Ici en Suède, la plupart des universités enseignent la programmation fonctionnelle dès la première année. Et des universités comme le MIT ont jusqu'à récemment utilisé la programmation fonctionnelle dans leur premier cours de programmation (Scheme).
Jonas
@ jonas: non, le langage de programmation n'a rien à voir avec cela. Bien sûr, C et C ++, Java, etc. sont utilisés par un grand nombre de projets. La programmation fonctionnelle fonctionne également en code c ++. La pratique actuelle semble être qu'une partie du projet utilise OO et une partie utilise la programmation fonctionnelle. Les deux parties utilisent le même langage (généralement c / c ++)
tp1
Ouais, vous pouvez faire OO en C aussi. Mais ce n'est pas recommandé. C et C ++ n’ont pas beaucoup de constructions pour la programmation fonctionnelle, c’est-à-dire qu’ils ne sont pas immuables par défaut, qu’ils ne prennent pas en charge l’appariement de modèles, qu’aucune infrastructure de données immuable n’est incluse, etc. ...
Jonas
Eh bien, c'est pourquoi cela nécessite des programmeurs expérimentés. Comme il est quasiment impossible de changer le langage de programmation par rapport au grand public, la meilleure chose à faire est de faire de la programmation fonctionnelle en c ++. Aussi c ++ a des choses comme const qui aident beaucoup.
tp1
-10

Parce qu'il est plus difficile de déboguer la FP.

interstar
la source
11
Je ne suis pas d'accord. Sans effets collatéraux, le processus de débogage est plus facile. Vous pensez peut-être que c'est plus difficile, car le paradigme fonctionnel est différent et a besoin d'expérience pour se familiariser avec une nouvelle façon de faire, y compris le débogage.
Maniero
2
Les langages de programmation fonctionnels sont en réalité plus faciles à tester, car les fonctions pures sont sans état.
Jonas
4
Jonas, je n'ai pas dit "test", j'ai dit "debug" c'est-à-dire. trouvez une erreur que vous avez commise. Les tests en font partie, mais le raisonnement à propos du programme, etc., en vaut la chandelle - je m'en tiens à cela. C'est une fonction du pouvoir de FP. Plus une ligne de code est lourde, plus il est difficile de déterminer quelle ligne de code pose problème. La correspondance entre la ligne de code et l'effet est plus diffuse, par exemple. une seule fonction d'ordre supérieur peut toucher des dizaines de comportements du programme et inversement. Les symptômes peuvent varier énormément entre différents points pour la même erreur.
Interstar
D'après mon expérience, il n'est pas difficile de déboguer du tout. J'utilise F # et je ne trouve aucune raison pour laquelle vous trouveriez plus difficile de déboguer que C # par exemple. Le débogage est peut-être plus difficile à Haskell à cause de la paresse (je n'en ai aucune idée), mais la programmation ardente de la PF est plus simple en raison de l'apatridie, comme l'a dit Jonas. En d'autres termes, le code de PF est plus prévisible, car vous savez que le résultat n'est pas influencé par des variables invisibles.
Mohammed Alkarouri
2
Tant que vos fonctions sont pures, le débogage est facile. Si vous ne pouvez pas déboguer en ajoutant des tests unitaires, alors vous ne faites pas un travail adéquat d'écriture de tests.
dan_waterworth