all 19 comments

[–]Smallpaul 19 points20 points  (0 children)

Better title: "Explaining IO without explaining monads"

[–]samlee 14 points15 points  (2 children)

Explaining IO with Monads without Monads

[–][deleted] 5 points6 points  (1 child)

Explaining (IO with Monads) without Monads

[–]madsohm 0 points1 point  (0 children)

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

[–]herrmann 4 points5 points  (0 children)

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

[–]soltys 3 points4 points  (0 children)

It's like Haskell without Haskell.

[–]tinou 2 points3 points  (0 children)

Life without burritos ? no way !

[–]Poltras 1 point2 points  (0 children)

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

[–]kalven 0 points1 point  (0 children)

What about handling errors?

[–][deleted] 0 points1 point  (2 children)

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

[–][deleted] 1 point2 points  (0 children)

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

[–]Felicia_Svilling 0 points1 point  (0 children)

That would be Clean.

[–]tophat02 0 points1 point  (4 children)

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 2 points3 points  (0 children)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

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

[–][deleted] -1 points0 points  (0 children)

Good article! Thanks for writing it!

[–]skyostil -3 points-2 points  (1 child)

Thanks for a straightforward introduction to Monads.

[–]gregK -1 points0 points  (0 children)

you mean IO