Discussion :

[Florian Goo]

Il y a aussi le livre Real World Haskell, dont l'introduction donne vraiment envie de s'y mettre : http://book.realworldhaskell.org/read/
L'intégralité du livre est accessible gratuitement sur internet et également édité chez O'Reilly.

[Alp]

Il y a aussi http://www.learnyouahaskell.com/ qui va moins loin mais est plus "ludique".

Au fait, pour ceux que ça intéresse, Tim Sweeney parle de Haskell ici : [ame="http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language-A-Game-Developers-Perspective-by-Tim-Sweeney"]The Next Mainstream Programming Language: A Game Developer's Perspective by Tim Sweeney[/ame]

[pcaboche]

Avec les languages fonctionnels, je trouve que c'est plutôt le cas. Un argument que j'entend 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éveloppeur. Le fait qu'ils soient écrit, de facon 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.

Sauf que l'intérêt principal de l'inférence de type, ce n'est pas juste de réduire la taille du code ou le nombre de frappes au clavier...

Non.

L'un des intérêts que je vois dans l'inférence de type, c'est la vérification de la cohérence des types tout au long du programme. Pour faire simple, si le compilateur n'arrive pas à inférer un type (ou si le type inféré n'est pas le type attendu), c'est qu'il y a un problème quelque part (pour caricaturer, c'est comme si on voulait faire rentrer le rond dans le carré).

Un autre intérêt de l'inférence de type est la possibilité de spécialiser une fonction à partir d'une fonction plus générale. Un peu à la manière des templates du C++ ou des generics de Java/C#... mais en plus élégant. C'est d'ailleurs dans ce cadre qu'on peut spécifier les types des paramètres explicitement.


Bref (et sans vouloir être méchant envers toi), quand on déclare que l'inférence de type sert principalement à réduire la taille du code, c'est qu'on a une vision très réduite de la programmation fonctionnelle.

Et malheureusement, ce sont souvent les gens qui n'y connaissent rien et n'ont strictement aucune ouverture d'esprit qui font le plus de commentaires du genre: "ouais, la programmation fonctionnelle, c'est nul !" (c'est une constatation générale, ne le prend pas à titre personnel)


Comme l'a très bien dit Alp, la programmation fonctionnelle (pas seulement en Haskel) c'est une manière différente de penser et si on veut bien comprendre... ben il n'y a pas de secret, c'est comme tout : il faut passer du temps dessus.

[gorgonite]

pour infos, l'inférence de types n'a rien d'obligatoire dans la programmation fonctionnelle... prenez les langages de la famille Lisp & Scheme, ils sont à la programmation fonctionnelle ce que Ruby est à C++. par exemple apply détruit tous les systèmes d'inférences classiques (un peu de lecture en anglais pour les curieux)

[Florian Goo]

prenez les langages de la famille Lisp & Scheme, ils sont à la programmation fonctionnelle ce que Ruby est à C++

J'ai pas bien saisi le rapprochement… ?

[pcaboche]

Ce point là me paraît très important :

Correctness. Most companies don’t give a **** about correctness. They don’t care about quality. They just want to shovel code out the door as fast as possible and earn wads of cash. If there are bugs, they’ll charge the customer money to fix them. Getting code right is of no interest; getting code fast is what counts. Haskell is a language that rewards those who sit back and deeply analyse the problem, and then produce a beautiful solution. Most companies don’t care for this approach; let’s just hack something together as fast as possible, and worry about fixing it later (i.e., never).

Les 2 seules questions qui intéressent le client sont :

1. combien ça va coûter ?
2. quand est-ce qu'on est livré ?

Le reste, il s'en fout.

En effet, essayez donc de dire à votre client : "je peux vous faire votre projet, mais ça prendra un peu plus de temps et coûtera donc un peu plus cher. En contrepartie, le programme sera mieux écrit et plus correct", comme ça, juste pour rigoler. Il y a de fortes chances que votre client confie le projet à un concurrent...

Le client ne voit quasiment jamais à long terme. Il choisit l'offre la moins chère, et quand les problèmes arrivent, il paye des correctifs.

Le client ne sait pas définir ses besoins, il veut "un truc qui marche" mais il ne sait pas dire comment. Et puis il change tout le temps d'avis, donc ça sert à rien de faire un truc bien pensé dès le départ.

Le client se fout de la flexibilité. Si le produit ne peut pas s'adapter au besoin, et bien on facturera une fonctionnalité supplémentaire.

Sachant tout cela, autant faire un truc "vite fait, mal fait" et pas cher. Une fois qu'il est coincé avec votre architecture bancale, vous pouvez le saigner avec des correctifs et des mises à jour.

Le "vite fait, mal fait" fait vivre pas mal de monde :
- le consultant qui arrive tel le chevalier blanc en criant fièrement: "pour améliorer la qualité logiciel, on n'a qu'à faire plus des tests" (et par "on", il veut dire "VOUS"). Les tests, c'est bien, mais ça ne fait pas tout. De plus, cela implique de détecter les erreurs à l'exécution... c'est-à-dire un peu tard. Ne serait-il pas mieux de réfléchir à un moyen de détecter plus d'erreurs à la compilation ? Surtout pas ! Réfléchir, c'est perdre du temps sur l'implémentation, t'arriveras pas à atteindre les objectifs du sprint...

- le ScrumMaster, qui fixe les objectifs à atteindre pour la fin du sprint. Ce qui compte, c'est ce que ça marche (même mal) à la fin du sprint. Le reste on verra après. Pas le temps de réfléchir, code !

- le responsable Software Quality Assurance qui vous dit comment bien coder... avec de mauvais langages. Il explique aussi comment faire de la documentation, des procédures, des contrôles... On vous explique même "la programmation pour les nuls", c'est à dire comment coder pour que même un gros nul ait une chance de vous comprendre (au détriment de tout le reste bien sûr: qualité de code, performances, etc.). Parce que des nuls, il y en a beaucoup... et même des fois ce sont ceux qui vous expliquent comment gérer votre projet...


On dirait que toutes les méthodes liées à la gestion de projet convergent vers le même objectif : produire du code en masse, ainsi que toute la documentation, les tests et les procédures qui vont avec. C'est à croire que tout ce beau monde est payé au poids !

C'en est à un point où lors d'un entretien d'embauche, on entend parfois la question: "et quelle est le plus gros projet sur lequel vous ayez travaillé en terme de nombre de lignes de code ?". Autant dire que je n'ai pas donné suite.

Je suis désolé, mais le "nombre de lignes de code" n'a jamais été une unité pour mesurer ni la complexité d'un programme, ni l'état d'avancement d'un projet, et surtout pas la qualité logicielle ! Le "nombre de lignes de code" ne sert à mesurer qu'une chose : le facteur "ce programme est une vraie usine à gaz".

Cependant le "nombre de lignes de code" est une unité mesurable, alors que la "qualité logicielle" peut difficilement être mesurée. Or pour récompenser les gens, on a besoin de quantités mesurables, comme la production de code, de tests, de documentation, de procédures... L'ère du Stakhanovisme logiciel est en marche !


Maintenant, émettons une hypothèse : "et si le développement logiciel était exactement l'inverse de ce qui a été dit précédemment ?", c'est-à-dire :
- prendre le temps de réfléchir au problème plutôt que produire bêtement du code (produire mieux plutôt que produire plus)
- fournir le même nombre de fonctionnalités avec un code avec un code réduit (small is beautiful !)
- factoriser : rendre chaque fonction aussi générale que possible, plutôt que d'écrire des fonctions hyper-spécialisées
- détecter un maximum d'erreurs avant qu'elles ne puissent se produire (à la compilation plutôt que dans les tests)

Quand on voit sur quels critères se base toute l'industrie informatique, on réalise que ceci n'est qu'une douce utopie.

Dans ces conditions, un langage qui ne ressemble à aucun autre, qui oblige à s'arrêter pour réfléchir et qui freine l'obtention d'une promotion parce qu'on ne produit pas assez de code/documentation/procédure... n'a effectivement aucune chance de percer dans l'industrie.

[gorgonite]

J'ai pas bien saisi le rapprochement… ?

ben le dynamisme du typage dans une certaine mesure... contrairement à un code C++ non truffé de if (dynamic_cast<T>(o) != 0)



@pcaboche: tu rêves je crois... Le problème est encore plus profond que cela, tu n'as fait que décrire ses conséquences. Le monde de l'industrie n'est en fait géré que par des financiers/responsables marketing vaseux/commerciaux payés au % du CA et non au bénéfice dégagé au final sur un projet. A partir de là, la quantité de faible qualité prendra le pas sur la qualité, car elle génère beaucoup d'argent "après le projet initial". Il n'y a qu'à voir, dans tout ce qui est grand public, le nombre d'ingénieurs payés pour s'assurer de l'usure d'un produit après (2 x durée de garantie) pour comprendre que le prêt-à-jeter a de beaux jours devant lui... et d'autant plus dans l'informatique où un bogue aberrant n'est pas considéré comme un vice caché du produit

[el_slapper]

(.../...) On vous explique même "la programmation pour les nuls", c'est à dire comment coder pour que même un gros nul ait une chance de vous comprendre (au détriment de tout le reste bien sûr: qualité de code, performances, etc.). Parce que des nuls, il y en a beaucoup... (.../...)

Outre l'excellente réponse de gorgonite, j'aimerais revenir sur ce point : dans le monde du travail, on ne code pas pour soi. On code pour une organisation qui a besoin d'un code. Et il y a des gens qui passeront derrière. et parfois même des non-informaticiens assumés(même pas des gens qui croient savoir, non, j'ai eu des codes repris par des gens ouvertement non-programmeurs). Et ce, d'autant plus que les besoins en termes de développement sont trop importants pour être couverts par les doués seuls.

Et là, les critères de qualité changent. J'ai appris à faire un code plus simple, moins élégant, avec des finesses seulement sur les parties fondamentales, celles qui ne changent pas, mais qui sont appelées par des système basiques, compréhensibles par une huitre. J'ai appris à créer une couche initiale qui se lit exactement comme la spec, au cas ou la spec change et qu'il faille réagir brutalement(mon record, 9 versions de specs sur un seul samedi. Faut dire, ils avaient pas eu le temps de fignoler, et ils corrigeaient au fur et à mesure de mes executions). J'ai aussi appris à faire ceinture et bretelle, au cas ou un gnou appelle mes services de traviole, que le service reste stable, et réponde quand même au mieux.

Emmerdant? Certes. Moche? Souvent. Mais très utile, surtout quand on se retrouve avec le feu aux fesses dans la situation du gnou..... C'est pourquoi j'ai posé mes questions précédentes. Mon expérience, c'est qu'un langage reservé aux doués n'a pas d'avenir. La vraie vie, c'est la maintenance, les urgences et les modifications à chaud.

[Florian Goo]

@pcaboche (et gorgonite + el_slapper)
Excellent exposé…
En plus de répondre à la question « Pourquoi le Haskell ne peut pas percer ? », elle en fait de même pour « Pourquoi le Java et consort sont-ils si populaires en industrie ? »…

Heureusement qu'on compte quelques exceptions qui confirment la règle. Surtout hors de France, d'après ce que j'ai entendu dire…

[Alp]

Mon expérience, c'est qu'un langage reservé aux doués n'a pas d'avenir. La vraie vie, c'est la maintenance, les urgences et les modifications à chaud.

Dans la boîte d'info moyenne oui. Après, en te défonçant à fond, il y a de fortes chances pour que tu puisses accéder à un emploi bien plus sympa où on te demandera plus de qualité... Tout dépend de ce que les gens veulent, car je connais pas mal de gens qui se contentent d'un poste tel que décrit dans les messages précédents...

[zaventem]

Dans la boîte d'info moyenne oui.

Ce sont ces boites qui représentent la très grande majorité des besoins.

[pcaboche]

@pcaboche: tu rêves je crois... Le problème est encore plus profond que cela, tu n'as fait que décrire ses conséquences.

Oui je sais, je suis un doux rêveur... sinon j'aurais pas fait informaticien. J'aurais vendu des assurances, par exemple.

Et oui, je ne fais que décrire les conséquences, parce que les conséquences sont bien visibles et plus faciles à saisir. Mais même ainsi, le constat est déjà bien lourd...

On code pour une organisation qui a besoin d'un code. Et il y a des gens qui passeront derrière. et parfois même des non-informaticiens assumés(même pas des gens qui croient savoir, non, j'ai eu des codes repris par des gens ouvertement non-programmeurs). Et ce, d'autant plus que les besoins en termes de développement sont trop importants pour être couverts par les doués seuls.

J'ai bien conscience de tout cela. Je faisais juste une constatation.

Je n'ai pas la prétention de vouloir changer les choses (autant se battre contre des moulins à vent), mais je trouve qu'on tend vers de plus en plus de médiocrité.

Le plus gênant, c'est que si le client veut du code médiocre mais lisible, qu'il l'écrive noir sur blanc dans ses specs (quand il y en a ). Si au contraire il veut de la qualité, pareil -> dans les specs. S'il veut à la fois qualité, lisibilité et performance, rapidité de développement, ce n'est pas toujours conciliable -> qu'il fixe des priorités dans les specs ! (sachant que les specs font partie du contrat entre le donneur d'ordre et l'exécutant)

Dans la boîte d'info moyenne oui. Après, en te défonçant à fond, il y a de fortes chances pour que tu puisse accéder à un emploi bien plus sympa où on te demandera plus de qualité... Tout dépend de ce que les gens veulent, car je connais pas mal de gens qui se contentent d'un poste tel que décrit dans les messages précédents...

Et oui, parfois on se contente d'un poste médiocre pour payer le loyer. Mais généralement cette situation ne peut pas durer éternellement et on finit soit par craquer, soit par aller voir ailleurs... (et souvent l'un, puis l'autre...)

@pcaboche (et gorgonite + el_slapper)
Excellent exposé…
En plus de répondre à la question « Pourquoi le Haskell ne peut pas percer ? », elle en fait de même pour « Pourquoi le Java et consort sont-ils si populaires en industrie ? »…

Merci !

[el_slapper]

(.../...)
Le plus gênant, c'est que si le client veut du code médiocre mais lisible, qu'il l'écrive noir sur blanc dans ses specs (quand il y en a ). Si au contraire il veut de la qualité, pareil -> dans les specs. S'il veut à la fois qualité, lisibilité et performance, rapidité de développement, ce n'est pas toujours conciliable -> qu'il fixe des priorités dans les specs ! (sachant que les specs font partie du contrat entre le donneur d'ordre et l'exécutant)
(.../...)

Le plus gênant, c'est que le client ne sait pas ce qu'il veut. Il veut une solution magique et pas chère qui lui règle tous ses soucis d'un claquement de doigts, et nos exigences de techos(machines, délais, charges, tests, spécifications, questions précises) ne font rien qu'à l'embêter.

« Pourquoi le Java et consort sont-ils si populaires en industrie ? »…

...je fais essentiellement du COBOL... ou , au choix. En même temps, quand je vois les niveaux d'emmnuis auxquels font face les javaïstes et autres Businessobjectistes, je ne me plains pas .

[pcaboche]

Le plus gênant, c'est que le client ne sait pas ce qu'il veut. Il veut une solution magique et pas chère qui lui règle tous ses soucis d'un claquement de doigts, et nos exigences de techos(machines, délais, charges, tests, spécifications, questions précises) ne font rien qu'à l'embêter.

C'est pas faux...

La "solution magique pas chère" résume bien ce qui a été dit auparavant.

...je fais essentiellement du COBOL... ou , au choix.

Je compatis...

[el_slapper]

...je fais essentiellement du COBOL...

Je compatis...

en fait, c'est pas forcément pire que d'autres. Quand je vois les gens qui bossent sur les nouvelles technos, qui mettent 4 heures à ouvrir leur projet(authentique), ou qui sont obligés de se battre pendant deux heures pour monter leur évolution d'un environnement(la durée officielle est de 90 minutes, souvent dépassée), là ou moi il me faut respectivement 5 et 45 secondes, je deviens soudain plus indulgent vis-à-vis des faiblesses inhérentes à un aussi vieux langage(faiblesses bien réelles pourtant)..... Mais j'ai quand même du mal avec les codes spaghetti d'il y a trente ans.

[Oscar Hiboux]

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.

La plupart des informaticiens dignes de ce nom ayant étudié en informatique et l'informatique, notamment la programmation, étant une discipline impliquant largement les mathématiques on en est quand même assez proche... D'autant plus que Haskell, comme d'autres langages marginaux, fait encore pas mal figure de jouet de laboratoire.

Ensuite, les langages fonctionnels ne sont pas moins lisibles.

Pourtant la pratique le démontre souvent. Prends par exemple un script ECMA écrit par un programmeur moyen, transforme le avec ton esprit si brillant et mets-y quelques fonctions anonymes, fermetures & compagnie. Quand le reste de l'équipe jetteront un œil à ton travail ils seront très probablement atteint d'irritation oculaire aigüe... Eh ouais, leur cerveau n'est pas prêt à assimiler ton génie.

[...]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.

Rassure toi, on n'est pas tous allergiques à l'effort. Et si c'est comme ça que tu tentes de séduire la communauté tu risques d'y laisser quelques dents...

[...]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.

Tu m'as vraiment mis en haleine là !

Effectivement, les concepts manipulés dans les langages fonctionnels s'avèrent assez abstraits et difficiles à maîtriser, donc mettre en œuvre. La douce logique procédurale et l'OO sont bien plus accessibles au commun des mortels, n'en déplaise à l'élite, et par ce fait même sont choyés par l'industrie.

Bref, et passons sur la pureté...

[...]Il faut être motivé. C'est la curiosité intellectuelle, la passion pour les langages de programmation, qui doit te motiver.

Voilà, c'est là où le bât blesse. Ça le classe presque immédiatement, et sans doute malheureusement, dans une catégorie proche des loisirs.

Quant à la réalité, elle est plutôt bien décrite ensuite à partir de pcaboche. C'en est même comique !

[zul]

Effectivement, les concepts manipulés dans les langages fonctionnels s'avèrent assez abstraits et difficiles à maîtriser, donc mettre en œuvre. La douce logique procédurale et l'OO sont bien plus accessibles au commun des mortels, n'en déplaise à l'élite, et par ce fait même sont choyés par l'industrie.

Tu peux prouver ça (que l'OO est plus "accessible") ? Si l'OO était une approche si efficace, pourquoi 90% des projets informatiques continuent d'échouer ? L'OO n'est il pas intuitif parce que la seule façon de penser enseignée dans les écoles d'informatique ? Connais-tu et applique-tu le principe de Liskov ? (question piège)

Qu'est qui te parait si abstrait dans les concepts manipulés en fonctionnel ? Les fonctions ?

Si la curiosité intellectuelle te fait passer dans la section loisir, personnellement je n'aimerai pas travailler avec toi

[zaventem]

Si l'OO était une approche si efficace, pourquoi 90% des projets informatiques continuent d'échouer ?

Parce qu'en général, les raisons des échecs sont à des années lumières de la technique

[Alp]

Parce qu'en général, les raisons des échecs sont à des années lumières de la technique

Non, justement ils parlent de l'échec des logiciels, sur l'aspect technique, si je ne m'abuse. On trouve des logiciels bourrés de bugs partout... (j'parle pas d'un p'tit bug bien planqué qui était indétectable pendant les tests, mais bien de pleiiins de bugs à la con)

[Alp]

La plupart des informaticiens dignes de ce nom ayant étudié en informatique et l'informatique, notamment la programmation, étant une discipline impliquant largement les mathématiques on en est quand même assez proche... D'autant plus que Haskell, comme d'autres langages marginaux, fait encore pas mal figure de jouet de laboratoire.

Le problème c'est qu'aujourd'hui les gens de l'info, en majorité, veulent s'éloigner des maths, ne comprenant pas que l'info est très proche des maths. Donc c'est pas prêt d'arriver...

Pourtant la pratique le démontre souvent. Prends par exemple un script ECMA écrit par un programmeur moyen, transforme le avec ton esprit si brillant et mets-y quelques fonctions anonymes, fermetures & compagnie. Quand le reste de l'équipe jetteront un œil à ton travail ils seront très probablement atteint d'irritation oculaire aigüe... Eh ouais, leur cerveau n'est pas prêt à assimiler ton génie.

Oui mais comme je le disais je pense que c'est juste une question de conditionnement de l'esprit. Je connais pleins de gens qui ont commencé la programmation avec OCaml, Lisp, Haskell, Erlang et autres, et ils galèrent pour comprendre du code C++, Java, C#, tout ça tandis que du code dans un langage fonctionnel qu'ils ne connaissent pas hé bien ça va. Je pense que le conditionnement de l'esprit joue beaucoup.

Rassure toi, on n'est pas tous allergiques à l'effort. Et si c'est comme ça que tu tentes de séduire la communauté tu risques d'y laisser quelques dents...

Ce qui est bien avec la communauté Haskell, justement, c'est que les gens ne sont pas là à vouloir à tout prix séduire tout le monde. S'y intéresse qui veut et voilà. Je suis pas contre conscient que ça limite pas mal niveau marketing mais ce n'est pas plus mal finalement.

Effectivement, les concepts manipulés dans les langages fonctionnels s'avèrent assez abstraits et difficiles à maîtriser, donc mettre en œuvre. La douce logique procédurale et l'OO sont bien plus accessibles au commun des mortels, n'en déplaise à l'élite, et par ce fait même sont choyés par l'industrie.

Bof... Encore une fois je pense au conditionnement. Certains Design Patterns sont "chiants" à comprendre quand tu débutes en OO, parce qu'ils sont immergés dans ce monde OO auquel il faut s'habituer. Je pense qu'il y a juste des choses similaires mais dans le monde fonctionnel, qu'il faut prendre le temps de se familiariser avec, et voilà.

Voilà, c'est là où le bât blesse. Ça le classe presque immédiatement, et sans doute malheureusement, dans une catégorie proche des loisirs.

Quant à la réalité, elle est plutôt bien décrite ensuite à partir de pcaboche. C'en est même comique !

D'accord pour les posts à partir de celui de pcaboche.
Pas d'accord pour le reste. Personnellement, je préfère bosser avec un langage que j'aime. Et pour l'instant j'ai toujours réussi à m'en sortir à ce niveau là. Enfin, j'trouve ça naturel de s'intéresser à des choses dans l'info, et, si on accroche, à vouloir les utiliser dans notre boulot quotidien.