Monads are not as hard as you think - it honestly helps if you stop thinking of them as a completely new concept with a scary name. I'm sure it wouldn't do people learning functional programming any favors to refer to the fold operator as a catamorphism all the time. (The syntax is also pretty funky, at first, with >>= and whatnot.)
I found it most helpful to think of monads as being similar to the pipe operator in Unix, but one that has a hook function it calls as it passes results along.
Also, the IO monad is probably the worst to start with; it's one of the most complicated. The Maybe monad is much simpler -- Think of a function that takes a function, f, and a second function, next_f. It calls f and grabs the result: if it's an error, then don't bother calling next_f, just return the error; otherwise, call next_f with the result as its argument. You can chain a bunch of Maybes together, and if any of them return an error, the whole chain immediately passes the error to the end. It's like how || (or) short-circuits in other languages, but much more general.
A similar Countdown monad could start with a time and a list of functions to call, then call them in succession, passing along the results, but immediately aborting and returning an error if the chain has exceeded the specified time to run.
The monad is the chaining construct, but you define what it does with the results it passes along.
Because of Haskell's type classes, it's able to recognize that any construct that supports that kind of chaining behavior (among other things) is an instance of the same general construct, and is therefore able to work with them in a common way. That's surprisingly useful, much like when an object's class is a Class object that supports various interfaces for interacting with the OO system itself (A "meta-object protocol").
Haskell makes a big deal of monads because it needs them to do some things in a functionally pure manner, of course. Still, they shouldn't be considered some completely alien by-PhDs-for-PhDs concept. (I remember Simon Peyton-Jones saying he wishes he'd instead named monads "warm fuzzy things"... :) )
This is, arguably, the biggest reason to use Monads in the first place, the typeclass thing.
You don't even need Monads to have completely functional IO code. Clean's uniqueness types are another method, but you can actually do it with just plain types if you're dedicated.
I found it most helpful to think of monads as being similar to the pipe operator in Unix, but one that has a hook function it calls as it passes results along.
Also, the IO monad is probably the worst to start with; it's one of the most complicated. The Maybe monad is much simpler -- Think of a function that takes a function, f, and a second function, next_f. It calls f and grabs the result: if it's an error, then don't bother calling next_f, just return the error; otherwise, call next_f with the result as its argument. You can chain a bunch of Maybes together, and if any of them return an error, the whole chain immediately passes the error to the end. It's like how || (or) short-circuits in other languages, but much more general.
A similar Countdown monad could start with a time and a list of functions to call, then call them in succession, passing along the results, but immediately aborting and returning an error if the chain has exceeded the specified time to run.
The monad is the chaining construct, but you define what it does with the results it passes along.