I recently read the chapter on the lambda calculus in Haskell Programming from First Principles, along with the papers suggested for further reading. It was a great surprise to find that a topic I assumed would be hard to access without a math background was plenty accessible when explained well. Thank you for that!
What are your thoughts on the most effective way to explain monads? I thought @hwayne’s post https://hillelwayne.com/post/monad-tutorials/ was a good elucidation of the imperfection of all familiar monad explainers. I haven’t read the chapter on monads in your book, which might be the answer to my question.
I think explanations like this SO answer are often regarded as unhelpful to beginners. But the most fruitful insights I have come from the learning I do in an attempt to understand statements like “a monad is just a monoid in the category of endofunctors”. The best intuitions I’ve in concrete applications of these topics have come from struggling to understand these concepts abstractly, in terms of algebraic law and not in terms of metaphor or patterns of use.
What are your thoughts on the most effective way to explain monads?
You already mentioned how I think people should learn Monad: Haskell Programming from First Principles.
But more seriously, there’s no point explaining Monad to someone unless they’ve already learned enough Haskell to learn Monad in Haskell. The word-stuff and thought-stuff that Haskell equips you with gives you an automatically verified, mechanical way to work through exercises that will teach you Monad.
I really have to agree with this. I was just reading “Real World Haskell” today (refreshing my Haskel for programming competitions), and it’s chapter on Monads was very clear, since the book had been building up to it, not by introducing the maths (that was in fact the last part of the chapter) but by showing it’s use, background (idea) and slowly sneaking up to the actual implementation.
To do this properly, blog posts will rarely find the right words. It’s a longer processes, where at the end you realize that you’ve already understood it for a while, and all that was missing was the name.
I’ve almost drafted a similar blogpost in order to try to explain to myself what a Monad is. Damn!
It’s okay if the answer doesn’t mean a lot to you. It won’t map onto concrete coding intuitions very well. I don’t like this meme at all.
I recently read the chapter on the lambda calculus in Haskell Programming from First Principles, along with the papers suggested for further reading. It was a great surprise to find that a topic I assumed would be hard to access without a math background was plenty accessible when explained well. Thank you for that!
What are your thoughts on the most effective way to explain monads? I thought @hwayne’s post https://hillelwayne.com/post/monad-tutorials/ was a good elucidation of the imperfection of all familiar monad explainers. I haven’t read the chapter on monads in your book, which might be the answer to my question.
I think explanations like this SO answer are often regarded as unhelpful to beginners. But the most fruitful insights I have come from the learning I do in an attempt to understand statements like “a monad is just a monoid in the category of endofunctors”. The best intuitions I’ve in concrete applications of these topics have come from struggling to understand these concepts abstractly, in terms of algebraic law and not in terms of metaphor or patterns of use.
You already mentioned how I think people should learn
Monad: Haskell Programming from First Principles.But more seriously, there’s no point explaining
Monadto someone unless they’ve already learned enough Haskell to learnMonadin Haskell. The word-stuff and thought-stuff that Haskell equips you with gives you an automatically verified, mechanical way to work through exercises that will teach youMonad.I really have to agree with this. I was just reading “Real World Haskell” today (refreshing my Haskel for programming competitions), and it’s chapter on Monads was very clear, since the book had been building up to it, not by introducing the maths (that was in fact the last part of the chapter) but by showing it’s use, background (idea) and slowly sneaking up to the actual implementation.
To do this properly, blog posts will rarely find the right words. It’s a longer processes, where at the end you realize that you’ve already understood it for a while, and all that was missing was the name.