Lumières sur les Monades en Haskell

Mais que diable sont les monades ?

a marqué ce sujet comme résolu.

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

Edit :

Bonjour,

Pour être honnête, je m'attendais à ce qu'on améliore ici ensemble la sémantique de cette traduction. Mais compte tenus des différentes remarques que j'ai reçu ici et sur irc, je renonce à vouloir faire passer en validation cet article.

Je proposerai prochainement une nouvelle traduction d'un tout autre article. À très bientôt.

+1 -0

La vraie question est : as-tu les droits pour faire cette traduction ? Une autorisation de l'auteur pour publier sur ZdS ?

KFC

Oui, j'ai demandé à l'auteur par mail sa permission (je le précise en introduction). En voici un extrait :

Given that you wrote this article and own the copyright, would you allow me to translate this article ?

Aloqsin

Hi. Of course - help yourself, and pass me a link to the translation when you publish.

cheers

[Noel Winstanley]

+0 -0

Je trouve que l'article explique mal le principe d'une monade, on voit trop de code d'un coup.

Grimur

C'est l'approche adopté par l'auteur, on aime ou on n'aime pas :

This introduction is presented by means of examples rather than theory […]

[Noel Winstanley]

La typeclass devrait être introduite plus tôt, tout de suite après les explications confuses sur Maybe.

Grimur

Cela supposerai de modifier le corps de l'article, ce que je ne peux me permettre sans ne plus aligner la traduction avec l'article d'origine.

+0 -0

Je reste très partagé sur cet article. Il est selon moi difficile à appréhender pour un débutant, notamment à cause des exemples de code trop bourrins et de l'introduction de la monade State trop rapidement, et pareil pour Maybe. Personnellement, je trouve que traduire des articles n'est pas une bonne idée puisque ça n'apporte rien par rapport à l'article initial à part la langue différente.

Je regrette également que tu préfères dire "je fais une traduction, si vous êtes pas contents c'est pareil". Je sais que c'est dur de pondre un bon article, mais un débutant en Haskell, il va voir ça et se dire "BEEEEERK mais qu'est-ce que c'est que ce truc" et avoir en tête "les monades c'est compliqué/pas beau, par extension Haskell beeeuaaark". Il y a beaucoup de bonnes ressources en français sur les monades, notamment dans LYAH. Quitte à pondre du contenu sur les monades, autant faire quelque chose d'original et qui se distingue de l'existant.

Il y a un tuto sur Haskell ici, pourquoi ne pas le reprendre ?

Histoire de résumer, ce qu'il faudrait c'est plutôt un article qui présente les monades de façon la plus claire possible pour des gens qui n'ont jamais rencontré le concept. Les "par l'exemple" marchent bien sur les personnes déjà un minimum familières avec le principe.

Ceci dit, ne va pas croire que je rabaisse ton boulot, c'est pas du tout facile de traduire un texte dans une langue étrangère et tout effort est le bienvenu.

+1 -0

En fait, l'article dit clairement au début qu'il faut déjà être familier avec Haskell donc ce n'est pas du contenu dédié au débutant. Le problème, c'est que pour quelqu'un d'un peu plus expérimenté, je trouve que c'est un peu léger en contenu.

D'ailleurs, ça serait peut être plus intéressant de faire une série de tutos/articles/whatever traitant de la théorie des catégories, en s'appuyant sur Haskell pour fournir des exemples. Bien entendu ça demande du boulot.

+1 -0

Mes compétences en Haskell sont proches du néant, mais dès l'intro, il y a quand même quelque chose qui cloche :

suppose un minimum de connaissance en Haskell

Un minimum ? T'as pas encore moins précis. :D

De plus, on ne sait pas à quoi servent les monades, dans quels cas ça s'utilise, ni pourquoi c'est une bonne idée de voir ça. Trois phrases de contexte (en claire, pourquoi lire ce tuto) serait pas mal.

De plus, et c'est inhérent aux traductions, certains passages sont très peu fluides, voir pas français. J'ai trouvé :

Il était une fois, des gens écrivaient leurs programmes Haskell en séquençant ensemble des opérations d'une manière un peu spéciale.

Il était une fois des gens qui écrivaient

Cette chose à noter est que la nouvelle base de donnée produite

La chose à noter

C'est très facile de se perdre dans les diverses bases de données intermédiaires et en passant la mauvaise valeur au prochain transformateur d'état, cela produirait des bogues difficilement-trouvables.

Heu… Faire deux phrases serait sûrement mieux.

ce style de programmation partage les avantages de l'exemple Maybe utilisant thenMB.

Mauvais verbe, je pense, ou alors partage avec autre chose.

à en presque oublier le style

À moins que ce ne soit un régionalisme, j'aurai mis à en oublier presque le style.

Parenthèse typographique :

Évidemment le style de programmation montré au-dessus - en utilisant des combinateurs pour gérer le passage de paramètre ou flot d'instructions -

Il faut mettre des tirets quadratins, ce qui se fait en markdown avec deux tirets --.

pour chacun de ces idiomes - en plus d'une notation uniforme,

Idem.

est uniquement utilisé une seule fois - en effet

Idem.

uniquement utilisé une fois - unicité des type

Idem.

+0 -0

Cela supposerai de modifier le corps de l'article, ce que je ne peux me permettre sans ne plus aligner la traduction avec l'article d'origine.

Aloqsin

Es-tu contraint de te contenter de traduire l'article ? Ne pourrais-tu pas reformuler ou compléter certains passages ?

+0 -0

J'ai tenu compte de tes remarques dans la mise-à-jour Gabbro, merci.

Es-tu contraint de te contenter de traduire l'article ? Ne pourrais-tu pas reformuler ou compléter certains passages ?

Vayel

C'est une auto-contrainte, même si je me permets quand même de reformuler certains passages. En compléter certains pourquoi pas à condition que cela soit justifié et que je précise NdT.

+0 -0

@Grimur: oui, par exemple ça. On pourrait aussi imaginer un truc plus théorique, un peu plus éloigné de la programmation. Mais après y'a le risque de se retrouver avec une liste de définitions/théorèmes/lemmes et ça peut rebuter. D'où l'intérêt d'avoir des exemples d'applications.

+0 -0

Concernant la forme, je me dois de dire qu'en l'état, cette traduction est mauvaise : il reste de nombreuses tournures anglaises, le texte est parsemé de ruptures de syntaxe et il est truffé de fautes. Pour être tout à fait honnête, j'aurais moins de mal à le lire directement en anglais.

Concernant le fond, je sais bien que l'exercice de traduction impose de respecter la manière de faire de l'auteur original, mais je rejoins Grimur quand il dit que cette approche est à peu près incompréhensible, même en ayant des bases en Haskell.

Je connais deux méthodes qui marchent pour expliquer simplement les monades.

  • La méthode longue, qui « construit » les monades à partir des foncteurs et des foncteurs applicatifs. C'est la méthode utilisée par LYAH, et il n'y aurait pas grand intérêt à la réécrire.
  • La méthode courte, qui pose directement la définition d'une monade avec la métaphore de la boite, et qui ensuite montre des exemples de mise en œuvre, et en quoi cela aide à résoudre tel ou tel problème.

Partir de l'idée que les monades ont été inventées pour gérer les effets de bord en prog fonctionnelle pure (déjà, bon… c'est la méthode du Haskell, mais le Clean ou le Elm font autrement, par exemple), pour embrayer directement sur la monade Maybe et la monade State, et seulement après se poser la question de ce qu'est une monade, c'est mauvais.

+0 -1

J'ajouterais que les concepts comme les foncteurs, monades etc sont assez abstraits et avant de pouvoir les utiliser il faut un temps pour intégrer l'idée. Intuitivement je comprenais ce qu'était un foncteur mais il a fallu un article sur la théorie des catégories en programmation fonctionnelle pour que je comprenne qu'un foncteur était simplement un morphisme dans la catégorie des catégories (je suis pas certain de la rigueur de cette affirmation, j'ai jamais fait ça en cours par contre). Du coup, ça donne une vision des choses plus mathématique et personnellement ça m' aide beaucoup de voir "l'image globale". Quand j'ai vu mon premier exemple de monade dans LYAH autant dire que j'ai rien bité à part la monade Maybe, et j'ai dû relire pas mal de fois pour me construire ma représentation interne.

Les approches "par l'exemple" sont à mon sens bonnes pour confirmer l'intuition qu'on a d'un objet. En maths, quand on a introduit la réduction des endomorphismes, je ne comprenais pas bien avant d'avoir une vision plus géométrique de ce que ça signifiait, alors que mon prof avait tenu à faire du "par l'exemple" presque tout de suite. Par contre une fois l'intuition acquise, les exemples la renforcent et on assimile mieux.

Je rejoins olzd: cet article a clairement le cul entre deux chaises. Il n'est pas fait pour le débutant et quelqu'un de confirmé n'apprendra rien de nouveau.

+0 -0
Ce sujet est verrouillé.