8 ms·

Blog post that explains Functors, Applicatives, And Monads in pictures http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html http:

Blog post that explains Functors, Applicatives, And Monads in pictures http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...

pwm 7y ago
Honestly, this blog post is cute but it does not actually give you understanding and insight into these concepts. Imho the only way to internalise these are through practice. Write code, get annoyed by repetition/boilerplate/etc... and discover that abstraction Foo solves that problem.
modernerd 7y ago
This blog post may help some but readers shouldn't expect it to magically flick a switch that allows them to use or create monads. Instead, I really like: 1. Stephen Diehl's “Eightfold Path to Monad Satori” from “What I Wish I Knew When Learning Haskell”: http://dev.stephendiehl.com/hask/#monads http://dev.stephendiehl.com/hask/#monads “Much ink has been spilled waxing lyrical about the supposed mystique of monads. Instead, I suggest a path to enlightenment: 1. Don't read the monad tutorials. 2. No really, don't read the monad tutorials. 3. Learn about Haskell types. 4. Learn what a typeclass is. 5. Read the Typeclassopedia. 6. Read the monad definitions. 7. Use monads in real code. 8. Don't write monad-analogy tutorials. In other words, the only path to understanding monads is to read the fine source, fire up GHC, and write some code. Analogies and metaphors will not lead to understanding.” 2. Chris/kqr's “The ‘What Are Monads?’ Fallacy?”, which mirrors the advice from Stephen Diehl: https://two-wrongs.com/the-what-are-monads-fallacy https://two-wrongs.com/the-what-are-monads-fallacy “Instead, learn to use specific monads. Learn how Maybe a works, learn how Either e a works. Learn how IO a and [a] and r -> a works. Those are all monads. Learn to use them with the >>= operator and with do notation. Once you've learned how to work with all of those, you'll have a really good idea of how monads can be used. Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”
- tome 7y ago
  > Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.” This is such a great analogy!
- JCoder58 7y ago
  Eric Lippert's blog series on Monads[1] follows this approach and is very effective in teaching the concepts behind Monads. He starts out with standard concepts from C# that are Monads and shows how they're implemented and what they have in common. It is very approachable for an object-oriented programmer who's curious about functional programming. 1: https://ericlippert.com/2013/02/21/monads-part-one/ https://ericlippert.com/2013/02/21/monads-part-one/
- roenxi 7y ago
  > Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.” Another good analogy might be learning circular breathing for ordinary everyday conversation. You might hear the circular breathing is an amazing thing that allows you to do things you couldn't otherwise do. If you are trying to use that trick without ever learning to play an instrument then there will be a great air of mystery to it all. Monads solve problems that are only made apparent by other design decisions in Haskell. In a non-functional, loosely typed context they are not so useful.
  - modernerd 7y ago
    Yes, I didn't include the papers below in my parent response because, “just read these dense academic papers to understand what monads are and why Haskell has them” doesn't tend to be good advice for Haskell beginners. But learning why monads came to be included in Haskell is useful if you want to dive deeper into this stuff: Philip Wadler's original paper on Comprehending Monads [PDF]: https://ncatlab.org/nlab/files/WadlerMonads.pdf https://ncatlab.org/nlab/files/WadlerMonads.pdf Philip Wadler and Simon Peyton-Jones' paper on Imperative Functional Programming [PDF]: https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... Simon Peyton-Jones mentions both papers and talks about why monads came to be part of Haskell in his talk on the history of Haskell here, with examples that are a little more accessible than the above papers: https://www.youtube.com/watch?v=re96UgMk6GQ https://www.youtube.com/watch?v=re96UgMk6GQ [introduction to purity and then monads starts around 30:07] It's a funny talk and it's worth watching in full, but here's a nice soundbite: “So what did we do for IO? Well, we just didn't have any. [audience laughs] So the joy of being an academic, right, is you can design a language — in 1990, I beg to inform you — that had no input/output. A Haskell program was simply a function from string to string. That was what it was. … But this was a bit embarrassing…” He goes on to talk about other ideas they explored to create effects, why they settled on monads, and why he wishes now they had called them something like “workflows” (as F# later did[1]) to make them sound less intimidating. (Simon and Philip will both be at Haskell Exchange 2019 in London this coming week if anyone else, like me, enjoys spending two days as the dumbest person in the room: https://skillsmatter.com/conferences/11741-haskell-exchange-2019 https://skillsmatter.com/conferences/11741-haskell-exchange-... ) [1]: https://blogs.msdn.microsoft.com/doriancorompt/2012/05/25/7-workflows-a-monad-alias/ https://blogs.msdn.microsoft.com/doriancorompt/2012/05/25/7-...
goto11 7y ago
Condescending tutorials seem to be an integrated part of Haskell culture. The rationale might be that people who don't already know Haskell should to talked to like kids. "Don't be scared, a monad is just like a Burrito!" and so on. I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available. I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.
- tome 7y ago
  > Condescending tutorials seem to be an integrated part of Haskell culture. Could you perhaps link to one? I know of plenty of misguided tutorials that try to be helpful but aren't. I've never come across one I'd call "condescending". > I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available. Yet for some reason newcomers (reputedly) want to know what a monad is before trying to use one! I agree with you: they should go ahead and use one and not worry about what it is!
  - pram 7y ago
    It's not unique to Haskell, and I wouldn't say condescending. More like patronizing and a little infantile. 'Learn you a Haskell' is in the same tone. Ultimately most of these are just imitations of the 'poignant guide to ruby' which is probably responsible for starting the trend of whimsical and zany programming guides.
  - goto11 7y ago
    You need to use the IO monad to write "hello world". So it is naturally the first question a newcomer will ask. But for example "Learn you a Haskell" http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters postpones "hello world" to chapter 9, after explaining things like type classes. So the reader is expected to read and understand 9 chapters before writing the first program? This is ridiculous - I certainly wouldn't be able to learn anything that way.
karmakaze 7y ago
This is one of two posts that made things click for me. This one clearly distinguishes Functors, Applicatives, and Monads visually so that I don't get hung up on the names every time I encounter them. The other article that demonstrated the practical purpose or path to constructing Monads showed a number of them using nested procedural syntax formatted to look like do-notation. [I can't remember the title/link, if anyone knows please post.] It went through async/await, maybe or list and showed them rearranged with the 'monad'ic parts off to the right where semi-colons might be. Do-notation just took that and flattened the nested structures. The appreciation that these different computational contexts could all be structured the same way while focusing on what's happening apart from these contexts really demonstrated why it's useful and the power of being able to encapsulate these seemingly different ideas. I'm sure I'll need to find a part-3 in my journey (perhaps Monad transformers) and so on, but I've at least got a good footing from those.
- ghostwriter 7y ago
  The best intro to monad transformers that I've seen so far is https://mmhaskell.com/monads/transformers https://mmhaskell.com/monads/transformers

pwm 7y ago

Honestly, this blog post is cute but it does not actually give you understanding and insight into these concepts. Imho the only way to internalise these are through practice. Write code, get annoyed by repetition/boilerplate/etc... and discover that abstraction Foo solves that problem.

modernerd 7y ago

This blog post may help some but readers shouldn't expect it to magically flick a switch that allows them to use or create monads. Instead, I really like: 1. Stephen Diehl's “Eightfold Path to Monad Satori” from “What I Wish I Knew When Learning Haskell”: http://dev.stephendiehl.com/hask/#monads http://dev.stephendiehl.com/hask/#monads “Much ink has been spilled waxing lyrical about the supposed mystique of monads. Instead, I suggest a path to enlightenment: 1. Don't read the monad tutorials. 2. No really, don't read the monad tutorials. 3. Learn about Haskell types. 4. Learn what a typeclass is. 5. Read the Typeclassopedia. 6. Read the monad definitions. 7. Use monads in real code. 8. Don't write monad-analogy tutorials. In other words, the only path to understanding monads is to read the fine source, fire up GHC, and write some code. Analogies and metaphors will not lead to understanding.” 2. Chris/kqr's “The ‘What Are Monads?’ Fallacy?”, which mirrors the advice from Stephen Diehl: https://two-wrongs.com/the-what-are-monads-fallacy https://two-wrongs.com/the-what-are-monads-fallacy “Instead, learn to use specific monads. Learn how Maybe a works, learn how Either e a works. Learn how IO a and [a] and r -> a works. Those are all monads. Learn to use them with the >>= operator and with do notation. Once you've learned how to work with all of those, you'll have a really good idea of how monads can be used. Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.”

tome 7y ago
> Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.” This is such a great analogy!
JCoder58 7y ago
Eric Lippert's blog series on Monads[1] follows this approach and is very effective in teaching the concepts behind Monads. He starts out with standard concepts from C# that are Monads and shows how they're implemented and what they have in common. It is very approachable for an object-oriented programmer who's curious about functional programming. 1: https://ericlippert.com/2013/02/21/monads-part-one/ https://ericlippert.com/2013/02/21/monads-part-one/
roenxi 7y ago
> Asking "What is a monad?" to learn how to use monads is as wrong as asking "What is a musical instrument?" to learn how to play musical instruments. It's a good start, but it won't teach you very much.” Another good analogy might be learning circular breathing for ordinary everyday conversation. You might hear the circular breathing is an amazing thing that allows you to do things you couldn't otherwise do. If you are trying to use that trick without ever learning to play an instrument then there will be a great air of mystery to it all. Monads solve problems that are only made apparent by other design decisions in Haskell. In a non-functional, loosely typed context they are not so useful.
- modernerd 7y ago
  Yes, I didn't include the papers below in my parent response because, “just read these dense academic papers to understand what monads are and why Haskell has them” doesn't tend to be good advice for Haskell beginners. But learning why monads came to be included in Haskell is useful if you want to dive deeper into this stuff: Philip Wadler's original paper on Comprehending Monads [PDF]: https://ncatlab.org/nlab/files/WadlerMonads.pdf https://ncatlab.org/nlab/files/WadlerMonads.pdf Philip Wadler and Simon Peyton-Jones' paper on Imperative Functional Programming [PDF]: https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... Simon Peyton-Jones mentions both papers and talks about why monads came to be part of Haskell in his talk on the history of Haskell here, with examples that are a little more accessible than the above papers: https://www.youtube.com/watch?v=re96UgMk6GQ https://www.youtube.com/watch?v=re96UgMk6GQ [introduction to purity and then monads starts around 30:07] It's a funny talk and it's worth watching in full, but here's a nice soundbite: “So what did we do for IO? Well, we just didn't have any. [audience laughs] So the joy of being an academic, right, is you can design a language — in 1990, I beg to inform you — that had no input/output. A Haskell program was simply a function from string to string. That was what it was. … But this was a bit embarrassing…” He goes on to talk about other ideas they explored to create effects, why they settled on monads, and why he wishes now they had called them something like “workflows” (as F# later did[1]) to make them sound less intimidating. (Simon and Philip will both be at Haskell Exchange 2019 in London this coming week if anyone else, like me, enjoys spending two days as the dumbest person in the room: https://skillsmatter.com/conferences/11741-haskell-exchange-2019 https://skillsmatter.com/conferences/11741-haskell-exchange-... ) [1]: https://blogs.msdn.microsoft.com/doriancorompt/2012/05/25/7-workflows-a-monad-alias/ https://blogs.msdn.microsoft.com/doriancorompt/2012/05/25/7-...

goto11 7y ago

Condescending tutorials seem to be an integrated part of Haskell culture. The rationale might be that people who don't already know Haskell should to talked to like kids. "Don't be scared, a monad is just like a Burrito!" and so on. I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available. I actually think Haskell is a very enjoyable language, but there is a culture around it which treats the type concepts (arrows, monads etc.) like goals in themselves rather than tools to achieve something useful.

tome 7y ago
> Condescending tutorials seem to be an integrated part of Haskell culture. Could you perhaps link to one? I know of plenty of misguided tutorials that try to be helpful but aren't. I've never come across one I'd call "condescending". > I can't recollect I have ever learned a programming concept through metaphors. The only way I have learned concepts is though solving tasks in a language and thereby learning to use the tools available. Yet for some reason newcomers (reputedly) want to know what a monad is before trying to use one! I agree with you: they should go ahead and use one and not worry about what it is!
- pram 7y ago
  It's not unique to Haskell, and I wouldn't say condescending. More like patronizing and a little infantile. 'Learn you a Haskell' is in the same tone. Ultimately most of these are just imitations of the 'poignant guide to ruby' which is probably responsible for starting the trend of whimsical and zany programming guides.
- goto11 7y ago
  You need to use the IO monad to write "hello world". So it is naturally the first question a newcomer will ask. But for example "Learn you a Haskell" http://learnyouahaskell.com/chapters http://learnyouahaskell.com/chapters postpones "hello world" to chapter 9, after explaining things like type classes. So the reader is expected to read and understand 9 chapters before writing the first program? This is ridiculous - I certainly wouldn't be able to learn anything that way.

karmakaze 7y ago

This is one of two posts that made things click for me. This one clearly distinguishes Functors, Applicatives, and Monads visually so that I don't get hung up on the names every time I encounter them. The other article that demonstrated the practical purpose or path to constructing Monads showed a number of them using nested procedural syntax formatted to look like do-notation. [I can't remember the title/link, if anyone knows please post.] It went through async/await, maybe or list and showed them rearranged with the 'monad'ic parts off to the right where semi-colons might be. Do-notation just took that and flattened the nested structures. The appreciation that these different computational contexts could all be structured the same way while focusing on what's happening apart from these contexts really demonstrated why it's useful and the power of being able to encapsulate these seemingly different ideas. I'm sure I'll need to find a part-3 in my journey (perhaps Monad transformers) and so on, but I've at least got a good footing from those.

ghostwriter 7y ago
The best intro to monad transformers that I've seen so far is https://mmhaskell.com/monads/transformers https://mmhaskell.com/monads/transformers