Hacker News new | past | comments | ask | show | jobs | submit login

>Isn't that kind of the problem?

Maybe. Leaving things in the abstract can certainly be confusing sometimes.

>I have no idea why it's a good abstraction for anything or what sorts of things it's a good abstraction for.

I think once you understand Monads for what they are (i.e. accept that it's just something with bind and return), you start seeing where it makes sense to use Monads. Until then, you can just use whatever concrete Monad implementations you're aware of. It seems like you know perfectly well that there exist Monad implementations for Lists, for example.

> Because it says what it does on the tin, rather than being buried under several abstraction layers.

IO, List, and most other Monads do what they say on the tin, even if you're not aware that they're Monads.

You don't have to know if something is a Monad or not to use it. For example, I've been using Lists my entire programming career without it occurring to me that I could use them with bind to model nondeterminism or the ZipList Monad.

>but unless they actually mean something solid, how are they useful in explaining or solving a problem?

They are useful because they are examples of http://en.wikipedia.org/wiki/Algebraic_structure .

You can use the definition of an algebraic structure to prove things about all instances of that structure.

Monads are, in fact, quite useful even in their most general definition.




ZipList isn't a monad, is it?


You're right. I think I mis-remembered reading the Applicative instance for ZipList.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: