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
Monad Tutorials Timeline
51–60 of 63 posts
Re: Monad Tutorials Timeline
#52Re: Monad Tutorials Timeline
#53Earlier 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.
Re: Monad Tutorials Timeline
#54Earlier 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…
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
#55Earlier 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.…
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
#56Earlier 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…
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
#57Re: Monad Tutorials Timeline
#58Very 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.
Re: Monad Tutorials Timeline
#59I have always thought that monads are just side effects and that's it.
Monads are just a pattern for chaining functions.
Re: Monad Tutorials Timeline
#60Very 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... )