> This blog entry neatly berates those assuming a metaphor which helps
> them think about monads, after going through a difficult process of
> learning, is going to help someone else learning them:
> http://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/

as a low-level (as in early, not as in to-the-metal) haskeller, i
do/do/will take issue with that attitude. it seems to say that using a
metaphor is to tilt at windmills for monads. i call b.s. because
metaphors are useful as a foothold, although any given metaphor has a
particular audience for it. a problem is nobody really knows ahead of
time which audience they are in and thus which metaphor to seek when
learning something. [personally i have always found this to be a
frustrating aspect of our educational system/philosophy -- we should
all know what type of metaphor audience we are most comfortable in,
and knowledge should be represented in as many of those facets of
understanding as possible. plus everybody should know that the map is
not the territory and that metaphors are training wheels.]
furthermore, while metaphors /can/ be useful for learning, they are
not something you wish to encode into a system which is meant to be
widely used, because, duh, they will limit you to that audience. so
you don't implement monads in haskell with names like "space suit" but
if it works to teach somebody, so be it.

(interesting that Matz says he wrote Ruby for himself, which i would
think partially means for he metaphors he himself groks.)


Reply via email to