Le langage Haskell est-il suffisamment populaire ?

[Idelways]

Le langage Haskell est-il suffisamment populaire ?
Notamment dans l'industrie ? Non répond un développeur, qui propose des pistes de réflexion



Haskell est un langage de programmation fonctionnel fondé sur le lambda-calcul et la logique combinatoire. Créé en 1985, il doit son nom au mathématicien Haskell Brooks Curry.

Bien qu'ayant bénéficié d'énormément de recherches, il semble pourtant peiner à imposer.

C'est en tout cas la vision des choses de certains développeurs.

Sam Martin est un développeur Anglais, chef de projet à Geometrics où il travaille sur « Enlighten », une plateforme d'éclairage et de radiosité en temps-réel pour les jeux vidéo.

Dans un article sur son blog, il analyse les raisons de l'impopularité du langage de programmation fonctionnel « Haskell » dans le milieu industriel alors que celui-ci n'est pas dénué de qualité dans cet univers. Bien au contraire, il aurait tout pour s'y imposer.

Sam Martin avance plusieurs pistes – dont certaines plus ou moins ironiques – pour expliquer cet état de fait.

Tout d'abord « personne n'entend parler » de Haskell. Ce qui expliquerait qu'il soit « impopulaire » puisque l'on confondrait trop souvent popularité et qualité.

Cette impopularité le rendrait également « risqué ». Aucune entreprise ne veut être la première à l'utiliser surtout qu'il est difficile de recruter des développeurs maitrisant Hashkell. Ou à les y former.

Haskell serait enfin, et surtout, « différent » et la différence fait peur. Elle donnerait l'impression que le langage est difficile et liée à une communauté élitiste.

Mais la raison la plus importante, selon l'auteur, serait ses librairies. Elles seraient nombreuses mais de pas assez « bonne qualité », et « déconnectées du monde réel » et accusant de « multiples incompatibilités ».

Aussi, les plus importantes librairies ne peuvent « compiler sous Windows ».

L'« imprévisibilité des performances » des programmes écrits en Haskell seraient donc un frein à son adoption.

La conclusion, plus générale, de Sam Martin, pose la question de savoir où se situe l'objectif principal des sociétés.

Pour lui, elles ne sacrifieraient la correction et la qualité d'un code au bénéfice d'une sortie rapide, quitte à facturer les corrections par la suite aux clients.

Une logique ô combien contraire à Haskell. Et finalement le plus gros frein à son développement.

Une question de mentalité en quelque sorte ?

Et vous, en tant que développeur ou manager, quelles sont les raisons qui vous empêchent (ou vous empêcheraient) d'utiliser Haskell dans votre entreprise ?

Pensez-vous que les sociétés sacrifient la correction et la qualité d'un code au bénéfice d'une sortie rapide ?




Source : Blog Sam Martin


Lire aussi :

L'inventeur du XML plaide pour la programmation concurrente et fonctionnelle, elle serait mieux adaptée aux progrès liés aux CPU multi-coeurs

Qu'est-ce qu'un langage fonctionnel

Les rubriques (actu, forums, tutos) de Développez :

Langages
Forum Haskell
Solutions d'entreprise



En collaboration avec Gordon Fowler

[bhamp0]

Haskell est très peu répandu en France ... Globalement, j'ai fait de l'ocaml en France et du Haskell au Royaume-Uni.
Mais à l'heure actuelle, allez sur Monster, et faites une recherche du terme "Haskell" sur le territoire national : il n'y a pas d'offre. S'il n'y a pas d'offre, il n'y aura pas de demande

[david06600]

Envoyé par bhamp0

Mais à l'heure actuelle, allez sur Monster, et faites une recherche du terme "Haskell" sur le territoire national : il n'y a pas d'offre. S'il n'y a pas d'offre, il n'y aura pas de demande

Pareil pour Caml ou Ocaml sur Monster. Je pense qu'il y a pas vraiment de demandes de développeurs sur un langage fonctionnel. Les entreprises n'y voient pas d'avantages et ne connaissent pas vraiment, ou ne sont pas prêtes à investir.
L'aspect mathématique pourrait aussi en refroidir plus d'un, je pense que l'on peut ajouter cela à la liste des raisons.

[csperandio]

Quelle coïncidence pour moi. Je me suis intéressé à Haskell depuis 2 semaines et je suis en train de lire Real World Haskell. Ce langage est vraiment trés intéressant mais, mon coeur balance entre soit apprendre ce langage soit approfondir mes connaissances Groovy qui mélange programmation objet, impérative et fonctionnelle.
Mon plus gros problème avec Haskell est l'absence d'idée sur ses performances :/ Dans mon travail, je travaille avec des chaines textes que j'analyse, transforme, codifie. Ces données venant essentiellement de fichier texte CSV. Quelq'un sait-il si Haskell est performant pour ce genre de travail ? Cela m'embêterait de prendre de temps à son apprentissage pour à la fin me rendre compte qu'il n'est pas utilisable :/

[ChipsterJulien]

Envoyé par csperandio

Dans mon travail, je travaille avec des chaines textes que j'analyse, transforme, codifie. Ces données venant essentiellement de fichier texte CSV. Quelq'un sait-il si Haskell est performant pour ce genre de travail ? Cela m'embêterait de prendre de temps à son apprentissage pour à la fin me rendre compte qu'il n'est pas utilisable :/

Pour traiter les chaines de caractères, le langage le plus adapté est certainement perl

[palnap]

Je connais pas vraiment Haskell, mais les langages fonctionnels permettent effectivement une productivité accrue (plus d'expressivité => moins de lignes de code => moins de temps passé à coder) mais je pense qu'outre le temps de formation des pros du C++/Java/que-sais-je aux langages fonctionnels (qui nécessitent tout de même un cheminement intellectuel différent), le principal problème est la difficulté lors de la relecture de code.

Je me rappelle d'un point assez intéressant dans la doc de Qt qui pour justifier la verbosité de l'API disait qu'une ligne de code est écrite une fois mais est relue beaucoup plus et qu'il était nécessaire d'adopter une syntaxe et des conventions de nommage allant dans ce sens. Du coup le choix d'Haskell n'est-il pas dangereux en ce qui concerne la maintenance et l'évolutivité d'une app?

De plus, je pense que les langages fonctionnels sont souvent écrits par/pour des mathématiciens, je ferai donc moyennement confiance aux types me vantant leur simplicité et leur adéquation au milieu industriel !

[lex2004]

L'impression que j'en ai toujours eu c'est que c'est clairement un truc de fac.

[kpouer]

Le problème de ces langages, c'est qu'ils sont peu connus, du coup une entreprise sera frileuse à l'idée de développer un projet avec sans avoir tellement de visibilité sur le fait qu'il va évoluer ou rester figé, qu'il sera difficile de trouver des ressources sur le sujet. Encore plus difficile de trouver des développeurs pour maintenir le projet si ceux qui sont là s'en vont ...

[PerlPicker]

je pense que le manque de librairies et de développeurs sont les 2 freins principaux pour une utilisation industrielle. On est à peu près sur de trouver ce qu'il faut en choisissant un langage répandu. On a aussi plus de chance qu'une librairie utilisée pas beaucoup de gens fonctionne réellement et que les mises à jours/corrections soient fréquentes.

L'idée que la qualité ou serait améliorée avec un langage fonctionnel me semble totalement fausse. La qualité vient d'abord du bon travail de l'équipe (bonne conception, tests, bonne organisation ...) que du langage. Un langage peu répandu amène le risque d'avoir à utiliser des développeurs moins expérimentés sur le langage ce qui peut amener à une conception mal faite et des problèmes de performances et de maintenance.

Il faut je crois utiliser les langages fonctionnels quand ils amènent un plus important pour un problème particulier, par exemple pour fournir une grande scalabilité ce qui devient de plus en plus important avec la multiplication des cores sur les cpu et la disponibilité de nombreuses cpu à la demande. Haskell ou ocaml me semblent très universitaires mais Erlang a été conçu par un industriel pour résoudre des problèmes concrets. Un langage que j'envisagerais pour une application qui doit pouvoir être très distribuée et robuste.

[HanLee]

Je reviens juste sur cette phrase...

Envoyé par palnap

De plus, je pense que les langages fonctionnels sont souvent écrits par/pour des mathématiciens, je ferai donc moyennement confiance aux types me vantant leur simplicité et leur adéquation au milieu industriel !

Parce que chez les industriels, personne n'a fait de mathématiques ?
Franchement, dans les langages fonctionnels, la seule chose de mathématique qu'on devrait comprendre, c'est le concept de fonction, les simplicités et mécanismes qui peuvent en découler (composition et curryfication). Rien que ça suffit !

Un peu de reformatage de son mode de pensée via des exercices mentaux suffisent en une poignée de jours à s'adapter assez bien.

Je pense aussi qu'il y a une certaine répulsion culturelle et un effet de mode à dire "beurk, des maths..." à cause du traumatisme (c'est un peu fort) scolaire de beaucoup de gens.
On ne demande pas l'impossible non plus !

----

Sinon pour en revenir au sujet, je pense qu'ils ne perceront jamais, mais que les langages évoluent pour intégrer les aspects des langages fonctionnels.

Voir C# avec ses lambda, C++ aussi...

Ah non, une exception, il y a F#, totalement compatible .NET qui profite donc de tous ses avantages (et vice-versa, les autres langages .NET peuvent utiliser une bibliothèque écrite en F# très simplement).

Et on pourra remarquer à juste titre que .NET dans sa version 4 fait la part belle au style fonctionnel pour la programmation concurrente ou asynchrone.

[amaury pouly]

Je ne me prononce pas sur le débat sans fin impératif contre fonctionnel parce que*j'ai déjà tranché pour moi Mais par contre j'aimerais parler de la lisibilité.

Un argument que l'on retrouver souvent dans le débat est celui de palnap (qui donne aussi son contraire):

plus d'expressivité => moins de lignes de code => moins de temps passé à coder

Je suis 100% d'accord avec cela et je pense aussi que ce genre d'argument passe à 100Km du débat. Pourquoi ? Parce que cela se saurait si l'on écrivait du code que pour soit. Or la lisibilité est importante. C'est débile de gagner 10% en productivité si le temps de maintenance augmente de 50% juste parce que le code produit est moins lisible.

Avec les languages fonctionnels, je trouve que c'est plutôt le cas. Un argument que j'entends souvent est qu'il inutile de donner le type des arguments, des variables car il est inféré. Mais personne n'est dupe, les types existe en grande partie pour les développeurs. Le fait qu'ils soient écrits, de façon redondante dans de nombreux language contribue à la lisibilité, on voit le type au premier coup d'oeil. Je pense que c'est un fait à ne pas négliger car dans un gros projet, on doit relire le code de quelqu'un d'autre très souvent et on a pas envie de passer des heures à fait tourner le code mentalement juste pour inférer les types parce que le code n'est pas documenter.

On peut me dire que je suis un peu malhonnête (et c'est vrai ) parce que dans les languages fonctionnels on peut aussi mettre les types explicitement mais qui le fait ?

Après ce n'est qu'un avis parmi tant d'autre, il y a probablement de nombreuses raisons, bonnes et mauvaises pour lesquels les languages fonctionnels ne percent pas. Probablement que le simple fait de changer de language représente un coup prohibitif et qu'au fond, ce n'est pas seulement une question d'impératif VS fonctionnel. C'est un peu un cercle vicieux.

[GanYoshi]

Je ne connais pas du tout ce langage, mais apparemment :

- Il est difficile
- Il est pas performant
- Il est pas portable
- Il a des librairies pourries et peu nombreuses
- Il n'est pas adapté au mode de facturation des entreprises
- Le code se relit difficilement

Et il est juste plus expressif en contrepartie.

Je pense que le souci vient de là.

[Alp]

Haskell n'a été fait ni par des mathématiciens, ni pour des mathématiciens. Il a été créé par des chercheurs en informatique, tout comme la plupart des langages qui existent.

Evidemment le post juste avant le mien est un ramassis de bêtises assez impressionnant. Il n'y a qu'à aller voir les perfs de Haskell sur le "language shootout"... Il se place souvent entre C++ et Java, bien qu'il arrive qu'il soit derrière Java.

Ensuite, les langages fonctionnels ne sont pas moins lisibles. C'est juste que le cerveau de 99.99999% des gens ici est formaté à l'OO ou au procédural. Et à des types de syntaxe très proches. Là ça change, et du coup faut se réadapter, c'est vrai que c'est beaucoup demander à un grand nombre d'entre vous. Pour les types, tu ne sais pas vraiment combien c'est important avant de programmer avec OCaml ou Haskell, leurs systèmes de type sont bien plus complet que les bêtes systèmes de type d'OO de Java, C# et compagnie.

De toute manière ça servirait à rien de trop développer le sujet ici bien que j'aurais beaucoup à dire, parce que 99.9999% d'entre vous sont trop fermés pour ne serait-ce qu'être réceptifs à une explication détaillée des avantages et défauts ***REELS*** d'Haskell, et non pas les bêtises balancées ici par 2 ou 3 clampins qui n'y connaissent rien.

[david06600]

Envoyé par Alp

De toute manière ça servirait à rien de trop développer le sujet ici bien que j'aurais beaucoup à dire, parce que 99.9999% d'entre vous sont trop fermés pour ne serait-ce qu'être réceptifs à une explication détaillée des avantages et défauts ***REELS*** d'Haskell, et non pas les bêtises balancées ici par 2 ou 3 clampins qui n'y connaissent rien.

Ben non vas y si tu as envi d'expliquer, moi ça m'intéresse et je pense pas être le seul.

[Alp]

Envoyé par david06600

Ben non vas y si tu as envi d'expliquer, moi ça m'intéresse et je pense pas être le seul.

Je l'ai déjà fait de vive voix comme sur internet, l'expérience me montre que les gens sont trop fermés pour ne serait-ce que comprendre les bénéfices qu'on tire de l'apprentissage d'Haskell, ainsi que pour comprendre ses qualités et défauts réels.

En attendant j'ai pas envie de me fatiguer à moins de voir un réel intérêt de la part des gens pour ce que j'ai mentionné ci-dessus.
Donc faudra se contenter de ressources comme :
http://www.haskell.org/haskellwiki/Why_Haskell_matters
Ou encore carrément : http://www.google.fr/#hl=fr&source=h...4a7da555a59877

Mais quand je vois déjà que les gens sortent l'argument de la lisibilité ou je sais pas quoi, stop quoi... "Moi j'arrive pas à comprendre quand je lis du Haskell, alors c'est forcément pas lisible!"
"Ah, j'ai oublié de dire que j'ai fait que du Java/C/C++/C#/... toute ma vie donc ouais j'suis pas habitué à cette syntaxe, mais c'est pas lisible quand même!!!!"

[david06600]

Envoyé par Alp

Mais quand je vois déjà que les gens sortent l'argument de la lisibilité ou je sais pas quoi, stop quoi... "Moi j'arrive pas à comprendre quand je lis du Haskell, alors c'est forcément pas lisible!"
"Ah, j'ai oublié de dire que j'ai fait que du Java/C/C++/C#/... toute ma vie donc ouais j'suis pas habitué à cette syntaxe, mais c'est pas lisible quand même!!!!"

Ahaha, je comprends ce que tu ressens, en tout cas moi ça m'intéresse comme langage, et j'ai commencé à m'y mettre il n'y a pas très longtemps, pour changer un peu et j'aime bien le concept. Mais c'est dommage qu'il ne soit pas plus utilisé je trouve. C'est peut-être au développeur de faire force de proposition en en vantant les mérites aussi.
Pour quelles types d'applications est ce que le paradigme fonctionnel serait vraiment utile ?

[Alp]

Envoyé par david06600

Ahaha, je comprends ce que tu ressens, en tout cas moi ça m'intéresse comme langage, et j'ai commencé à m'y mettre il n'y a pas très longtemps, pour changer un peu et j'aime bien le concept. Mais c'est dommage qu'il ne soit pas plus utilisé je trouve. C'est peut-être au développeur de faire force de proposition en en vantant les mérites aussi.
Pour quelles types d'applications est-ce que le paradigme fonctionnel serait vraiment utile ?

Toutes. A part le temps réel, car les perfs ne sont pas encore suffisantes pour ça, et on a pas encore de VM (notamment Garbage Collector) pour le temps réel.

Et sinon, juste à titre informatif, avant de faire du OCaml et du Haskell, j'étais à fond dans le C++ (et le suis +- toujours). Donc je ne suis pas fermé sur le Haskell.

[david06600]

Envoyé par Alp

Toutes. A part le temps réel, car les perfs ne sont pas encore suffisantes pour ça, et on a pas encore de VM (notamment Garbage Collector) pour le temps réel.

Et sinon, juste à titre informatif, avant de faire du OCaml et du Haskell, j'étais à fond dans le C++ (et le suis +- toujours). Donc je ne suis pas fermé sur le Haskell.

Moi je n'ai pas regardé le Haskell, uniquement Ocaml sur le site de l'inria.
Sinon est ce vraiment productif comme langage, une fois qu'on le maitrise, parce qu'une société s'en fout un peu de la techno du moment que ça peut lui faire gagner de l'argent. D'après ce que j'ai lu c'est surtout que le logiciel est beaucoup plus sur (moins de bug), du fait de l'inférence de type entre autre.
Niveau EDI et bibliothèques est ce suffisamment développé actuellement ? Communauté ?
Si eclipse ou netbeans intégrait un plugin permettant de développé en Haskell ou Ocaml ça aiderait peut être aussi.

[el_slapper]

Est-ce que c'est accessible à un type d'intelligence moyenne? Est-ce qu'un type d'intelligence moyenne saura faire un code propre et efficace avec? Ou est-ce qu'il faut un cador?

Je pose la question, j'en sais rien, jamais vu Haskell. Juste, ça me parait important pour une utilisation industrielle. Un truc génial que seuls quelques génies peuvent utiliser n'a pas sa place dans l'économie.

[Alp]

Envoyé par david06600

Moi je n'ai pas regardé le Haskell, uniquement Ocaml sur le site de l'inria.
Sinon est ce vraiment productif comme langage, une fois qu'on le maitrise, parce qu'une société s'en fout un peu de la techno du moment que ça peut lui faire gagner de l'argent. D'après ce que j'ai lu c'est surtout que le logiciel est beaucoup plus sur (moins de bug), du fait de l'inférence de type entre autre.

Une fois que tu le connais ça va très vite de développer avec oui. Ce n'est pas pour rien que des grands noms de l'industrie info s'en servent.

Envoyé par david06600

Niveau EDI et bibliothèques est-ce suffisamment développé actuellement ? Communauté ?
Si eclipse ou netbeans intégrait un plugin permettant de développé en Haskell ou Ocaml ça aiderait peut être aussi.

La communauté est *géniale*. La mentalité ambiante est "ceux qui ne s'intéressent pas à Haskell bah tant pis pour eux, on ne va pas évangéliser partout. Ceux qui s'y intéressent peuvent compter sur nous s'ils ne comprennent pas quelque chose, ont besoin d'un coup de main, etc."
Niveau EDI il y en a un qui est assez développé (leksah), et il y a quelques éditeurs ou des modes pour les éditeurs connus. Et il y a même un plugin eclipse qui avait été commencé, mais je n'ai pas trop suivi (eclipsefp).

Envoyé par el_slapper

Est-ce que c'est accessible à un type d'intelligence moyenne? Est-ce qu'un type d'intelligence moyenne saura faire un code propre et efficace avec? Ou est-ce qu'il faut un cador?

Il faut être motivé. C'est la curiosité intellectuelle, la passion pour les langages de programmation, qui doit te motiver. Parce que programmer en Haskell c'est trèèèèèèès très différent de programmer en Java, C++, C# ou autre. Il faut que tu prennes du recul sur ce que tu sais pour intégrer qu'il n'y a pas que la façon OO ou procédurale de faire. En partant de là, bah y'a les ressources nécessaires (livres, articles, ...) si tu veux apprendre. Et t'as pas besoin de sortir d'un Ph.D à MIT ou Stanford pour savoir faire du Haskell. Après, c'est comme avec tout langage, si tu veux faire un code propre, efficace et maintenable facilement, il te faut de l'expérience, il faut que tu comprennes ton langage etc. Il y a des concepts en Haskell non présents dans les langages que tu connais et il faut les comprendre pour écrire le code le plus efficace possible.
Une chose à savoir est que étant donné que le langage est très différent de l'impératif, le compilo a un gros boulot à faire, et il se trouve qu'il y a pleins d'optimisations assez agressives qui sont faites par le compilateur. Si tu te lances dedans tu découvriras tout ça.
Autre chose : un des gros points forts de Haskell, c'est qu'il est presque enfantin d'écrire pour du multicoeur, enfin pour en bénéficier au maximum. En comparaison aux langages mainstream, c'est trivial. Justement grâce à la "pureté" d'Haskell.

Envoyé par el_slapper

Je pose la question, j'en sais rien, jamais vu Haskell. Juste, ça me parait important pour une utilisation industrielle. Un truc génial que seuls quelques génies peuvent utiliser n'a pas sa place dans l'économie.

Le problème c'est que beaucoup de gens dans l'info sont soit fermés soit refusent de faire trop d'effort pour se former à un truc tout nouveau une fois qu'ils sont sur le marché du travail. Il n'y a rien de complexissime en soi en Haskell, c'est juste que presque tout y est différent, ça demande du temps si t'as pas été formé aux langages fonctionnels pendant tes études ou quoi. Enfin, les raisons qui font que ce n'est pas mainstream sont diverses et variées (par exemple, ce n'était pas si performant que ça jusqu'à il y a 5 ans je crois).

Pour terminer, parmi les utilisateurs "connus" de Haskell, il y a Microsoft (qui finance une partie du dev de GHC, le compilateur principal pour Haskell), Facebook, Google, Intel aussi je crois. A noter que Haskell est excessivement pratique pour tout ce qui concerne le parsing également (ce pour quoi Facebook l'utilise d'ailleurs).

Voilà, en espérant que vous y voyiez plus clair, bien que la meilleure façon d'en savoir plus, c'est d'aller lire un peu les différents articles sur Haskell, en prenant du recul (il faudrait drolement de la chance pour tomber sur un article 100% objectif... vous tomberez généralement soit sur des articles de fanboys, soit sur des articles de mecs anti-haskell), ainsi que le HaskellWiki qui est un excellent concentré d'informations sur Haskell.