[Haskell-cafe] Suggestions For An Intro To Monads Talk.

Jonathan Geddes geddes.jonathan at gmail.com
Fri Aug 6 15:43:03 EDT 2010

On Fri, Aug 6, 2010 at 9:17 AM, aditya siram <aditya.siram at gmail.com> wrote:
> Upon further reflection I realized that my audience is more pragmatic than theoretical. Instead of emphasizing how monads are constructed and the monad laws I think I want to dive right into the most common and useful monads. From my vantage point they are (in no particular order) : Reader, Writer, State, IO, ST, STM, Parsec (have I missed any?) and of course the transformer versions. I am debating whether or not to add [] to the bunch.

If your audience is indeed a pragmatic lot then they will not be
interested in the same things as a more theoretical crowd (obviously).
So they might not be interested in Monads at all. You've got your work
cut out for you!
With that said, I would suggest starting with the advantages of
purity. I would guess that 95% of bugs in imperative code are related
to some erroneous state. Pure code, on the other hand is immune to
this huge class of bugs. Sometimes state is useful or even necessary
(stateful computations, IO, in-place algorithms, etc), so you really
can't forgo state entirely. The cool thing about Monads is they allow
us to have our cake and eat it too! We can model stateful computations
in pure code. You might also mention the separation of pure and impure
code and how this helps us to reason about a program.
> I'm still a little iffy on why the monad concept isn't used in other languages. From where I sit it seems as though monads really let you play with the order of evaluation - just because one statement is executed after another doesn't mean they are executed in that order. I think other languages don't make this easy.

My guess would be that other languages have much less commitment to
purity. You don't need Monads in other languages because state is
implicit, everything is in the IO monad, in a sense. While Monads are
still an excellent abstraction in other languages they're often more
awkward than just using implicit state/IO/whatever operations. Haskell
has some sweet built-in syntax for monads.
Also related to advantages of purity:
I think this approach (stating benefits of purity and maybe laziness)
would be more interesting to a pragmatic crowd. Just a guess though.
Good luck with your presentation!

More information about the Haskell-Cafe mailing list