Maybe Monads Might Not Matter

http://gbracha.blogspot.com/2011/01/maybe-monads-might-not-matter.html

by DanielRibeiro • 15 years ago

24 18 15 years ago

gbracha.blogspot.com

kenjackson• 15 years ago

This author seems to make several mistakes.

First believing that async calls to actors with side effects helps reasoning.

Second he conflates Haskells exposure of monads with the math of monads. Haskell just makes more explicit (and provable) what other systems indirectly model (often times muddling the ability to reason over it).

ghc• 15 years ago

This post is full of spurious reasoning. Haskell's monads are mainly (ignoring the specifics of IO) syntactic sugar for a series of lambdas akin to a series of asynchronous functions linked via callbacks. While I get that this can be hard to grok given the magic of the syntax, it has nothing to do with the difficulty of monads in math.

jimmyjazz142• 15 years ago

do notation (in Haskell) is syntactic sugar, monads themselves are not.

cageface2• 15 years ago

Sometimes it really amazes me just how far out of touch with the mainstream people in the FP community can be. Any concept that the elite struggle with as much as monads simply has no place in the working programmer's toolbox. Haskell is a wonderful research language. It and its ilk will never be bread & butter.

nopassrecover2• 15 years ago

The same could be said originally for generics and lambdas which have become increasingly common elements of programming. Complex ideas can yield powerfully simple and useful implementations.

forkandwait• 15 years ago

I would say about one out fifty (2%) of bread and butter programmers can actually figure out how to pass an anonymous function as a parameter to another function. Granted, those 2% are probably a lot more important than the other 48%, but I don't think lambdas are actually common...

Also, if one of those 2% have to write code understood by the other 48%, they probably shouldn't use a ton of anonymous functions (or generics, whatever they are).

cageface2• 15 years ago

FP research has contributed many valuable ideas to the programming mainstream. However, after watching entire rooms full of top 5% programmers scratching their heads in bafflement over explanations of monads I very much doubt monads will earn this distinction, at least not in any kind of explicit use.

jimmyjazz142• 15 years ago

Plenty of "the elite" find monads quite common place and use them effectively for real mainstream programming every day.

I might say people in the FP world are much more in touch with the future of programming then most. Languages like Haskell are solving problems (elegantly) that many mainstream programmers have not yet come across but they will.

ekidd• 15 years ago

If you're designing a programming language, and you're planning to include monads solely for the sake of IO, the author has a point: Monads are a very complex way to perform IO, and you're better off with a simpler abstraction.

But monads are good for dozens of other things, including Bayesian inference[1], computation with optional values, list comprehensions, software transactional memory, quantum mechanics[2] and (to geek out a bit) anything that involves defining a lambda-calculus analog over a topos. Any time your problem domain includes a bunch of hairy matrix math, there may be a lovely, intuitive formulation using monads.

Now, if you're never programmed in Haskell, or if you've stuck to the IO monad, you may not understand why monads are a powerful way to tackle certain kinds of problems. But if you've never used monads in anger, how do you whether or not they're a useful tool?

If you want a relatively programmer-friendly language that supports monads, check out Scala's 'for' loop. It looks like a list comprehension, but it gives you about 90% of what you want from monads in practice.

[1] Here's an article I wrote on probabilistic programming with monads: http://www.randomhacks.net/articles/2007/02/22/bayes-rule-an...

[2] Here's a much cooler article on quantum mechanics with monads: http://blog.sigfpe.com/2007/03/monads-vector-spaces-and-quan...

aristidb• 15 years ago

There's an often-discussed (hypothetical) extension to Haskell's list comprehensions called Monad comprehensions. I suppose that would be similar to Scala's "'for' loop".

But really, the difference between 'do' notation and a syntax based on list comprehensions is not that big.

Compare:

[(x, y) | x <- [1 .. 10], y <- [1 .. 10]]

do { x <- [1 .. 10]; y <- [1 .. 10]; return (x,y) }

The main difference is that it uses return (which is implicit in the comprehension syntax), and the final element in the do syntax is pushed into the first position in comprehension syntax.

(Another alternative would be liftA2 (,) [1 .. 10] [1 .. 10].)

MichaelGG2• 15 years ago

I've found monads in programming languages to be a lot easier to understand than the myriad "guides" that explain them in obtuse ways.

cmars232• 15 years ago

As one who has dabbled with Haskell a bit here and there, "programmable semicolon" is the most apt metaphor I've seen.

Every time I have to break up a chain of method calls in Java with several lines of ternary null checks, I think about the Maybe monad.

Maybe Monads Might Not Matter

Related Stories