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?

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!

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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