Not an academic paper, but I found the Roslyn (new C# compiler) whitepaper to be an interesting window into the future of programming languages: <a href="http:&#x2F;&#x2F;www.microsoft.com&#x2F;en-us&#x2F;download&#x2F;details.aspx?id=27744" rel="nofollow">http:&#x2F;&#x2F;www.microsoft.com&#x2F;en-us&#x2F;download&#x2F;details.aspx?id=2774...</a><p>&quot;Tackling the Awkward Squad:
monadic input&#x2F;output, concurrency, exceptions, and
foreign-language calls in Haskell&quot; (<a href="http:&#x2F;&#x2F;research.microsoft.com&#x2F;en-us&#x2F;um&#x2F;people&#x2F;simonpj&#x2F;papers&#x2F;marktoberdorf&#x2F;mark.pdf" rel="nofollow">http:&#x2F;&#x2F;research.microsoft.com&#x2F;en-us&#x2F;um&#x2F;people&#x2F;simonpj&#x2F;papers...</a>) finally made me understand monads. Or rather, why they have such an unreasonable draw on Haskell people. tl;dr: Monads are useful to thread data (state, side effects, ...) through a computation, without modifying all your function signatures (the functions can be lifted to work with the monad). But mostly, it turns out you NEED monads (or something like it) to sequence side-effects (since Haskell is lazy).