Hacker News Reader

Comment by cjfd | Hacker News Reader

I am not a haskell pogrammer but reading about monads it seems much ado about nothing. It seems that one does not need to understand category theory to understands monads. Basically, I would say, in very basic language, that a monad is a thing that swallows values so you cannot get them back. You can have one function that produces a value that is swallowed by the monad. Then you can compose these kinds of functions one after another and have all values swallowed by the monad. The use is e.g., to do output (IO monad) or do error handling (maybe monad). If you could get back your values from the output the output could be used to store state and functional programmers hate that so the output is a monad and cannot be used to get the state back.

View on HN

I had a dozen people try to describe Monads to me, many of them Haskell programmers.

The one that finally made it click, was from a very senior Haskell dev who said:

  "People overcomplicate things. "Functor" is a fancy word for an interface that has the .map() method, and then "Monad" is a fancy word for a interface that has ".map" and ".flatMap" both"

Or something like that, I think. This probably isn't totally right, but IIRC it's something like this:

  interface Functor<A> {
    map: <B>(
      transform: (a: A) => B,
      a: A,
    ) => B[]
  }


  interface Monad<A> extends Functor<A> {
    flatMap: <B>(
      transform: (a: A) => B,
      a: A,
    ) => B
  }

Which helps me to think about it and understand it. None of the other explanations made any sense.

The explanation is kind of right but the code isn't.

The map function needs to return a Functor and flatMap takes a function A => Monad and returns a Monad.

That's actually not 100% correct either as those are in fact higher kinds, so it's more like you have a generic F<_> that can be a functor or a monad or whatever, and the signature for functor map actually returns a F, and flatMap takes a A => F, returning a F.

It's quite easy to grok looking at Scala.

As the sibling says, your code's a little off; but the approach of "they're just an interface" is the way I think of them too.

We shouldn't forget the associated "functor laws" and "monad laws", but they're pretty intuitive and not much different than more mainstream rules; e.g. a 'Serialize' interface might have a "law" like 'Serialize.load(Serialize.save(x)) == x'

It depends on what you mean by "swallows values". If I have an IO<T>, I can very easily get at the T that's inside by flatMapping over it. It's true that there's no way to turn an IO<T> straight into a T -- whatever you do with the T must always get wrapped back in IO<-> at the end of the day -- but it's not gone, and indeed we do use monads to store state. (There's literally a monad called `State`, actually.)

What monads don't let you get at -- at least, not without more knowledge about which monad you're using -- is whatever other information given alongside the Ts it contains. If I've got a random M<T>, and I don't know that M is Option, I can only operate over all the Ts (the either zero or one of them) it contains, but I can't tell whether it has any Ts in the first place.

Monads are a unification of a bunch of computer stuff, including sequencing, IO, non-determinism, state, concurrency and exceptions. When I say "unification", I mean it in the sense that Newton's theory of gravity unified the motion of the planets with a falling apple (previously they were considered separate phenomena), or how Maxwell's equations unified electricity and magnetism. Once you grok monads you realise that all those different things I listed are just special cases of one overarching theory.

The word itself comes from Category Theory. That's why a comprehensive understanding requires it, since the implementation of the concept in programming derives from the definition in CT.

The difficulty of understanding the concept is blurred because both the implementation and the mathematical object are called "monad", but they are technically different. The implementation of it could be simplified as many do, but it still doesn't explain the actual math object's definition. The implementation is not as abstract as the math object, which means it is also not as powerful, so it becomes a limited understanding by definition.

From my perspective, CT is the math of abstract composition, and is foundational mathematics from which other maths can be derived. This highly abstract nature of it, makes it hard to "simplify" further with an explanation. Monad is already by definition as simple as possible, and it's confusing that its implementations in programming get the same name (although I'm not sure naming it differently would help either).

The best explanation of functional concepts is (rather unsurprisingly) done using Javascript. See Functional Programming Jargon: https://github.com/hemanth/functional-programming-jargon#mon...

Purists say that it's not correct (monadic laws and all that), but it's a vastly more approachable explanation than literally any monad tutorial.

My few word explanation: Monad is a wrapper for effectful impure functions. It swallow the effect (not value) and assure a defined value type to be available for further computing.

Reply on news.ycombinator.com