And the reason you can't write "Hello world" in Haskell without using a monad is that functions in Haskell are "pure", meaning they cannot have side effects like outputting to the console.

Preventing side effects, including reading and writing global state, helps prevent bugs and makes it easier to understand and refactor Haskell code. Some would argue that the extra layers of abstraction from category theory and unpredictable order and number of lazy evaluations can actually make it harder to understand and refactor Haskell code.

Anyway, in order to perform I/O in Haskell, you evaluate your pure functions as a sequence of actions that are executed by the Haskell runtime. The construct that helps you build the sequence of I/O actions and allows you to bind their intermediate values to arguments to be used by subsequent actions is called the 'IO' monad.

While it's true that `IO` in Haskell has a `Monad` instance, you don't really have to know that to do `IO` in Haskell. Certainly you don't need to know `Monad` in the abstract to use `IO` concretely.

I like Haskell's `do` notation, which is its syntax sugar for monads, but it's really not that bad without. For example:

    do name <- getLine
       putStrLn ("Hello " ++ name)

isn't really that much nicer than:

    getLine >>= \name-> putStrLn ("Hello " ++ name)

or even:

    getLine >>= \name->
    putStrLn ("Hello " ++ name)

The main reason that monads are important in Haskell is that programs that do IO simply are not functions in a mathematical sense. If Haskell were limited to functions, it wouldn't be able to do IO.