4 ms·

I think parsers are a decent way to introduce monads, and I really like the way Graham Hutton's Programming Haskell does it, by demonstrating parsing without ev

I think parsers are a decent way to introduce monads, and I really like the way Graham Hutton's Programming Haskell does it, by demonstrating parsing without even using the word monad, and then in a later chapter on IO, saying "oh hey and this thing is called a monad and we used it once before!" And I disagree a bit about RWH... I'm in the middle of it now I think it's great, filled with meaty examples that aren't too complicated at all and are generally pretty concrete. Maybe I'm just not far enough in yet? There are bits where it goes off into the weeds (the chapter on JSON goes so far as to fiddle about with character encoding IIRC) but I just can't imagine a PragProg book could do much better, without sacrificing depth.

boothead 14y ago
I actually find parsing to be a better example of Applicative than Monad.
T_S_ 14y ago
Hutton's book is excellent (and thin!). Work through that and you will learn about some deep stuff without even realizing it.
- paulcc 14y ago
  I agree, and it's the one I recommend for experienced programmers. It has a K&R-like succinctness and clarity. That said, it is about programming in Haskell and not about programming with Haskell; hence this series of articles where I try to look at the wider picture and some pragmatic issues.
  - gtani 14y ago
    Simon Thompson's text (3rd ed) is also a good learning text. It was updated in 3rd ed for GHC
Evbn 14y ago
RWH is way obsolete. Its own authors have written libraries that deprecate the ones they recommend in the book.
lobster_johnson 14y ago
The problem is that RWH teaches Haskell with "real world" examples that actually do useful stuff (such as the JSON chapter), and high-level theoretical concepts such as functors and monads are subtle and complicated enough, especially for FP newbies, that they need to be taught from first principles, not by wading into the deep end by showing a real-world implementation of a parser. Personally, my "eureka" moment was reading the "IO Inside" [1] page on the Haskell wiki, which explains the IO monad in a way that made it click for me, as a imperatively-trained programmer. You can think of the IO monad as a way to force a compile-time dependency between I/O operations by having each IO-performing function take a "baton" value (the "IO" instance) as an argument, as well as return it. The explanation of how Haskell retains the appearance of purity in the face of impure I/O by passing an instance of RealWorld around is genius. That's a brilliant way to start out explaining monads, and it's something simple that you can use to explain the other monads such as the state monad (which the IO monad is built on). I haven't tried the Hutton book yet. [1] http://www.haskell.org/haskellwiki/IO_inside http://www.haskell.org/haskellwiki/IO_inside
- deleted 14y ago
  [deleted]

boothead 14y ago

I actually find parsing to be a better example of Applicative than Monad.

T_S_ 14y ago

Hutton's book is excellent (and thin!). Work through that and you will learn about some deep stuff without even realizing it.

paulcc 14y ago
I agree, and it's the one I recommend for experienced programmers. It has a K&R-like succinctness and clarity. That said, it is about programming in Haskell and not about programming with Haskell; hence this series of articles where I try to look at the wider picture and some pragmatic issues.
- gtani 14y ago
  Simon Thompson's text (3rd ed) is also a good learning text. It was updated in 3rd ed for GHC

Evbn 14y ago

RWH is way obsolete. Its own authors have written libraries that deprecate the ones they recommend in the book.

lobster_johnson 14y ago

The problem is that RWH teaches Haskell with "real world" examples that actually do useful stuff (such as the JSON chapter), and high-level theoretical concepts such as functors and monads are subtle and complicated enough, especially for FP newbies, that they need to be taught from first principles, not by wading into the deep end by showing a real-world implementation of a parser. Personally, my "eureka" moment was reading the "IO Inside" [1] page on the Haskell wiki, which explains the IO monad in a way that made it click for me, as a imperatively-trained programmer. You can think of the IO monad as a way to force a compile-time dependency between I/O operations by having each IO-performing function take a "baton" value (the "IO" instance) as an argument, as well as return it. The explanation of how Haskell retains the appearance of purity in the face of impure I/O by passing an instance of RealWorld around is genius. That's a brilliant way to start out explaining monads, and it's something simple that you can use to explain the other monads such as the state monad (which the IO monad is built on). I haven't tried the Hutton book yet. [1] http://www.haskell.org/haskellwiki/IO_inside http://www.haskell.org/haskellwiki/IO_inside

deleted 14y ago
[deleted]