科技回声

A couple of earlier appearances netted some discussion:<p><a href="https://news.ycombinator.com/item?id=28690798">https://news.ycombinator.com/item?id=28690798</a><p><a href="https://news.ycombinator.com/item?id=431702">https://news.ycombinator.com/item?id=431702</a>

When folks ask "What is a monad?", they usually don't want the technical meaning, they're wondering what they can do to see why they should care or take the time to learn/use them. Here's a summary[0] that's as good as any I've seen.<p>> Summary. We have seen that a monad is a type constructor, a function called return, and a combinator function called bind or >>= . These three elements work together to encapsulate a strategy for combining computations to produce more complex computations.<p>[0] <a href="https://wiki.haskell.org/All_About_Monads#Summary" rel="nofollow">https://wiki.haskell.org/All_About_Monads#Summary</a>

Like models, all abstraction are False, but some are usefull. I never found Monad to be usefull : a abstraction shared by async/await and map/list comprehension is for me a bad abstraction, because as a developper I typically want to know if I'm dealing with the former or the later. And want to manually combine them, like with gather.

It always disappointed me how utterly unlike a burrito a monad turns out to be. No hint of beans, queso, or salad.

That reminds me, I should write a Monad tutorial.

It always disappointed me how utterly unlike a burrito a monad turns out to be. No hint of beans, queso, or salad.

That reminds me, I should write a Monad tutorial.

The "Monad Tutorial Fallacy" (2009)

5 条评论

The "Monad Tutorial Fallacy" (2009)

5 条评论