Are you sure it's pointless? Having to show I/O in the type signature means you can't end up with accidental side-effects.
have `unsafePerformIO` in the language.
Speak for yourself. I don't see any value in not using a tool when it's available and seems to do the job:
http://science.raphael.poss.name/haskell-for-ocaml-programme...
Personally I don't believe in 100% pure FP, it's both a pain in the ass and doesn't really give you more than 85% FP already would. Actually, most of the FP world seems to agree: out of many Lisps, Scala, OCaml, SML, F#, Erlang/Elixir etc. only Haskell is that hell-bent on purity. Even things like PureScript are more pragmatic than Haskell in this regard.
Here's a great talk on getting what's best from FP without also taking all the problems: http://www.infoq.com/presentations/functional-pros-cons
How so? Having a pure language has some significant benefits, like laziness. Data structures as control flow is awesome.
Monads are a quite clever solution to control IO: instead of allowing functions to directly perform IO, allow them to compose a sequence of IO operations and return them, such that you can compose a program which the runtime will then execute.
They're not imperative: they represent programs in a purely functional way, and they don't let you opt out of any of the guarantees a purely functional language provides. And they're not a hack, they fit properly into the type system.
Unlike "mostly functional" programming, use of monadic IO in a purely functional language will force you to cleanly separate IO and computation. Not only does this make a more maintainable program (no side effects everywhere), but you get nice bonuses, like lazy computation.
> and most monad tutorials will only confuse you about what they are actually.
Perhaps because many monad tutorials try to hide how they work, despite this really being quite simple.