On Fri, Aug 6, 2010 at 9:17 AM, aditya siram
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: http://www.haskell.org/haskellwiki/Why_Haskell_just_works 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! --Jonathan