Der Blog

Quoth Doaitse Swierstra, nevermore,
>  digest.chew.eat.serve.cook.chop.pluck.kill $ chicken
>
> we all have a definite feeling that after applying the functions, the
> original object is no longer available, and the FP view does not feel
> entirely natural.

Yes, that is true. I can sort of see why people might object to the IO
monad in this case, since it explicitly prevents the programmer from
reusing old data. Of course, one might argue that it's not really the
*monad* that prevents it, but the construction of the physical world.
The monad merely prevents us from trying to eat our cake and have it.

Dougal Stanton on haskell-cafe (archive).

For the uninitiated, the dots refer to function composition; in OO notation it would look like chicken.kill().pluck().chop().cook().serve().eat().chew().digest(). The point is that that kind of composition in Haskell implies there are no side effects. Consider:

let chicken = getChicken
in  (chicken, 
    (digest.chew.eat.serve.cook.chop.pluck.kill) chicken)

Here we've taken a chicken, eaten it, and returned the result along with the original chicken — i.e, we eat our chicken and have it. This is what the IO monad stops you from doing, and why composing functions that perform side effects is difficult.

This is perhaps a good introduction to a rather interesting video I also saw linked from haskell-cafe (in fact in the same thread). It's only available in WMV unfortunately (it does come from MS after all).