In my last two blogs on The von Neumann Bottleneck and The Problem with Immutability I was flushing out some thoughts on immutability, side effects and the difference between functional and imperative programming. One thing I continue wrestling with is reconciling "no side effects" with the real world need for side effects. We know that side effects lead to all sorts of problems but how can we eliminate side effects and still be left with useful programs? The answer seems to lie in these magic monads that everyone keeps talking about. So I spent some time skimming some papers on monads. It seems as though I'm late to the party. 2007-2008 was the big year of the monads, when people were comparing them to burritos, elephants and sexual conquests. But I'm always late to the party.
After a day of casual reading I kind of get monads. There's left unit, right unit, type constructor, a bind function and a couple of other goodies. Still a bit abstract since when was the last time a Java programmer like myself ran across an explicit monad. But something still felt off. Philip Wadler writes in "Monads for functional programming"
Monads provide a convenient framework for simulating effect found in other languages, such as global state, exception handling, out-put, or non-determinism
So aren't monads just a neat math trick for keeping things pure when things are in fact full of side effects? That's like me saying my apartment is clean after I shove all my junk in a closet out of sight. No, it's still dirty, you just can't see it anymore.
Then I saw this video of Brian Beckman of Microsoft Research explaining the state monad and I think I'm one step closer to my "ah ha" moment. Sequential programmers (Java, C, etc.) live in a huge ambient monad. In this ambient monad side effects (updates) are allowed. FP forces you to live in smaller monads. Brian Beckman:
In fact there's nothing wrong about side effects at all, it just how disciplined, how precise are you going to be in your use of side effects. If your programming language allows you to update any variable then you can never tell by looking at a variable whether it has been side effected. All Haskell does is discipline the side effects; so if you're doing side effects you have to do them in an explicitly written monad. So now you can tell. The stuff in the monad may have been side effected by whatever function was ahead of you and may be side effected by whatever function is behind you...It's precise in the text of the program. In a programming environment [like c# or vb] you are in am ambient monad so everything is updatable.
OK, this makes a lot more sense now. Side effect is not this horrible, terrible, bad thing you absolutely cannot have (duh), you just need to be precise with it. There's no way to be precise with it in Java or the imperative languages (enforce preciseness), but there is a way to be precise with it in functional languages. Monads make this precision more convenient than passing the world around as was done in the past.
It should be noted that Beckman goes on to say that monads are not a panacea. While reading up on Haskell one question in the back of my mind was how does Haskell do logging? In Java I can do something like System.out.println("the value of x is " + x), but does this mean I have to use the IO monad now to do basic logging? And Beckman points this out as a shortcoming, that to just do a printf you have to rewrite your functions to use monad. I guess that's why there's some "unsafe" IO stuff you can do in Haskell, but as the name implies it's unsafe and the compiler can't guarantee things, as it can with monads.
