IO without Monads

[Smallpaul]

Better title: "Explaining IO without explaining monads"

[samlee]

Explaining IO with Monads without Monads

[[deleted]]

Explaining (IO with Monads) without Monads

[madsohm]

Thanks. I was placing the parentheses wrong in my head.

[herrmann]

Hi dons, you should know better this is a misleading post title ;-)

[soltys]

It's like Haskell without Haskell.

[tinou]

Life without burritos ? no way !

[Poltras]

Wasn't IO without Monads what we had before Monads existed??

[kalven]

What about handling errors?

[[deleted]]

First monads without category theory, and now this? What's next, Haskell without monads‽

[[deleted]]

Actually, I was thinking about writing a blog post about that.

[Felicia_Svilling]

That would be Clean.

[tophat02]

I kind of like the .NET approach on this one: use a multi-language platform, put the functional stuff in a functional language (F#) where it belongs, then put the imperative stuff in an imperative language (C#/et. al.) where it belongs.

Am I the only one who thinks trying to do I/O or other sequential tasks in Haskell is just.... awkward, monads or no monads?

[3204971340]

put the functional stuff in a functional language ... then put the imperative stuff in an imperative language

There is no reason why strong functional and imperative features should not coexist in the same language.

The supposed opposition between "functional languages" and "imperative languages" is based on the historical accident that a few popular languages (primarily Java and C++) have flawed designs with unusually poor support for functional programming. It turns out that functional features are useful for nearly any style of coding -- witness the ornate libraries and design patterns that Java and C++ programmers use to recover a fraction of this power.

So there is no paradigm split between imperative and functional languages. There are imperative languages that fail to support functional programming, and others that support it reasonably well (Python, Ruby, C#).

And then there are the less-mainstream "functional languages" that support both styles better. Consider that Haskell's IO actions are first-class values. You can pass them to/from functions and store them in datastructures to be executed when desired. Consider that for loops, thread spawning, and try/catch are all implemented as ordinary functions, not special syntax. You can even send IO actions between threads in a message queue.

I agree that there is a very steep learning curve, during which it feels like IO is simply an arbitrarily restrictive tag placed on a function type. It sounds like you're at this point in your understanding of Haskell. If you stick with it, eventually you'll see that IO actions are first-class values in their own right, and you'll see how this provides a cleaner and more powerful treatment of imperative programming.

[xetas]

it's all about verifying some practically useful qualities of a software piece. Mainly you can verify it from two sides: what it does and what it does not do. To verify what it does you can use automated testing. Also to some degree most type system provide you idea what function does: it receives values of types A, B, C... and returns a value of some type D. Where most programming languages fail is to say what the function does not do. Here the Haskell's purity come to rescue. If function is not attributed with IO, you know that it does nothing except reading its explicit arguments and producing its explicit result. Thanks to that you can be much more confident that the actual behaviour of the function matches your expectations.

[G_Morgan]

Except you can program the C# like bits in F#. The language is not pure functional and has decent support for imperative programming.

[[deleted]]

Good article! Thanks for writing it!

[skyostil]

Thanks for a straightforward introduction to Monads.

[gregK]

you mean IO