Monades...

[yloiseau]

Superbes illustrations 😄

Je trouve cependant que voir les monades comme un conteneur + map + join (ou flatMap/bind) est un peu bloquant pour la suite. En effet, l'analogie trouve vite ses limites quand on regarge Either, IO, Reader/Writer et donc State, et donc aussi les parseurs, les continuations, ou même plus simplement les fonctions (oui, une fonction est aussi une monade).

Un point de vue plus révélateur pour moi est de les voir comme une valeur dans un contexte, le bind appliquant un calcul à la valeur en tenant compte du contexte (d'où le nom, comme le late binding en objet, etc.). Par exemple, pour Either, on applique une fonction / effectue un calcul dans un contexte où l'échec est possible; State, ben... le contexte c'est l'état en question; pour les parseurs, on construit un automate à état/pile, et donc on doit traiter chaque élément dans le contexte de ce qui précède; les continuations capturent leur contexte d'exécution, etc.

Je trouve personnellement que cette manière de voir est plus révélatrice de la nature des monades, et aide mieux à les appréhender.

voilou

[k33g]

👋 @yloiseau je retiens les remarques 👍 cc @jponge
Cependant:

• la cible du document -> des personnes comme moi qui ont du mal avec le fonctionnel
• l'objectif du document -> désacraliser 2,3 concepts simplement quitte à prendre des raccourcis (puisque l'objectif est louable)

Quant au terme conteneur/contenant, il faut le prendre avec son sens "pratico/pratique" dans la vraie vie, c'est à dire, une boîte, un bocal, ... qui contient quelque chose (et le protège). Donc une valeur dans un contexte, une valeur dans un bocal, ... c'est tout pareil (dans le "contexte" de ce document)

Si j'attaque le sujet par le biais que tu proposes (qui est plus juste certes) je m'éloigne de mon objectif 1er: simplifier des concepts pour des néophytes (dont je fais partie) et retomber dans un document qui pourrait les perdre.

Tu essaieras dans quelques temps cet exercice 😉 : Il y a quelques années, j'ai du expliquer à ma fille de 5 ans, ce qu'étaient une variable et de valeur ... Finalement, la boîte (conteneur/contenant) avec des allumettes (valeur) ça a bien marché 😄.

... Mais je ferais un chapitre 2 quand j'aurais avancé

voilou ❤️

[yloiseau]

T'inquiètes, j'explique déjà aux étudiants de 1e année 😄
L'approche contexte est intéressante quand tu t'adresses à des gens qui connaissent les concepts objets: tu peux faire le parallèle avec l'encapsulation de l'état au sein de l'objet, et les méthodes qui s'y appliquent.

[k33g]

@yloiseau tu veux dire qu'ils ont le niveau d'un enfant de 5 ans 😉

[yloiseau]

Le niveau de gamins immatures qui ont jamais codé, savent à peine écrire correctement, et sans aucune curiosité? Ouai... C'est même peut être pire.

[k33g]

@yloiseau rooooh! Mais ils viennent pourquoi a la fac? (moi c'était la coinche, mais en deug Mass, l'info c'était léger)

[PhBastiani]

Cool :) Une présentation dans le même style...
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html
Comme le dit Yannick la notion de contexte est plus juste... mais, reste à expliquer ce qu'est un contexte... chose qui n'est pas si simple ! D'ailleurs la présentation de Léonard MEYER passe sans explication sur cette notion... Bon courage pour la suite

Après d'un autre côté si tu arrives à définir la notion de valeur... le contexte n'est qu'un pas supplémentaire ! non ?

[PhBastiani]

Et pourquoi pas parler de modalité au sens linguistique du terme ? L'idée ma été soufflée par PY Saumont l'auteur de functional programming un java....

[k33g]

@PBastiani merci, en fait j'ai commencé à faire une prez sur le sujet (dont est issu mon "article") où j'explique justement qu'avec mon petit cerveau, même cette explication en images apparaissait obscure ... d'où la prez, qui n'est ni plus ni moins un exercice de vulgarisation pour les allergiques au fonctionnel

👍 sur le contexte

"functional programming in java" est le bouquin qui m'a poussé à me creuser la tête, j'étais reviewer