Impure languages don't really differ in principle from the more familiar imperative languages, especially now that many functional tricks have been copied. What's different is the style - how you solve problems.
Whether you count Haskell as pure, or count the IO monad as impurity, Haskell style is an extreme form of this style and well worth learning.
The Haskell IO monad is derived from the mathematical theory of (of course) monads. However, for imperative programmers, I think a backwards way of arriving at monads makes more sense.
Phase one - a pure functional language can easily return a big string value as its result. This big string can be the source code of an imperative program, derived in a pure functional way from some requirement-specifying parameters. You can then build a "higher level" compiler that runs your code generator, then automatically feeds that generated code into the imperative language compiler.
Phase two - rather than generating textual source code, you generate a strongly-typed abstract syntax tree. Your imperative-language compiler is absorbed into your "higher level" compiler, and accepts the AST directly as source code. This is a lot closer to what Haskell does.
This is still awkward, though. For example you have two distinct kinds of functions - those evaluated during the code-generating phase and those executed when the generated program is run. It's a bit like the distinction between functions and templates in C++.
So, for phase 3, make the two the same - the same function with the same syntax may be partially evaluated during the "code generation", or fully evaluated, or not evaluated at all. Further, discard all looping construct AST nodes in favor of recursion. In fact, discard the idea of AST nodes as a special kind of data altogether - don't have "literal value" AST nodes, just have values etc.
This is pretty much what the IO monad does - the bind operator is a way of composing "actions" to form programs. It's nothing special - just a function. Many expressions and functions can be evaluated during the "code generation", but those that depend on I/O side-effects must have evaluation delayed until run-time - not by any special rule, but as a natural consequence of the data dependencies in expressions.
Monads in general are just generalisation - they have the same interface, but implement the abstract operations differently, so instead of evaluating to a description of imperative code they evaluate to something else instead. Having the same interface means there are some things you can do to monads without caring which monad, which turns out to be useful.
This description will no doubt make purists heads explode, but to me it explains some of the real reasons why Haskell is interesting. It blurs the boundary between programming and metaprogramming, and uses the tools of functional programming to reinvent imperative programming without needing special syntax.
A criticism I have of C++ templates is that they are a kind of broken pure functional sublanguage in an imperative language - to evaluate the same basic function at compile-time rather than run-time you have to re-implement it using a completely different style of coding. In Haskell, while impurity must be labelled as such in its type, the exact same function may be evaluated both in a meta-programming sense and in a run-time non-meta-programming sense in the same program - there is no hard line between programming and metaprogramming.
That said, there are some metaprogramming things that standard Haskell can't do, basically because types (and maybe a few other things) aren't first-class values. There are language variants that try to address this, though.
A lot of things I've said about Haskell can be applied in impure functional languages - and sometimes even imperative languages. Haskell is different because you have no choice but to take this approach - it basically forces you to learn this style of working. You can "write C in ML", but you can't "write C in Haskell" - at least not without learning what's going on under the hood.
