Shameless plug:

I wrote an article for "Linux Journal" called "Everything Your Professor Failed to Tell You About Functional Programming". Hopefully you will enjoy the article.

http://www.linuxjournal.com/article/8850

(By the way, I'm not on the cafe mailing list, so please cc me on any replies.)

Nice article, good to see people trying to get these ideas out to the masses. There are some issues with it that I'd like to mention. The term "monad" is misused a couple of times, especially in the examples in your article. The only thing which is a monad is the type constructor -- the function on types, never the elements of any given type. So Maybe is a monad, but (Just 5) isn't. Another slightly odd thing which you might try to fix with your Python implementation of Maybe is that Nothing is properly part of the Maybe type, that is, it's a value of type (Maybe a) which isn't just return applied to some value. Here, you're using the constructor for the class as return, but you also get the equivalent of Nothing by applying the constructor to the value None, which is a little odd. I'd also have some reservations with the comment that you need to understand monads to understand Haskell and vice versa. That's sort of true, but it really shouldn't be a difficulty, because you pass back and forth between them in learning. You don't need very much Haskell to understand some simple examples of monads in Haskell (Lists are probably the best example), and you don't need to know all that much about monads to understand most Haskell code. By the way, did you read my article? http://www.haskell.org/hawiki/MonadsAsContainers It takes a rather different perspective on monads than a lot of the tutorials do, and it's one that I've found people new to monads have an easier time with. The point about monads being a design pattern I actually wouldn't take too much exception to, except for the fact that I don't really like the term "design pattern" in the first place. :) Too often, the things people call design patterns are just ordinary functions or general interfaces in a more expressive programming language. In Haskell, you have the Monad class which unifies the use of monads throughout the language, so that you don't end up with the same structures of bind and return and liftM and join over and over on different types. (Which is the point at which I'd think it more reasonable to call it a design pattern.) It started out in programming use as a design pattern, and now it's just a typeclass whose members satisfy some laws. I suppose one could say that the general use of the Monad class is a design pattern, but I'd argue that it's no more a design pattern than the use of the Num class. :) - Cale