For any aspiring Haskell programmer out there, my advice is to stay away from any blog posts describing Monads using analogies of some kind. The fact is that you do not have to "understand" monads in order to write practical programs that use the IO monad or even something more complicated like Parsec. I've seen too many people stop using Haskell when it's time to start doing something that isn't purely functional because they have been afraid of going to unfamiliar territory.<p>Here's a simple two part exercise that should give you enough of an understanding about the basics of using IO and give you a general idea about monads.<p><pre><code> 1. Write a "guess the number" game
2. Write it without "do" notation, using (>>=)
</code></pre>
That's it. If you're at all like me, this should give you a better start than reading theory about the subject. Now that you have a basic understanding about the practice, it's easier to grok the theory.<p>And even if you do not understand the theoretical aspects of it by now, you know enough IO to be able to read and write files, connect to the internet using sockets or do some HTTP requests. That opens a lot of possibilities.
The first two monad papers, "You could have invented monads" and "Monadic Parsing in Haskell", are terrific.<p>I think that monads and most monad tutorials are great examples of "this concept is hard because everyone says it is." It reminds me of engineering school, where a lot of people sit around and complain about how hard something is <i>instead of actually trying to do that particular thing.</i> Monads really aren't super difficult to grasp, and I wish people would stop making tutorials that only serve to confuse learners more.
> none of them clearly explain how lenses work<p>I had taken a stab at this with my lens tutorial[1]. But if you just want to use lenses, Joseph Abrahamson's posts[2][3] are much better. And of course, SPJ's talk is great. He's an excellent public speaker.<p>> I'm really disappointed that so many critical Haskell topics only have a single source of truth that is difficult to find.<p>I found the same thing when I started learning Haskell a few years ago, so I started a blog on advanced topics[4]. Since then there have been a <i>lot</i> of excellent haskell posts. In particular, Stephen Diehl[5] and Christopher Done[6] write interesting and easy-to-read posts. The School of Haskell[7] also has advanced, interactive posts by very smart Haskell folks. So this problem is not as dire as this post makes it sound.<p>[1] <a href="http://adit.io/posts/2013-07-22-lenses-in-pictures.html" rel="nofollow">http://adit.io/posts/2013-07-22-lenses-in-pictures.html</a><p>[2] <a href="https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/basic-lensing" rel="nofollow">https://www.fpcomplete.com/school/to-infinity-and-beyond/pic...</a><p>[3] <a href="https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial" rel="nofollow">https://www.fpcomplete.com/school/to-infinity-and-beyond/pic...</a><p>[4] adit.io<p>[5] stephendiehl.com<p>[6] chrisdone.com<p>[7] fpcomplete.com/school
I think that monads are hard for non-functional programmers to grasp for two reasons: They take a different way of thinking, and "monad" is the wrong name.<p>"The name is wrong?" the Haskell crowd replies. "Not at all! Look at the function signatures, and look at the definition of a monad in abstract algebra! It <i>is</i> a monad!"<p>Well, any function with the signature a -> a -> a is a magma (per abstract algebra), and those are all over the place in Haskell. But we don't hear much about magmas in Haskell. We <i>do</i> hear a lot about monads. Why? Because monads are magic in Haskell, and magmas are not.<p>But here's the thing. Monads are magic for reasons that have to do with programming in Haskell, but that really don't have much to do with abstract algebra. <i>That's</i> why it's a bad name. It's like I told you that something was "an enumerable set of bricks" rather than "it's a three bedroom house". "An enumerable set of bricks" is in fact an accurate description, but it is not a useful one.
An introduction to type-level programming should also be on the list, I think—but there are no great blog posts yet about newer type-system extensions in GHC, as far as I'm aware.<p>You can find some good posts on older techniques and features (phantom types, GADTs), but there's not much out there introducing type families other than material riffing on the papers that introduced them. (The papers are usually quite readable, with well chosen examples, but ...)<p>For example, there's almost nothing beyond the docs about the tweaks in GHC 7.6–7.8 that make doing computation at the type-level easier. Different type-system extensions can get you many of the same places (e.g., GADTs v. type families, particularly the new closed variety), and I haven't seen much advice about when to prefer one variation to another (hint: it usually helps to think about type-function injectivity/non-injectivity and definitional openness/closedness).<p>Richard Eisenberg's blog [0] might be the best source of insights on this stuff right now, but as a researcher he's often out closer to the bleeding edge than best suits a beginning type-level hacker.<p>-----<p>Another topic with poor coverage: Template Haskell.<p>----<p>Roman Cheplyaka's post about monad transformers [1] is one of my favorites, by the way. More code than prose, and it's not a from-the-ground-up tutorial, but if you understand the examples, you will understand transformers and why they are actually useful in real-world code.<p>----<p>0. <a href="http://typesandkinds.wordpress.com/" rel="nofollow">http://typesandkinds.wordpress.com/</a><p>1. <a href="http://ro-che.info/articles/2012-01-02-composing-monads.html" rel="nofollow">http://ro-che.info/articles/2012-01-02-composing-monads.html</a>
Simon Peyton Jones took a stab [sic] at explaining lenses in a down-to-earth way<p><a href="https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation" rel="nofollow">https://skillsmatter.com/skillscasts/4251-lenses-composition...</a> (log in to view)
Good post - I book marked this. As a scala dev, I find higher kinded types hard to approach and find practical uses. I'd like to get into haskell just to improve my ability to work in functional programming in the industry as a scala developer. This post was much appreciated.