Live data from Hacker News

Monad Tutorials Timeline

wiki.haskell.org

51–60 of 63 posts

Re: Monad Tutorials Timeline

#51
post #42
post #28

Earlier quoted context omitted.

You may appreciate my own contribution, https://www.jerf.org/iri/post/2958/ , which includes an entire section titled "If They're So Wonderful Why Aren't They In My Favorite Language?", a section explaining why IO is not a good lens to understand monads and why "monads" don't really have anything to do with "making IO possible" ( very common misconception), as well as what I believe to be one of the more practical ap…

> If They're So Wonderful Why Aren't They In My Favorite Language? Aren't they now though? Like option is everywhere lately

Very few languages let you write a function that works for both Option and for other not particularly related monadic types (e.g. Future), while being fully typesafe, which is what I'd call "having monads".

Re: Monad Tutorials Timeline

#52

I have always thought that monads are just side effects and that's it.

Most monadic effects aren't executing side effects.

On the contrary, every monadic effect is a side effect. It's just that what exactly that means is specific to the monad in question.

Re: Monad Tutorials Timeline

#53
post #15

Earlier quoted context omitted.

I've read more than my fair share of these tutorials, and I'd like to be proven wrong here but I don't think I've ever seen one that explains what the point of these functional constructs (similarly with Applicative etc.) is. "You can do IO now." So what? I could do IO before that as well. Very rarely are practical explanations discussed. Even if they are discussed, the treatment is shallow and useless.

From my experience having used Haskell (a long time ago), the main benefit of Monads is the `do` and Whether this is the best thing since sliced bread or not, is left as an exercise to the reader.

> From my experience having used Haskell (a long time ago), the main benefit of Monads is the `do` and Nah, I don't even use the syntax much any more. The main benefit is the huge library ecosystem that works generically with any monad, so that if you want to e.g. traverse over a datastructure with your effectful action you can just use cataM or whatnot from recursion-schemes instead of writing it yourself, if you want to compose pipelines of them you just use Conduit, etc.

Re: Monad Tutorials Timeline

#54
post #28
post #15

Earlier quoted context omitted.

I've read more than my fair share of these tutorials, and I'd like to be proven wrong here but I don't think I've ever seen one that explains what the point of these functional constructs (similarly with Applicative etc.) is. "You can do IO now." So what? I could do IO before that as well. Very rarely are practical explanations discussed. Even if they are discussed, the treatment is shallow and useless.

You may appreciate my own contribution, https://www.jerf.org/iri/post/2958/ , which includes an entire section titled "If They're So Wonderful Why Aren't They In My Favorite Language?", a section explaining why IO is not a good lens to understand monads and why "monads" don't really have anything to do with "making IO possible" ( very common misconception), as well as what I believe to be one of the more practical ap…

I enjoyed your article, thanks for sharing.

As I understand it, one thing the tutorial didn't go into, which I think is an important subtlety, is that it's not enough to have an implementation of "bind" to have a monad interface. You also need an implementation of "return : a -> m a" (i.e. a way of making sources of 'a's when given an 'a'), AND a proof that these implementations together satisfy the monad laws (i.e. that they "play nicely" together).

Without all three components, you can have something that "looks like" a monad, in that it has definitions for "bind" and "return", but isn't actually one, because those particular definitions don't also satisfy the monad laws.

Re: Monad Tutorials Timeline

#55
post #28

Earlier quoted context omitted.

You may appreciate my own contribution, https://www.jerf.org/iri/post/2958/ , which includes an entire section titled "If They're So Wonderful Why Aren't They In My Favorite Language?", a section explaining why IO is not a good lens to understand monads and why "monads" don't really have anything to do with "making IO possible" ( very common misconception), as well as what I believe to be one of the more practical ap…

I enjoyed your article, thanks for sharing. As I understand it, one thing the tutorial didn't go into, which I think is an important subtlety, is that it's not enough to have an implementation of "bind" to have a monad interface. You also need an implementation of "return : a -> m a" (i.e. a way of making sources of 'a's when given an 'a'), AND a proof that these implementations together satisfy the monad laws (i.e.…

Per the very last section, I chose to elide those. That's mostly because few languages worry about "laws" anyhow, and the lawfulness is less consequential in a non-lazy language because even if you nominally screw up the lawfulness, the code will still reliably do whatever it does. While I suspect we could find a pretty solid plurality of HN readers to be at least somewhat appalled at the idea, I think the generally programming world is not generally worried about it.

Plus it's rather like giving out criteria for how the frosting on the cake will be judged when most of the contestants are submitting piles of slightly dampened raw flour with an egg cracked over it and being offended when you won't agree that's a "cake".

Re: Monad Tutorials Timeline

#56
post #55

Earlier quoted context omitted.

I enjoyed your article, thanks for sharing. As I understand it, one thing the tutorial didn't go into, which I think is an important subtlety, is that it's not enough to have an implementation of "bind" to have a monad interface. You also need an implementation of "return : a -> m a" (i.e. a way of making sources of 'a's when given an 'a'), AND a proof that these implementations together satisfy the monad laws (i.e.…

Per the very last section, I chose to elide those. That's mostly because few languages worry about "laws" anyhow, and the lawfulness is less consequential in a non-lazy language because even if you nominally screw up the lawfulness, the code will still reliably do whatever it does. While I suspect we could find a pretty solid plurality of HN readers to be at least somewhat appalled at the idea, I think the generally…

Ah yep - I missed that mention of "lawfulness" in the last section. I guess the minor gripe I have is that that really isn't anything to do with Haskell: it's that you only have a monadic interface when the laws are satisfied (and Haskell itself doesn't, and can't, enforce the laws: you have to check them / others using your interface have to trust that you've checked them.)

I don't quite follow why you're making a distinction for non-lazy languages?

If you want to actually use any generic monad combinators with your monad interface, and expect it to behave sensibly, then the laws had better be satisfied!

But yeah... Nice article, and I really liked your "Noun / Adjective" distinction.

Re: Monad Tutorials Timeline

#58
post #49

Very very nice timeline ! some interesting papers from the 90s section. Maybe they could add https://github.com/VincentToups/emacs-utils/blob/master/mona... . I found J.V. Toups writing very nice, and useful to see how monadic composition could exist without type support.

Some tutorials seem to predate introduction of monad itself, it seemed... )

Re: Monad Tutorials Timeline

#60
post #49

Very very nice timeline ! some interesting papers from the 90s section. Maybe they could add https://github.com/VincentToups/emacs-utils/blob/master/mona... . I found J.V. Toups writing very nice, and useful to see how monadic composition could exist without type support.

Some tutorials seem to predate introduction of monad itself, it seemed... )

Well, Moggi's paper on monads is from 91 and wadler first tutorial from 92. Am I missing something ?
Post reply on HN