<br><br><div><span class="gmail_quote">On 8/14/07, <b class="gmail_sendername">Michael Vanier</b> <<a href="mailto:email@example.com">firstname.lastname@example.org</a>> wrote:</span><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm becoming more and more convinced that metaphors for monads do more harm than good. From now on<br>I'm going to describe monads as purely abstract entities that obey certain laws, and that _in<br>certain instances_ can be viewed to be like containers, or actions, or donuts, or whatever. In
<br>other words, a monad is an abstract thing that can generate things that we can metaphorize, but it's<br>pointless (point-free?) to try to capture the entire concept in a single metaphor. I'm reminded of<br>a physics teacher who was having a similar problem explaining the concept of tensors, until he said
<br>that "a tensor is something that transforms like a tensor does!". So a monad is something that<br>behaves like a monad does.</blockquote><div><br><br>Nice. As a Haskell beginner (with previous imperative programming experience) I subscribed to this list today to say exactly that. I spent weeks reading different tutorials that attempted to enlighten by means of various abstractions before I finally found one that simply showed the mechanics of the required operators and rules (sounds less formal than laws) that they need to hold to. Even then I hadn't quite "got it" until I met SPJ at OSCON and heard myself saying, "All monads are are labels in front of values with specific operations defined on them." His reply was, "Yes! Very abstract isn't it?" Then I'd "got it", or realized that I had but hadn't realized it (if that makes any sense...), as that sequential exchange of ideas (hah!) brought me to the realization that the "abstractions" that monads are held to represent are solely in the usage semantics of aforesaid operations and, while technically the actual labels used don't matter, we pick labels whose meaning match those semantics.
<br><br>So, yes, don't start by giving any extra meaning to the basic monad operations than their mechanics. Then show how they can be use to "implement" abstractions like state, uncertainty, etc...<br></div>
<br></div>Oh yeah, start with terms that programmers already know, e.g. encapsulation v. wrappers. Then switch. Don't start with terminology that's different and explain the mappings, start with the familiar than follow the mappings to the different.
<br clear="all"><br>-- <br>Erik Jones<br><a href="mailto:email@example.com">firstname.lastname@example.org</a><br>