[Haskell] Everything Your Professor Failed to Tell You About Functional Programming

[Cale Gibbard]

> 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