On Dec 10, 2007 1:44 PM, Dan Piponi <
dpiponi@gmail.com> wrote:
When someone comes to me and says "I have this Python script that
scans through these directories and finds the files that meet these
criteria and generates a report based on this template, could I do it
better in Haskell?" it'd be good to have a better answer than "to do
this you could use the IO monad, but to do things properly you need to
understand monads so here, learn about the List monad and the Maybe
monad first, understand how this interface abstracts from both, come
back when you've finished that, and then I'll tell you how to read and
write files".
I thought your blog post about the IO monad for people who don't care about monads (yet) was a pretty good start.
As it happens, the IO monad was one of the things that attracted me to Haskell. When I was learning SML in college, I wondered how one could do I/O in a functional style. SML provides I/O via functions with side-effects, which struck me as crude and contrary to the functional style.
Years later, I encountered Haskell and learned that it handled I/O tasks using something called the "IO monad". I had no idea what a monad was, but I understood the implications: Haskell could be referentially transparent *and* do I/O. This was what inspired me to learn the language.
As I learned more Haskell, I discovered the other monads and the Monad class and the full generality of the "do" notation. Eventually, a light came on and monads suddenly made sense.
I don't know if it's best to learn the IO monad before or after other monads. I suspect no choice is right for everyone. An experienced programmer who is new to Haskell is going to have different questions than a beginning programmer with no preconceived notions.