I don't feel at all that this is true. It is not necessary to understand monads to get good work done in Haskell for basically any purpose. Authoring monads is something usually left to library authors, and for basic users it's just a nifty interface that lets you do handy things in imperative style haskell ('do' syntax).
I don't want to be defensive in this thread, since obviously getting real about deficiencies in Haskell is a great way of making a path for positive change, but the spreading of the idea that monads are magical and hard is dangerous.
It's similar to how back in the day Java and PHP developers dismissed Ruby on Rails for being magical and hard to understand with weird syntax. The truth is that Ruby on Rails was very easy to use regardless of its rather complex innards, and once you get a good handle on Ruby, even the Rails innards weren't all that difficult to understand and extend.
The hard part of learning Haskell is getting to grips with functional style programming and understanding the power of its type system. Learning that is rewarding and has a low entry-barrier, it's even something I'd recommend to someone who has never programmed before. Don't worry about monads.
I think if you don't have the time to learn enough about a language like Haskell to understand how monads work in that language then you are probably better off just not trying to understand them. It is impossible to understand them without having examples.
And yet Zed seems to think he can teach the basis by which Ruby's for ... in works without laying nearly the same amount of groundwork. That's the real question---why do you need to go over so much in so much detail in the one case, but somehow the other is significantly simpler? (Especially if the second is actually syntactic sugar for the first!)
"As a result I don't know when or even if I'll learn Haskell - and it's caused solely by the lack of full, up-front explanation of Haskell I/O model in most (all?) learning materials for the language."
The IO monad is just like the State monad, except you can't get the State back out. You're passing around RealWorld. (In any event the "theoretical grounding of monads" doesn't tell you anything about IO. It would tell you things about monads in general---monadic bind and return and join, etc. Haskell may be doing weird things with its IO monad, but your objection actually bypasses what I was talking about, which is the category theory shee that Haskell is known for, but is also found in, say, Scala, where IO is not done through a special monad.)
ETA: given that these books are apparently for people who might need to be taught about variables in the first place, I wonder how accurate your conception of how like you they are is, and how much that resemblance applies to the case at hand. To reiterate, I can't really understand why any explanation that would pass muster with Zed for adequately explaining how "for foo in bar" works in Ruby, including the binding of the name foo, the repeated execution of the body, etc., couldn't be straightforwardly adapted to "bar.each { |foo| ... }". Would the adaptation not get into the weeds of the .each method? Indeed it would not. But then, the explanation of "for ... each" also didn't get into the weeds of that. Both should be acceptable if either is.
It took me two months to really comprehend monads. Now I find them very intuitive and easy. However, they are definitely not easy to learn. It is like you are learning programming for the first time. Initially, they seem weird. Haskell requires patience. It is not a language where you can jump in and immediately see results, like jumping from C to Python. Someone who starts learning vi might be frustrated too. You need to learn ten keys before it becomes as productive as notepad.
> In Ruby or a similar object oriented language you expect to find three APIs/gems, all with a similar object oriented syntax, but for three Haskell DSLs designed for three different tasks to share syntax implies that their authors failed to optimise them for those tasks, hence instead of five minutes with API documentation you have hours of DSL tutorials ahead of you before you can begin work.
You need to learn monads only once. I can use new monads without any trouble.
Yeah, but if the monads were the only problem it would be ok (for me at least). But I'm asked to learn monads while also learning this weird syntax. I'm asked to learn something I don't understand in a syntax I don't understand. It's a bit too much. Like a math lecture in which, aside from the new concepts, the lecturer has decided to replace the traditional symbols (+,-, etc) with his new and equally arbitrary ones (¤, @). Except, of course, that Haskell's syntax is often more arbitrary than its competitors.
I appreciate these attempts to give non-Haskellers a chance to learn Monads but, personally, I never really grokked them until I got into Haskell. In Haskell, Monads are defined in terms of types, thus languages without type systems like Haskell's make the concept both more difficult to understand and less (immediately) useful. Having been through many of these tutorials myself, I think the best way to get into Monads (as well as many other useful constructs like Functors, Monoids and Monad Transformers) is to roll up your sleeves and learn Haskell (Learn You A Haskell is a great and relatively quick read). As a bonus, you'll also learn one of the most elegant programming languages around.
This comment isn't intended as a knock against the article. I think there's a lot of merit in using monadic constructs in languages that aren't Haskell, I just think Haskell's type system makes understanding the concept easier.
Monads are pretty trivial to understand if you learn some Haskell first, and kind of pointless if you don't. The actual definition of a monad in the Haskell standard library is a dozen lines or so of simple code.
Well, then you came pretty far already. This post is not a tutorial on monads. It’s really his thoughts on why he sees monads are needed in Haskell. (And not needed in, for example, ML.)
Wait. Assuming one does not need or want to learn Haskell, what would then be a purpose of learning about monads?
There seems to be a disproportionate amount of tutorials about monads. Not being able to provide sufficient amount of examples in other languages makes monads seem quite less useful. Maybe next article to write is “why should you learn about monads”.
I don't really have the experience to comment on this issue, but I did try looking at another monad tutorial in Clojure several months ago. I think I kind of got the idea behind monads, but I always thought so what. I have no experience with Haskell. I supposed that may be the reason.
Don't be. The fundamental observation that monad's usability is tied closely to Haskell's features is important, and still hasn't been taken on board elsewhere. There's always someone trying to do monads in Clojure...
I've read lots of monad tutorials. I get it, they're a way of encapsulating side-effects in a pure lazy language.
But Haskell doesn't sink in unless I use on a regular basis. The time that I've felt like I was able to see a light at the end of the tunnel (i.e., that I might be able to be useful enough in Haskell that I could keep using it regularly) was when I simply memorized the expansions for the do, <-, return sugars.
reply