[Haskell-cafe] IO is a bad example for Monads

Dan Piponi dpiponi at gmail.com
Mon Dec 10 13:44:06 EST 2007

On Dec 10, 2007 4:51 AM, Daniel Fischer <daniel.is.fischer at web.de> wrote:
> Am Montag, 10. Dezember 2007 10:36 schrieb Ketil Malde:
> > Daniel Fischer <daniel.is.fischer at web.de> writes:
> > > Various other people write:
> > > > ... lots of talk about monads and IO ...

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". And I definitely want a better answer than "Haskell I/O
is performed using the IO monad but everyone thinks this is bad so
just wait a few years and someone may write a fancy new nice
combinator library that does exactly what you want". There are
thousands of competing programming languages out there, and there are
dozens that are viable choices for the task I just mentioned. If my
response to their question takes longer than the time it would take to
find another language and implement a solution, then Haskell will
remain a niche language.

Maybe hardened Haskell programmers don't notice these things, but
there's a wall that goes up when Haskell is presented to
non-functional programmers. There are significant barriers for them to
cross (some of them imaginary): there's the infamous type system,
there's the mystique around monads, there's the fear that laziness can
impact performance, the general fear that many ordinary programmers
have about recursion, and so on. Giving people even the slightest
reason to think that there's something weird about opening files or
printing a result is just another brick in that wall, and it's
probably the biggest brick of all.

More information about the Haskell-Cafe mailing list