Hacker News Reader

Comment by huqedato | Hacker News Reader

Monads are hard. I read many articles explaining what a monad is and what is good for but I never really grasped the concept. I probably have to learn Haskell.

View on HN

There's an endless stream of monad tutorials and I think they (almost) all misunderstand the point of confusion. No one gives a f*** about monads, they care about state.

If you've internalized reasoning about a program's execution symbolically and in a time-independent way, then monads solve the problem of how you enforce a correct sequencing of otherwise time-independent operations at a library level without any fancy modifications to the type system. And oh by the way, this structure shows up everywhere and isn't that pretty cool. People who hang around in the formal PL world tend to assume this already because it emerges naturally from how we talk about the semantics of languages via symbolic manipulation.

But if you haven't grasped that yet, then monads solve a problem that you probably don't even realize exists and no amount of rephrasing the monad laws will help you.

I'd almost always recommend anyone new to Haskell ignore monads as much as possible. Fiddle around with evaluating toy functions with pen and paper symbolically to reason about the semantics, and then try to imagine how you could represent the state of a program changing across the page by creating a new object representing the state of the program from the old state. Then, dig in to the RealWorld type and how the IO Monad actually works (not at a type level).

Thanks for explanation. The point is that I do not really intend to learn Haskell (I don't have the motivation for), I've been just (very) curious to understand what's about these concept called monad: - Why does should exist? Why can't they be simply replaced with control structures (if, case, switch etc.) ? - Why there is so much fuss on the web, in the FP world, about monads?

They can't be explicitly replaced with control structures because implicit in that suggestion is the idea that when writing code you write what the code _does_. If you call the same function with the same inputs you can expect exactly the same machine level code to execute (perhaps taking different branches based on external state it reaches out for).

Contrast that with what happens in Haskell and friends. When writing code you define what the _inputs and outputs_ for particular functions should be. The actual code generating those inputs and outputs is free to be replaced or removed as the compiler sees fit. That buys you a lot of things (trivial parallelization, excellent type checking, ...), but it self inflicts an extra problem we didn't have in the previous paradigm:

In the real world, we don't in fact just want to run a program and get an output. The way we interact with, e.g., a GUI is an important part of the program's behavior. If your mental model of code is that we're sequentially doing a series of things then this isn't ever a problem you would even have because you would just write your code to do the right things at the right time, but if you've adopted a model where you're defining outputs for your inputs you need some way to shove state and order of effects into that system for it to be useful.

Enter stage-left: monads! Yes they're pretty and ubiquitous and whatever, but the problem they solve for us is specifying an order of events (by virtue of taking the entire monad in as an input and spitting it out as an output) in a way wholly compatible with the type system we've already developed.

https://fsharpforfunandprofit.com/rop/ is by far my most recommended starting point, using a railway analogy. To grossly oversimplify, as far as I can tell, a monad is a type well-defined enough that you can hook up functions that work with it in a “parallel tracks” manner. So it’s great for chained functions, and reusing and weaving those functions, where you accumulate information other than the “obvious” thing to return as you go along, like errors or logging or IO.

I know that also. Not great not terrible. Still couldn't clarify the thing.

It strongly depends on your background. What kind of programs are you writing? If you have a lot of boilerplate for error handling, creating chains of promises or passing a file handler to log to around, that's the kind of thing monads can help abstract away (from a programming point of view).

They are a more general construction in category theory but knowing that doesn't tell you how to use them (because the full generality is not often needed).

This was how it was taught at my school in Java [0], although thinking about monads as a container is weird since functions are monads as well.

[0] https://nus-cs2030s.github.io/2021-s2/33-monad.html

How about [2013 Philip Wadler - The First Monad Tutorial](https://www.youtube.com/watch?v=yjmKMhJOJos&t=1490s&ab_chann...)

Yes, and monads in Haskell seem a bit different from monoids in the category of endofunctors.

From personal experience Scala also works. It's 100% possible to learn monads using https://scastie.scala-lang.org/ as a scratch pad.

I read once, somewhere, an advice from a computer scientist: one with OOP background should perceive a monad as a class that has everything contained: types, declarations, methods, error handling. Is it true ?

Reply on news.ycombinator.com