Monads, Zippers and Views: Virtualizing the Monad Stack | Hacker News Reader

Monads, Zippers and Views: Virtualizing the Monad Stack

ropas.snu.ac.kr

60 pointsburo99 comments

42 Votes and I have no idea what this is all about. Can somebody please give us a summary for the "uneducated" ;)

Monads offer a level of abstraction over non-functional parts (anything that might have side effects) of a functional program. In functional programming, the idea is that every time you put something into a function, you should get the same result (i.e. every time you put a 5 into a doubling function, you get a 10). A byproduct of that simple idea, is the possibility of extreme complexity, and thus the reason for an extra level of abstraction. It's easier for many to reason about this potential complex behavior at a higher level.

This article talks about some of the options of adding an additional level of abstraction on top of the monad. The idea is that some people find it difficult to reason about monads, because they have so many specific applications (read 10 monad articles and you'll get 10 different definitions for what they are).

TLDR: It's an abstraction of an abstraction that might help you reason better about complex things.

Thank you for this - the first sentence helped immensely.

And is also grossly wrong (or to put it more charitably, over-specific). The only monad that has to do with side effects is IO, and that's a special one built into the language.

Haskell's do-notation could almost be said to abstract side effects because it makes monad actions look like imperative programs, but they're still pure-functional unless they're in the IO monad.

Do you have/know of a similarly understandable description of monads, preferably with examples? I'd love to see one.

It is overly specific, but it's probably the easiest to understand explanation for someone who is familiar with imperative programming. Concurrency, continuations and exception monads are all likely more difficult to grasp.

A more accurate explanation would say that monads are just an abstraction that encapsulates program logic. Someone unfamiliar with the concept might not see WHY that's important. So my example was tangible, but not all inclusive.

One of the big issues with abstract concepts like monads, is that most people insist on using a long-winded complex explanation up front. I find it's better to pique interest, and make the concepts accessible, with the hope that the reader later is willing to dig in and learn more themselves. I probably could have done a better job of explaining that the IO monad isn't the only monad, but I think it did a "good enough" job of explaining a way to think about them.

This is a good point of view to come from. I just think it's important to emphasize two things, to avoid the monad-insanity that people often get- 1) IO is not the only monad, and 2) monads are not the only, or even best, of this kind of abstraction.

Learning about monads without (applicative) functors makes everything look like an over-complicated nail.

It is about making higher level monads, with benefits in reusability. About monads:

One very good explanation on the topic: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

Monads are (quote) elephants: http://james-iry.blogspot.com/2007/10/monads-are-elephants-p...

Monads can be implemented in OO languages, like ruby: http://moonbase.rydia.net/mental/writings/programming/monads...

This is pretty arcane even for Haskell aficionados. I have no idea what it is doing on Hacker News.

Reply on news.ycombinator.com