Monad Tutorials Timeline • Hacker News Board

Re: Monad Tutorials Timeline

#61

Post by jerf » Fri, May 01, 2026, 6:00 PM UTC

thefunkychook wrote: post #56

jerf wrote: post #55

Earlier quoted context omitted.

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 d…

My understanding, which may be incorrect, is that the major reason that lawfulness matters in Haskell is the laziness makes it so that unlawful monads won't just do "something that violates the laws", an abstract, mathematical consideration that maybe you care about, maybe you don't, but that the combination of the laziness and the aggressively optimizing compiler means that result will be very unpredictable, and slight and seemingly isomorphic source changes can result in unpredictable results.

In Python, if I write an iterator on something pretending to be a list, and when it sees strings it doesn't just return an uppercased string but actually modifies the contents of the list to be uppercased, that's stupid, but at least since it's a strict language that isn't interleaved with IO and all the other stuff flying around in Haskell it will be consistently stupid. It isn't going to blow up or behave differently if I accidentally flip an "a + b" into a "b + a" somewhere.

It's bad, but Haskell has a whole different level of bad if you screw with it and don't play within the sandbox.

There is a definite "I'm being more pragmatic here than the average Haskell programmer" effect going on here. I... how to put this... "won't blink" is too strong, but... if I need to violate a law, if I need to write something like the stupid iterator above, I am in fact willing to. I have the decency to feel bad about it, and there will be extensive and probably bitingly sarcastic comments attached to it, but I'll do it. (Generally only when I don't control one end of the source code, though. If I have full control I never do anything that stupid.) But in Haskell it's a particularly bad idea, mostly because of the laziness and its interaction with other things.

And, heh, in a world where the struggle to explain what monads even are to people, monad combinators aren't even on my horizon.

Re: Monad Tutorials Timeline

#62

Post by bazoom42 » Sat, May 02, 2026, 9:05 AM UTC

tayo42 wrote: post #42

jerf wrote: 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

Many languages have monads “by accident”, e.g JavaScript by way of Array.flatMap() - but the fact this type happen to satisfy the monad rules is not particularly useful.

Re: Monad Tutorials Timeline

#63

Post by whateveracct » Sun, May 03, 2026, 2:58 PM UTC

alper wrote: post #15

preommr wrote: post #6

To explain like two fundamental rules (we can make wrapper types, and do flatmap) I will: - Write 5 paragraphs setting up an imaginary scenario involving fantasy elements of aliens, dragons, and a magical kindom where they speak using message boxes - Introduce basic category theory by starting with what a functor is - Explain all the effects of a monad in such general terms that it basically amounts to anything and e…

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.

Think of Monad (and really the whole typeclassopedia in a way) like Iterable in Java

what does it gives you? for loops

what do the haskell things give you? various types of for loops. monads in particular have `do` which is a language construct. but the rest are just higher order functions that are specific types of `for` loops

you learn a handful of these and then all programs are the same. you can whisk together complex control flow across domains with the same few abstractions. you can hop into a library, see these type class instances, and know how to use the library.

stuff like that.