Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

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.

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.

    1. Write a "guess the number" game
    2. Write it without "do" notation, using (>>=)

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.

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.

I've found these Haskell slides useful: http://dev.stephendiehl.com/hask/

The slides suggest an "Eightfold Path to Monad Satori":

1) Don't read the monad tutorials. 2) No really, don't read the monad tutorials. 3) Learn about Haskell types. 4) Learn what a typeclass is. 5) Read the Typeclassopedia. 6) Read the monad definitions. 7) Use monads in real code. 8) Don't write monad-analogy tutorials.

I've found this advice helpful. Monads are something you'd probably invent yourself once you know the rest of the language well enough.

> Monads are something you'd probably invent yourself once you know the rest of the language well enough.

Very true. I understood monads far better after I wrote some explicitly state-threaded code (where every function took a state and returned (state, actual_return)), wrote functions equivalent to >>= and return, and then turned the result into a monad.

Better yet, isn't that what the State Monad[1] is doing internally?

[1]: http://www.haskell.org/haskellwiki/State_Monad

Lots of great Haskell material on his site. In particular this derivation of the State monad from first principles was the "Aha!" moment for me understanding monads.

http://dev.stephendiehl.com/begin/index.html#monads

Some Haskell essentials...

Easy to parse online book: http://learnyouahaskell.com/chapters

Rapid search engine of the Haskell lang and libs: http://www.haskell.org/hoogle/

Common f*ckups, useful if you're coming from an imperative world especially: http://www.haskell.org/haskellwiki/Common_Misunderstandings

Cheat sheet of operators and notation: http://www.imada.sdu.dk/~rolf/Edu/DM22/F06/haskell-operatore...

The 'Monad tutorial' linked in the article doesn't use analogies. Instead, it takes you through a couple of pieces of code that have an obvious abstraction, then shows you that these abstractions are all the same, and that this abstraction is called Monad. It's really very good, you should read it.

If anyone reading this wants to see what a basic "guess the number"-style game looks like in Haskell, I wrote one with the same basic logic, but a ton of different coding styles as well as java code that implements the same logic. https://gist.github.com/cleichner/6086604

Note: As you go farther down the page, the techniques become increasingly overkill for a program this small. For this sort of program, I actually like RandomProblem2.hs the most.

Write a "guess the number" game

There are plenty of learning materials to get to that point. There are probably a few papers on writing GTA5 and World of Warcraft too. Unfortunately, almost no-one is writing about how to do Tetris, Mario or Wolfenstein 3D.

I suspect one of the biggest barriers to adoption that Haskell specifically has is the gaping void in intermediate-level material. When the concepts are so alien to what most programmers work with, even those with some basic knowledge of functional programming ideas more generally, you really need the books or websites that come after things like RWH or LYAHFGG -- things that show how to build non-trivial software, scaling up the toy examples to something more realistic.

It's great to see sites like the one that started this discussion trying to bridge that gap, but I suggest that understanding relatively obscure things like heavyweight parsing frameworks or lenses isn't the most important goal. While they are certainly interesting ideas, this feels like trying to teach people how to write a chess AI with an 1800 rating. When you're just trying out a new language to get a feel for how it works, writing Tetris is probably a better bet.

hell i love me some monads! might just create a language that's pure monadic. (name it FANB (Fortran_a_new_beginning) and it'll have hookers and blackjack! in fact, forget the blackjack)

wow... i had no idea that there was so little sense of humor here. well, i guess i've learned my lesson.

Reply on news.ycombinator.com