(quote pozorvlak)

[pozorvlak]

I observe to my astonishment that I've made the "Quotes of the Week" section of this week's Haskell Weekly News. Um, gosh.

Now if only I could work out if I've been quoted because dons agrees with me or wishes to hold me up to public ridicule :-)

Comments

[totherme]

Congrats :)

There's a third option of course - he may not know yet whether he agrees or disagrees, but does think it's worth further thought...

[mtbc100]

Your comment seems reasonable to me. You need to be able to use monads in order to use many of the terribly useful libraries available. Also, they're one of the ways to capture some common design patterns, so when you use one other Haskell programmers can easily see what you were up to. (E.g., not reinventing state monads, etc.)

[pozorvlak]

I'd have called that the opposite of a design pattern - to me, a design pattern is a recurring pattern in code that hasn't been abstracted into a function/library/macro/etc. So state monads are an implementation of the design pattern "purely functional code with accumulators".

What you say about libraries was part of what I was getting at, but there's a bit more. I'm having a bit of difficulty putting it into words, though.

[mtbc100]

Ah, I've seen the term used for both the pre- and post-abstraction things: in a sense, I figure that it is there in both. (-: I am not deeply into that world, though, TBH, and what you say makes good sense.

I don't know if it's relavant that monads are kind of a way you can embrace particular programming styles (especially, imperative) where Haskell isn't so much about making you do everything in the traditional functional way so much as letting you do things in various ways but still purely functionally?

[pozorvlak]

Yes, I think that's it. To me, there's a purely-functional sublanguage and a monadic sublanguage. When you're first learning the language, you're pretty much entirely learning the purely-functional bit: recursion, laziness, lists, algebraic data types, typeclasses, folds, maps and so on. The monadic part of the language seems just like an odd little corner. But that corner contains everything about programming that is not purely functional. Hence, to really be an effective Haskell programmer (and, as you say, to take advantage of most of the libraries) you need to break out of the purely-functional jail and learn to use the monadic sublanguage. But you're still not much better off! While you can change the style you use, you're still stuck with at most one - your program can do IO or it can work with probabilities or it can have state or it can do parsing or it can have automatic backtracking or your functions can have possibly-null return values or... If you want to do more than one of these (as you almost certainly will in a

[bronxelf_ag001]

Congratulations. I think.