3 ms·

> Monads are already overused and misunderstood- using them in C++ templates just makes things worse. Where are they overused?

by Peaker 15y ago

Hemospectrum 15y ago
In Haskell, mostly. This is probably because most Haskell programmers learned about monads without understanding applicative functors, which are more general and a much better fit for a lot of tasks.
Rusky 15y ago
They are an overly-specific interface to what can usually be done with applicative functors or even just functors. This trend originated with Haskell and then when people who learned monads without understanding the other (often better) abstractions spread them everywhere else, we got things like this article. Using monads, especially in a language like C++ templates or Scala, but also in Haskell, can overcomplicate things and make things longer than if you just solved the problem the direct way. -- As an example of where monads are overused, look at the Maybe/Option type. I've read several articles that advocate using bind and/or Haskell's do-notation to move a string of null checks out of the main program. This is great, but it's much more easily and expressively done with applicative functors. Instead of assigning all the intermediate results to names, you can just do someFunction <$> Just 3 <*> Just "Something" and it looks like regular function application. Because Applicative is a more general interface that Monad, it also has the plus of working with more types.
- Peaker 15y ago
  I agree that Applicative should be used when possible. I think the Maybe example may be wrong, though. You may need the power of Monads sometimes. If you have a function that requires the result of a different function which was wrapped in Maybe, Applicative will not be enough. Example: xmlChild :: String -> Element -> Maybe Element Now you might want to do something like: myPath = xmlChild "a" >=> xmlChild "b" >=> xmlChild "c"

> Monads are already overused and misunderstood- using them in C++ templates just makes things worse. Where are they overused?

by Peaker 15y ago

> Monads are already overused and misunderstood- using them in C++ templates just makes things worse. Where are they overused?

Hemospectrum 15y ago

In Haskell, mostly. This is probably because most Haskell programmers learned about monads without understanding applicative functors, which are more general and a much better fit for a lot of tasks.

Rusky 15y ago

They are an overly-specific interface to what can usually be done with applicative functors or even just functors. This trend originated with Haskell and then when people who learned monads without understanding the other (often better) abstractions spread them everywhere else, we got things like this article. Using monads, especially in a language like C++ templates or Scala, but also in Haskell, can overcomplicate things and make things longer than if you just solved the problem the direct way. -- As an example of where monads are overused, look at the Maybe/Option type. I've read several articles that advocate using bind and/or Haskell's do-notation to move a string of null checks out of the main program. This is great, but it's much more easily and expressively done with applicative functors. Instead of assigning all the intermediate results to names, you can just do someFunction <$> Just 3 <*> Just "Something" and it looks like regular function application. Because Applicative is a more general interface that Monad, it also has the plus of working with more types.

Peaker 15y ago
I agree that Applicative should be used when possible. I think the Maybe example may be wrong, though. You may need the power of Monads sometimes. If you have a function that requires the result of a different function which was wrapped in Maybe, Applicative will not be enough. Example: xmlChild :: String -> Element -> Maybe Element Now you might want to do something like: myPath = xmlChild "a" >=> xmlChild "b" >=> xmlChild "c"