Dans ton exemple pratique, tu penses uniquement à la monade IO qui est un gros hack pour les effets de bord. La pureté en question, c'est pour se donner bonne conscience; en pratique, c'est aussi sale qu'un effet de bord dans un autre langage. C'est un artifice, oui, et comme argument, ça vaut zéro. C'est pas la monade qui permet ça, c'est le style de programmation : « environment passing style. »
Des gens font ça tous les jours dans d'autres langages, y compris C (quand tu passes un pointeur vers une donnée à toute tes fonctions, genre ta surface en SDL, ta socket en réseau).
S'ils mettaient une macro pour ne plus avoir à taper à chaque fois le code redondant, ils utiliseraient la monade IO (ou la monade State) sans le savoir !
En revanche, l'idée d'encapsulation, elle, est meilleure.
Quand tu écris
do
x <- extraction
return (foo x)
c'est comme si tu écrivais
do
x <- extraction_hors_de_la_boite(boite)
met_dans_une_boite(foo x)
Sauf que l'extraction et la remise en boite, même si elles paient pas de mine là, sont en fait des fonctions qui peuvent être plus ou moins compliquées.
C'est bien un design pattern, comme tu le décris. Son avantage est d'être *très* généraliste.
Là où les dp usuels sont « limités » (un décorateur est un décorateur et n'est pas un visiteur), la monade est très configurable car l'interface ne dit rien d'autre que « ça doit typer, sinon ton algo est buggé ! »
Le concept mathématique est pas utile pour la programmation haskell. Ni pour la programmation. Les monades, c'est des foncteurs (ou un triplet de foncteurs ? je ne sais plus) dans des catégories, dans un modèle du lambda calcul simplement typé. Et c'est aussi utile pour programmer que de savoir comment représenter mathématiquement la tenue de l'encre sur le papier quand on veut juste savoir écrire.
Attention, je dis pas que c'est inutile ! J'ai bouffé des monades (mathématiques) en cours, des catégories, des power-domains, et j'en ai redemandé à l'époque. Mais à moins que tu ne cherches à faire de la sémantique dénotationnelle au niveau professionnel (recherche académique), pas la peine de se prendre la tête dessus.
T'as bien plus intérêt à te pencher sur les bases. Si tu ne sais pas pourquoi/comment on est arrivé aux catégories comme modèle et comment ça marche, alors il est vain de vouloir comprendre des concepts plus poussés qui reposent dessus.
Si néanmoins t'est un peu timbré, je te conseille l'excellentissime livre "The Scott Trachey Approach".
De mémoire t'as pas de monades, mais t'auras certainement du mal à le comprendre même en le lisant deux fois si t'as pas suivi de cours de maths et de sémantique avancées ^^
[^] # Re: Quelques petites rectifications et une question
Posté par Axioplase ıɥs∀ (site web personnel) . En réponse au journal Go : Un nouveau langage chez Google. Évalué à 3.
Des gens font ça tous les jours dans d'autres langages, y compris C (quand tu passes un pointeur vers une donnée à toute tes fonctions, genre ta surface en SDL, ta socket en réseau).
S'ils mettaient une macro pour ne plus avoir à taper à chaque fois le code redondant, ils utiliseraient la monade IO (ou la monade State) sans le savoir !
En revanche, l'idée d'encapsulation, elle, est meilleure.
Quand tu écris
do
x <- extraction
return (foo x)
c'est comme si tu écrivais
do
x <- extraction_hors_de_la_boite(boite)
met_dans_une_boite(foo x)
Sauf que l'extraction et la remise en boite, même si elles paient pas de mine là, sont en fait des fonctions qui peuvent être plus ou moins compliquées.
C'est bien un design pattern, comme tu le décris. Son avantage est d'être *très* généraliste.
Là où les dp usuels sont « limités » (un décorateur est un décorateur et n'est pas un visiteur), la monade est très configurable car l'interface ne dit rien d'autre que « ça doit typer, sinon ton algo est buggé ! »
Le concept mathématique est pas utile pour la programmation haskell. Ni pour la programmation. Les monades, c'est des foncteurs (ou un triplet de foncteurs ? je ne sais plus) dans des catégories, dans un modèle du lambda calcul simplement typé. Et c'est aussi utile pour programmer que de savoir comment représenter mathématiquement la tenue de l'encre sur le papier quand on veut juste savoir écrire.
Attention, je dis pas que c'est inutile ! J'ai bouffé des monades (mathématiques) en cours, des catégories, des power-domains, et j'en ai redemandé à l'époque. Mais à moins que tu ne cherches à faire de la sémantique dénotationnelle au niveau professionnel (recherche académique), pas la peine de se prendre la tête dessus.
T'as bien plus intérêt à te pencher sur les bases. Si tu ne sais pas pourquoi/comment on est arrivé aux catégories comme modèle et comment ça marche, alors il est vain de vouloir comprendre des concepts plus poussés qui reposent dessus.
Si néanmoins t'est un peu timbré, je te conseille l'excellentissime livre "The Scott Trachey Approach".
De mémoire t'as pas de monades, mais t'auras certainement du mal à le comprendre même en le lisant deux fois si t'as pas suivi de cours de maths et de sémantique avancées ^^