When you're doing functional programming you represent (almost) everything as a value. Say you're working in a concurrent system, (e.g. a web app) so you're dealing with Futures everywhere. Are you going to write 4 or 5 nested flatMaps? It's unreadable. For comprehensions are much easier to parse. Here's an example from real shipping code
for {
perm <- loginActions.mandatoryAuth(req)
queryString <- req.mandatoryParam[String](uuidParam).toClientProblem.fv
user <- stringToUser(cache.user, queryString).fv
result <- actions.user(Read(perm, user))
} yield result
Then you get into nested monads (e.g. Either can represent a computation that succeeds or fails, which you want to contain inside a Future) and you use monad transformers to squish them into one single monad, to avoid nesting for comprehensions.
Comments
When you're doing functional programming you represent (almost) everything as a value. Say you're working in a concurrent system, (e.g. a web app) so you're dealing with Futures everywhere. Are you going to write 4 or 5 nested flatMaps? It's unreadable. For comprehensions are much easier to parse. Here's an example from real shipping code
Then you get into nested monads (e.g. Either can represent a computation that succeeds or fails, which you want to contain inside a Future) and you use monad transformers to squish them into one single monad, to avoid nesting for comprehensions.