On 02/07/2011 08:16 PM, Warp wrote:
> Orchid XP v8<voi### [at] devnull>  wrote:
>> Currying, not so much. (Other than that it's something people often do,
>> so they use the technical term for it. Rather like inheritance gets
>> mentioned a lot in OO languages, even though it's just a short cut for
>> duplicating code.)
>
>    The difference, to me, is that I understand what inheritance is and why
> it's useful. I can't say the same about currying or monads.

And how long have you been doing object-oriented programming?

When I first tried to learn Haskell, I didn't understand most of this 
stuff either. Much like when I first learned about OOP, it didn't make a 
lot of sense initially. (Of course, I wasn't helped by using a 
programming language with "OOP" splashed all over it which *isn't* 
actually object-oriented, but anyway...)

>    Btw, in the articles mentioned in the original post the example is
> given of making an int "nullable" via a monad (or something along those
> lines). I can't comprehend what this has to do with I/O

Absolutely nothing.

That's arguably the confusing thing about monads. Lots of completely 
different things that look nothing like each other all turn out to be 
monads. Even though this "sameness" is highly non-obvious.

> (or, more precisely,
> I can't understand what this kind-of "inheritance", which is what it looks
> like to me, has to do with I/O), as the I/O monad seems to be one of the
> main concepts of haskell.

The I/O monad is what makes I/O possible in Haskell today. (Previously 
it used a clunky solution with lazy lists which made it very easy to 
accidentally deadlock the entire program. Using a monad is a far 
superior technique.)

But, as pointed out, even in C#, where you don't need a monad at all 
just to do I/O, monads still exist and can still be useful. Because 
monads can do things *other* than just I/O...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message