4 ms·

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 understa

by cjfd 5y ago

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.

Twisol 5y ago
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.
deleted 5y ago
[deleted]
fbn79 5y ago
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.
PaulAJ 5y ago
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.
gavinray 5y ago
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: ( transform: (a: A) => B, a: A, ) => B[] } interface Monad<A> extends Functor<A> { flatMap: ( 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.
- still_grokking 5y ago
 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.
- chriswarbo 5y ago
 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'
proc0 5y ago
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).
dmitriid 5y ago
The best explanation of functional concepts is (rather unsurprisingly) done using Javascript. See Functional Programming Jargon: https://github.com/hemanth/functional-programming-jargon#monad 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.

by cjfd 5y ago

Twisol 5y ago

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.

deleted 5y ago

[deleted]

fbn79 5y ago

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.

PaulAJ 5y ago

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.

gavinray 5y ago

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: ( transform: (a: A) => B, a: A, ) => B[] } interface Monad<A> extends Functor<A> { flatMap: ( 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.

still_grokking 5y ago
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.
chriswarbo 5y ago
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'

proc0 5y ago

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).

dmitriid 5y ago

The best explanation of functional concepts is (rather unsurprisingly) done using Javascript. See Functional Programming Jargon: https://github.com/hemanth/functional-programming-jargon#monad 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.