Pourquoi apprendre Haskell

… aperçu d'un langage intriguant

a marqué ce sujet comme résolu.

Malheureusement, cet article qui était en bêta a été supprimé par son auteur.

Tout le monde se secoue ! :D

J’ai commencé (il y a 5 heures) la rédaction d’un article au doux nom de « Pourquoi apprendre Haskell » et j’ai dans l’objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l’adresse suivante :

Merci !

Je précise que cet article n’est en aucun cas un tutoriel, mais plus une incitation à l’apprentissage de ce langage que je trouve génial. J’ajoute aussi que je n’ai pas la prétention de présenter Haskell comme le meilleur langage objectivement, j’expose juste mon avis pour essayer de répandre un langage qui est à mon goût pas assez représenté.

J’ai écrit cet article à l’origine pour expliquer une bonne fois pour toute pourquoi j’aime Haskell, pour ne pas avoir à trop me répéter quand un nouveau membre apparaît sur un salon de discussion :)

Enfin, je veux juste dire que c’est la première fois que j’écris quelque chose sur Zeste de Savoir (et de manière générale, première fois que j’écris un article tout court), donc je savais pas trop comment m’y prendre.

Je prend toute critique constructive et corrections,

Merci d’avance,

felko

+5 -0

Oui parce que sinon je vendais pas assez mon langage :diable:

Mais finalement je gagne plus en crédibilité si je parle aussi des désavantages.

J'attendais surtout des critiques pour savoir où améliorer, mais un commentaire positif fait toujours plaisir :)

+0 -0

Chacun son avis, mais moi je trouve qu'au contraire ça n'est pas assez étouffé, ou qu'en tout cas, ça n'ouvre pas énormément sur d'autres sujets ( même si tu parle de la Théorie des catégories ou autres petites choses ) — ( bon, j'avoue, c'est pas très clair ce que je viens de dire… :s )

Sinon ta phrase « Il faut apprécier les mathématiques abstraites pour apprécier Haskell, même si cela ne requiert pas de connaissances avancées. » est un peu décourageante, surtout quand tu nous dis que tu as commencer à apprécier les mathématiques grâce à ce langage :p

Voili voilou, vraiment cool ton p'tit article :)

+0 -0

Chacun son avis, mais moi je trouve qu'au contraire ça n'est pas assez étouffé, ou qu'en tout cas, ça n'ouvre pas énormément sur d'autres sujets ( même si tu parle de la Théorie des catégories ou autres petites choses ) — ( bon, j'avoue, c'est pas très clair ce que je viens de dire… :s )

Tu voudrais que j'ouvre sur quoi ? J'ai pas trop voulu comparer à d'autres langages parce que sinon ça allait être le bordel dans les commentaires.

Sinon ta phrase « Il faut apprécier les mathématiques abstraites pour apprécier Haskell, même si cela ne requiert pas de connaissances avancées. » est un peu décourageante, surtout quand tu nous dis que tu as commencer à apprécier les mathématiques grâce à ce langage :p

Tu peux apprécier un truc sans le savoir, tout ce que je dis c'est que si tu détestes les mathématiques, c'est peu probable que tu accroches à Haskell. C'est possible mais quand on voit la communauté Haskell, on peut voir qu'il y a pas mal de matheux. En tout cas la plupart des haskellers que j'ai pu rencontrer un peu partout, y'en avait pas mal.

Mais en aucun cas Haskell n'est réservé aux matheux, je me suis mal exprimé je vais éditer tout de suite, merci :)

+0 -0

Il faudrait aussi peut être chercher à simplifier la partie « caractéristiques ». Je m'attarderais moins sur les caractéristiques du langage et je décrirais plutôt les différences entre l'impératif et le fonctionnel.

D'autre part, terminer par les inconvénients rend le truc un peu moins vendeur du coup. Pour remédier à cela, peut-être conclure brièvement par pourquoi tu aimes ce langage ?

+1 -0

Quand je parlais « d'ouvrir », c'était dans le sens ou justement étoffer la partie « caractéristiques » ( Oups, le contraire de Thulemalta ? :'( ) en parlant par exemple un petit peu plus des monades, même si il y a déjà un article , Par ici :3 ( pour la comparaison avec d'autres langages, c'est vrai que ça aurait été cool, mais laisse ça pour les tuto's sur Haskell :D )

T'es pas obligé de m'écouter, j'dis souvent des conneries :D

En plus, t'avais déjà mis le lien à la fin, je suis bête, pardi !

+0 -0

Oui mais qu'il en parle, ça pousse à être curieux et à aller voir un petit peu sur notre ami moteur de recherche ;)

Et puis personnellement, je l'ai lu d'une traite :p

Mais c'est vrai que ce n'est pas forcément le but de l'article :-°

Ce que je reproche le plus à cet article c'est les quelques petits défauts / maladresses, tout riquiqui ^^ par exemple : « C'est pourquoi je vais vous expliquer dans cet article les avantages de Haskell et pourquoi vous devriez l'apprendre. »

Avantages ? Mais tu nous parle aussi des défauts ? :D ( bon, ok, je chipote :3 ) Vous devriez ? Oh, non, pourquoi ? Je vais devoir annulé mon anniversaire… Je suis obligé d'apprendre Haskell, c'est obligatoire, le monsieur l'a dit !

+0 -0

Il faudrait aussi peut être chercher à simplifier la partie « caractéristiques ». Je m'attarderais moins sur les caractéristiques du langage et je décrirais plutôt les différences entre l'impératif et le fonctionnel.

La partie « Caractéristiques » est peut-être un peu déséquilibrée par rapport aux autres.

Par contre à mon sens cette partie décrit plutôt bien les différences avec l'impératif. Après c'est vrai que ça serait mieux d'orienter plus comparaison que simple description.

Je vais voir comment je vais faire sans trop alourdir :)

D'autre part, terminer par les inconvénients rend le truc un peu moins vendeur du coup. Pour remédier à cela, peut-être conclure brièvement par pourquoi tu aimes ce langage ?

Je vais peut-être pas répéter le fait que j'aime Haskell, mais en tout cas nuancer mes propos dans la conclusion au lieu de rester sur un point négatif. Merci de ton conseil :)

Bah je trouve qu'il développe un peu trop la pureté du langage, l'évaluation paresseuse et le typage par exemple. C'est intéressant, mais ce n'est pas fondamental pour l'article qui, du coup, est plus lourd à lire.

C'est vrai que c'est pas le but initial de l'article, mais je pense que c'est important de parler un peu de l'aspect technique pour donner un aperçu (pour le coup dans la partie sur le typage je fais un parallèle entre Haskell et les langages orientés objet, toi qui voulais plus de comparaisons)

Avantages ? Mais tu nous parle aussi des défauts ? :D ( bon, ok, je chipote :3 )

J'oriente tout de même plus mon article vers les avantages que les défauts, je suis pas convaincu.

Vous devriez ? Oh, non, pourquoi ? Je vais devoir annulé mon anniversaire… Je suis obligé d'apprendre Haskell, c'est obligatoire, le monsieur l'a dit !

J'y ai pensé en l'écrivant, mais c'est au conditionnel, donc c'est plutôt un conseil qu'un ordre. Mais tu as raison c'est maladroit, j'édite :)

+0 -0

L'idée est sympa mais je trouve cet article pas assez fouillé. Tu aurais pu expliquer tous les exemples de code, ainsi que le rôle de map. Pour ce qui est de IO, tu pourrais montrer un exemple tout simple pour montrer comment ça "contamine" tout ce qui a des effets de bords. Tu aurais pu parler aussi de types algébriques et du fait que le typage d'Haskell et ses signatures de fonction permettent de vraiment réfléchir à ce qu'on fait avant même d'écrire du code.

+1 -0

J'ai vraiment lu en diagonal mais j'ai l'impression qu'il y a une forte dose d'avis personnel. Même si tu essai de mitigé le propos dans une section à parler des défauts, ça ne semble pas être un article objectif sur une technologie mais une explication de pourquoi toi tu l'aime bien (d'ailleurs tu l'assume dans le premier message de ce sujet).

Du coup je me demande si ça n'aurai pas plus sa place dans une tribune libre (qui ne devraient plus tarder maintenant)

+3 -0

Mon avis général sur l’article : en l’état, il va faire un bide. Maintenant, si on regarde un peu plus en détail, il souffre de plusieurs défauts.

Le premier, c’est que tu ne sembles pas t’être posé la question de ton public. À qui t’adresses-tu, et qui cherches-tu à convaincre ? Nécessairement, les arguments et les points plus ou moins détaillés ne seront pas les mêmes.

On voit d’emblée à la lecture que tu ne t’adresses absolument pas à des débutants en programmation : tu utilises bien trop de concepts avancés pour qu’un débutant qui chercherait un premier ou deuxième langage comprenne quoi que ce soit à ton argumentaire. Est-ce vraiment ce que tu veux ? Si oui, pourquoi utiliser un titre aussi généraliste ?

Mais même parmi les développeurs relativement chevronnés, on ne voit pas bien qui tu cibles. Tu as des passages comme ça :

De plus Haskell commence peu à peu à être utilisé en industrie pour sa sûreté sans pareille. Haskell va connaître un succès d'ici les 10 années futures selon moi. Étant donné la difficulté de Haskell, il faut commencer tôt pour d'ici-là maîtriser Haskell au mieux.

Et puis connaître un langage d'un paradigme différent est un vrai plus dans un CV.

… où tu sembles clairement t’adresser à des devs professionnels. Je veux dire, je bosse dans le domaine général de l’administration, avoir tel ou tel langage plutôt qu’un autre sur mon CV ne me sert strictement à rien. Et je me fous de savoir ce qu’utilise l’industrie pour faire mes joujoux dans mon coin.

Et pourtant, une bonne partie de ton argumentaire semblerait vouloir toucher un public plus large. De même, tu sembles globalement t’adresser à un public de gens qui viennent de la programmation impérative, mais tu considères par ailleurs comme acquises des choses qui… justement viennent de la programmation fonctionnelle.

Par exemple, quand tu parles du fait que Haskell permet de faire des fonctions d’ordre supérieur, un programmeur impératif qui n’a jamais eu besoin d’utiliser des fonctions d’ordre supérieur (je dirais, à peu près tous) ne comprendra pas en quoi cela a le moindre intérêt.

De même, tes exemples de code sont difficilement compréhensibles pour quelqu’un qui n’a jamais fait de programmation fonctionnelle, et surtout, manquent cruellement d’intérêt. Sérieusement, qui s’emmerde à écrire une factorielle ?

On en arrive au deuxième défaut : tu présentes tout un tas de fonctionnalités de Haskell, mais tu n’expliques jamais à quoi elles servent. La question majeure, c’est : pourquoi j’irais me faire chier à apprendre un nouveau paradigme, pour utiliser des outils, alors que j’arrive très bien à faire la même chose avec les outils de mon propre paradigme ?

En fait, tel quel tu présentes et expliques les choses, il faut avoir déjà fait de la programmation fonctionnelle pour comprendre à quoi cela sert d’apprendre la programmation fonctionnelle !

Dans un même ordre d’idée, ta section sur les domaines de prédilection ne fait vraiment, vraiment pas envie. Écrire un nouveau langage, écrire un compilateur pour un langage existant et faire de la programmation concurrente. Youhou ! ça envoie du rêve, vraiment… Ah si, quand même, tu mentionnes vaguement à la fin les frameworks Web et le fait que le langage soit généraliste…

Je vais parler un peu d’expérience personnelle, ici. J’ai mis très longtemps à faire comprendre à mon paternel pourquoi j’appréciais coder en Haskell. Pour lui qui n’est pas dev professionnel, mais qui utilise simplement la programmation comme outil pour son boulot, l’élégance des types algébriques, ça lui passe complètement au-dessus.

Le jour où j’ai fini par réussir à lui faire piger, c’est quand je lui ai parlé non des grands principes (Évaluation Paresseuse, Fonctions Comme Données De Premier Ordre, Monades™…), mais des outils du quotidien. Comment j’utilisais map plutôt que des boucles. La puissance des listes en compréhension. Des trucs comme ça.

Parce que là, il s’est rendu compte que c’était des outils qu’il utilisait lui-même au quotidien, mais sous un autre nom. Et sans savoir qu’ils venaient de la programmation fonctionnelle. Et qu’il les aimait beaucoup.

Troisième défaut majeur à mon sens, ceci :

Haskell est très abstrait, et requiert une grande capacité d'abstraction pour comprendre certains concepts comme les foncteurs, les monades, les arrows, la programmation fonctionnelle réactive et bien d'autres encore.

Dans tous les cas, Haskell a une courbe d'apprentissage très rude. Au départ, il sera normal de se dire toutes les dix secondes "Oh là là, c'est quoi ce langage bizarre" si vous n'avez jamais fait de programmation fonctionnelle avant. Mais d'après mon expérience personnelle, cela vaut vraiment le coup.

Bien que j'adore ce langage, je le déconseille si vous n'aimez pas les mathématiques, et si vous ne cherchez pas à vous casser la tête.

Tout ça, c’est de l’ordre de la prophétie auto-réalisatrice. À force de répéter inlassablement que Haskell est dur à apprendre, que c’est vache d’abstrait1, que c’est super chelou comme langage2, on finit par générer chez les gens cette impression de difficulté3.

Si tu veux parler des défauts de Haskell, parle plutôt du fait que c’est super chiant de faire de l’IO. Ou encore que l’évaluation paresseuse peut te jouer des tours de cochon : même un exemple simple comme le foldl non strict est suffisant pour bien se rendre compte de l’ampleur du problème.

Quatrième défaut, et je m’arrête là : à quelques détails près, ton article n’explique pas pourquoi les gens devraient apprendre Haskell, il explique pourquoi ils devraient apprendre la programmation fonctionnelle.

Il manque une comparaison avec d’autres langages fonctionnels, et un argumentaire sur pourquoi Haskell plutôt que ceux-là. Par exemple, quand tu écris ceci :

Mais Haskell reste imbattable en ce qui est de la sûreté (il existe quelques langages plus sûrs que Haskell mais encore moins connus).

Clairement, le fait qu’ils soient peu connus n’est pas un argument en soi pour préférer Haskell à ces langages dont tu ne donnes même pas le nom. Alors si la sécurité est si importante4, pourquoi se contenter de Haskell plutôt que d’aller directement voir ces langages-là ?

Ou encore, tu parles de la capacité d’Haskell à faire de la programmation concurrente, mais il peut aller se rhabiller à côté d’Erlang sur ces questions-là, alors pourquoi Haskell ?

Voilà, j’espère ne pas t’avoir découragé, mais l’argumentation est un art moins évident qu’il n’y paraît, et il faut bien que je mette le doigt sur les failles de la tienne. ^^

  1. Sérieusement, tant qu’on ne monte pas dans les concepts avancés, Haskell n’est pas plus abstrait que n’importe quel langage de programmation. Y’a même eu des expériences sur le sujet : le simple fait d’être capable d’apprendre un langage de programmation, quel qu’il soit, nécessite une capacité d’abstraction supérieure à la moyenne. Et même là… Un truc comme les objets est un concept tellement abstrait que tous les cours sur un langage objet se cassent la tête à savoir comment expliquer ce que c’est sans causer de rupture d’anévrisme à leur lecteur. ↩

  2. Là, je connais pas d’expérience scientifique sur la question, mais empiriquement, un langage fonctionnel est « super chelou » si tu as déjà formaté ton cerveau pour la programmation impérative. Si tu découvres la programmation avec ce paradigme, ce n’est pas plus chelou que n’importe quel autre langage. ↩

  3. Là encore, je n’invente rien. Des expériences ont montré que si tu fais résoudre à des gens un problème de géométrie basique, en le formulant de manière à masquer que ce sont des maths, le taux de réussite est de plus de 90 %. Si tu leur fais résoudre strictement le même problème, en le présentant explicitement comme un problème de maths, le taux de réussite s’effondre autour de 35 %. Dire par avance que quelque chose va être dur, c’est mal. ↩

  4. Petit détail, avant qu’Eusèbe ne te fasse la remarque : c’est pas bien de parler de « sécurité » sans dire exactement ce que cela recouvre. Tu es certainement protégé contre les erreurs de segmentation et les comportements imprévisibles dus au changement d’une variable loin ailleurs dans le code, mais tu n’as aucune garantie que les résultats parfaitement sûrs que produit ton programme soient justes. Honnêtement, je passe autant de temps à déboguer un programme Haskell que dans n’importe quel autre langage. ↩

+4 -0

Du coup je me demande si ça n'aurai pas plus sa place dans une tribune libre (qui ne devraient plus tarder maintenant)

Sur ZdS ? C'est vrai que ça serait plus adapté :)

Pourquoi apprendre Haskell et pas un autre langage fonctionnelle ? Pourquoi apprendre Haskell et pas un langage imperatif/objet qui supporte aussi le fonctionnel ?

Là ça va partir en couille si Eusèbe voit ça :D

Mais en effet ce sont des questions intéressantes, merci.

Pour le coup j'aurai besoin d'un dev OCaml/Caml/Lisp parce qu je n'ai pas assez d'expérience dans ces langages pour dire que Haskell est meilleur.

Bon maintenant réponse à Carnufex:

Le premier, c’est que tu ne sembles pas t’être posé la question de ton public. À qui t’adresses-tu, et qui cherches-tu à convaincre ? Nécessairement, les arguments et les points plus ou moins détaillés ne seront pas les mêmes.

Non clairement pas, c'est pour ça que j'essaye de couvrir l'aspect professionnel autant qu'amateur.

On voit d’emblée à la lecture que tu ne t’adresses absolument pas à des débutants en programmation : tu utilises bien trop de concepts avancés pour qu’un débutant qui chercherait un premier ou deuxième langage comprenne quoi que ce soit à ton argumentaire. Est-ce vraiment ce que tu veux ? Si oui, pourquoi utiliser un titre aussi généraliste ?

C'est pas ce que je veux, mais je pense qu'apprendre Haskell en premier/deuxième langage est pas super utile. C'est déjà assez difficile d'expliquer Haskell à des programmeurs confirmés en impératif, je ne sais pas si c'est pertinent de tout expliquer de zéro pour couvrir aussi les débutants (au risque de perde une bonne partie du public), et c'est encore moins pertinent d'épargner les détails techniques je pense.

EDIT: cf message à la fin

… où tu sembles clairement t’adresser à des devs professionnels. Je veux dire, je bosse dans le domaine général de l’administration, avoir tel ou tel langage plutôt qu’un autre sur mon CV ne me sert strictement à rien. Et je me fous de savoir ce qu’utilise l’industrie pour faire mes joujoux dans mon coin.

Oui comme je l'ai dit plus haut je trouve des arguments pour tout le monde. Si celui ci ne te touche pas, prends juste compte des autres.

Enfin encore une fois je sais pas, je te fais confiance étant donné que c'est la première fois que j'écris un article.

mais tu considères par ailleurs comme acquises des choses qui… justement viennent de la programmation fonctionnelle.

Ouep ça j'ai du mal, je vais voir ce que je peux faire, merci :)

De même, tes exemples de code sont difficilement compréhensibles pour quelqu’un qui n’a jamais fait de programmation fonctionnelle, et surtout, manquent cruellement d’intérêt. Sérieusement, qui s’emmerde à écrire une factorielle ?

Oui j'avoue j'ai été rapide sur les codes :D

L'intérêt est pas forcément le but du code en lui-même, mais plus de montrer l'expressivité du langage.

Je vois pas trop quel code utile on pourrait faire en si peu de lignes en fait (je prends les idées).

On en arrive au deuxième défaut : tu présentes tout un tas de fonctionnalités de Haskell, mais tu n’expliques jamais à quoi elles servent. La question majeure, c’est : pourquoi j’irais me faire chier à apprendre un nouveau paradigme, pour utiliser des outils, alors que j’arrive très bien à faire la même chose avec les outils de mon propre paradigme ?

Parce qu'on gagne en productivité étant donné qu'on écrit souvent moins. Et aussi parce que ça te force à voir les problèmes d'une perspective différente potentiellement plus adaptée que la solution impérative (ça je l'ai dit dans l'article).

(je réponds là mais je sais bien que tu connais probablement les réponses, je vais évidemment compléter mon article)

Dans un même ordre d’idée, ta section sur les domaines de prédilection ne fait vraiment, vraiment pas envie. Écrire un nouveau langage, écrire un compilateur pour un langage existant et faire de la programmation concurrente. Youhou ! ça envoie du rêve, vraiment… Ah si, quand même, tu mentionnes vaguement à la fin les frameworks Web et le fait que le langage soit généraliste…

Tu voudrais que j'aborde quoi de plus ? Là pour le coup je sais pas trop :/

Il manque une comparaison avec d’autres langages fonctionnels, et un argumentaire sur pourquoi Haskell plutôt que ceux-là

Cf. message de gbdivers

Clairement, le fait qu’ils soient peu connus n’est pas un argument en soi pour préférer Haskell à ces langages dont tu ne donnes même pas le nom. Alors si la sécurité est si importante, pourquoi se contenter de Haskell plutôt que d’aller directement voir ces langages-là ?

Parce que:

  1. je les connais pas (bof comme argument je sais)
  2. la communauté et les librairies de Agda ou Idris sont pas incroyable à ce que j'ai cru comprendre
  3. pour le coup je doute que cela soit un jour utilisé dans l'industrie (mais bon ça peut toujours toucher les devs amateurs, c'est vrai)

Ou encore, tu parles de la capacité d’Haskell à faire de la programmation concurrente, mais il peut aller se rhabiller à côté d’Erlang sur ces questions-là, alors pourquoi Haskell ?

Parce que niveau programmation concurrente, même si Erlang est plus adapté à ce que j'ai cru comprendre, ce qui compte c'est l'ensemble des capacités non ? En plus Haskell se défend pas si mal de ce côté (en tout cas par rapport à la plupart langages impératifs). Je n'ai pas dit que c'était le meilleur, mais qu'il était bon dans ce domaine.

Là, je connais pas d’expérience scientifique sur la question, mais empiriquement, un langage fonctionnel est « super chelou » si tu as déjà formaté ton cerveau pour la programmation impérative. Si tu découvres la programmation avec ce paradigme, ce n’est pas plus chelou que n’importe quel autre langage.

Non effet, mais cf ce que je disais au début: je m'adresse d'avantage à des programmeurs au moins intermédiaires en impératif. Tu penses vraiment que je devrai orienter ça plus pour les débutant ?

Honnêtement, je passe autant de temps à déboguer un programme Haskell que dans n’importe quel autre langage

Le temps de debug est le même mais, de mon expérience personnelle, est beaucoup reporté à la compilation. Déjà on a pas toutes ces histoires de null/None/nil/nullptr/etc… qui représentent environ 70% des erreurs dans pas mal de langages impératifs. . D'ailleurs en parlant de debug, c'est hyper chiant de debugger en Haskell je trouve.

Voilà, j’espère ne pas t’avoir découragé, mais l’argumentation est un art moins évident qu’il n’y paraît, et il faut bien que je mette le doigt sur les failles de la tienne. ^^

Non pas du tout, merci beaucoup de tes conseils, si je veux pas publier de la merde, faut bien passer par là ^^

EDIT: En fait je retire ce que j'ai dit sur le fait que Haskell est difficile à expliquer aux débutants. En fait ce qui est difficile comme tu l'as dit c'est de faire désapprendre aux devs impératifs. Enfin ça c'est si on parle pas des monades. Dans du tutoriel sur les monades, tu dis que ce n'est pas une notion nécessaire en Haskell, mais je suis pas tout à fait d'accord dans le sens où elles sont omniprésentes dans la librairie standard. Et ce sera infiniment plus agréable de coder avec les monades que de faire du pattern matching à tout bout de champ :euh:

EDIT 2: Je pense beaucoup plus restreindre mon article aux notions de bases facilement explicables, donc plus susceptible de toucher le public, suite aux critiques de Carnufex. Je sais pas du tout comment ouvrir l'article aux débutants complets en programmation par contre :/

+0 -0

Je vais pas répondre à tout précisément, parce que certaines réponses se recoupent.

Globalement, je n’ai pas d’avis sur le fait de t’adresser à un public ou à un autre. Je suis intimement persuadé que la prog fonctionnelle, et Haskell en particulier, mériteraient des cours qui s’adressent à de vrais débutants, plutôt qu’à des programmeurs impératifs, mais c’est un peu hors sujet ici.

Le seul point certain, à mon avis, c’est que tu ne peux pas balayer trop large : si tu fais un contenu qui « parle » aux débutants, les programmeurs chevronnés vont se faire chier, et si tu fais un contenu qui « parle » aux programmeurs chevronnés, les débutants vont partir en courant.

De même, je ne pense pas que ce soit une bonne idée de mélanger allégrement arguments qui s’adressent à des pros et le contenu plus général qui s’adresse aux amateurs. Je pense que tu devrais faire une section spécifique « et si vous êtes un dev professionnel, y’a ça aussi pour vous ».

En bref, adresse-toi au public que tu veux, mais tiens-toi-s-y. Et d’après ce que je lis entre les lignes, ce que tu sembles vraiment vouloir faire, c’est un contenu qui explique aux programmeurs impératifs un minimum chevronnés pourquoi ils devraient s’intéresser aux outils de la programmation fonctionnelle pour améliorer leur capacité à coder, avec des exemples en Haskell.

Ça implique de complètement renommer l’article, mais au moins, ça te donnerait un fil directeur bien identifié.

Et quant à la manière d’expliquer les choses, je pense sincèrement qu’une approche plus pratique et spécifique s’avérera beaucoup plus efficace étant donné ton objectif. Plutôt que de parler de la Sainte Évaluation Paresseuse, choisis un problème concret et « réaliste » (sincèrement, tout le monde s’en branle de Fibonacci), montre comment l’évaluation paresseuse permet de le résoudre de manière plus efficace / simple / élégante / ce que tu veux que l’approche impérative, puis montre les limites de l’outil (foldl…).

Tu fais ça pour 3-4 outils phares de la programmation fonctionnelle, et si tu arrives à ajouter des exemples de comment ces outils ont pu être intégrés dans des langages impératifs, tu obtiendras, à mon avis, un contenu réellement instructif et pertinent pour ta cible, et qui permette vraiment à un programmeur impératif de comprendre ce qu’il peut retirer de la prog fonctionnelle.

Oui mais tu debug les erreurs à la compilation non ?

Non, la compilation se passe à merveille, mais les résultats du programme n’ont pas de sens. Par exemple, mon condensat SHA-3 est mauvais.

+1 -0

Ouais mais du coup ça part dans un truc totalement différent de mon idée de départ. Moi je veux pas que les gens fassent du fonctionnel dans un langage impératif multi-paradigme, mais je veux que les gens apprennent Haskell. Faire du fonctionnel dans un langage non fonctionnel est une perte de temps. Bien que ça puisse te faire gagner quelques lignes dans ton code, le réel avantage de Haskell est la sûreté qu'il apporte. Or la sûreté est bien plus difficile à implémenter dans un langage fondamentalement unsafe

Plutôt que de parler de la Sainte Évaluation Paresseuse, choisis un problème concret et « réaliste » (sincèrement, tout le monde s’en branle de Fibonacci), montre comment l’évaluation paresseuse permet de le résoudre de manière plus efficace / simple / élégante / ce que tu veux que l’approche impérative, puis montre les limites de l’outil (foldl…).

OK merci je vais y réfléchir :)

+0 -0

Rust est censé être sûr. Pourtant il y a seulement des éléments piqués au fonctionnel, c'est pas un langage fonctionnel.

Arrête de croire que pour faire du fonctionnel il faut faire du Haskell. Les outils fonctionnels dans des langages multiparadigmes sont super utiles, par exemple mon TIPE en Python est truffé d'emprunts au fonctionnel (et avant que quelqu'un le fasse remarquer, si j'avais pu le faire en Haskell je l'aurais fait). Déjà, si tu montres à quel point certains éléments du fonctionnel sont puissants les gens auront peut-être envie d'en savoir plus, ce qui sera moins le cas si tu leur dis juste "mais nonnn faut faire du haskell si tu veux utiliser map".

+2 -0
Ce sujet est verrouillé.