Hacker News Reader

Comment by hota_mazi | Hacker News Reader

All the ad hoc solutions look at least as clear if not clearer than their monad equivalents.

Also, that article conveniently ignores that as soon as you start mixing monads, you enter a different kind of hell: monad transformer hell.

Because you see, monads don't compose. Not without these transformers. And if you think the monad examples in that article were hard to follow, wait until you see monad transformers in action.

Also, I don't think replacing a `for` loop with a `for` comprehension is that much of a gain. I'll pick a `map`/`filter`/... any day over such `for` loops.

View on HN

I worked on a Scala system with two rookie Scala programmers who had been taught that `for` expressions were a simple and easy way of composing futures, because it was the monadic way. The code looked very neat, but we had an epidemic of swallowed Failures, and the ones that weren't swallowed were often interpreted incorrectly. (For example, a 500 from service A would be logged as a 500 from service B, because someone miscalculated how the Futures and Trys were being composed.) This was due to people not understanding the for expressions they were writing. Rather, I seemed to be the only one trying to understand the `for` expressions: I often had to mentally (or even manually) translate them into flatmaps and maps according to the language spec to discover that they were not doing what the person who wrote them intended. The other programmers, who had been promised that `for` expressions were obvious and self-explanatory, felt that this should be unnecessary, and that if they were making mistakes, then Scala was failing to live up to its billing, and we should stop using it. It was extremely frustrating. I love Scala, and I feel that promoting `for` expressions to beginners like that was ideologically motivated and bad for the language.

It's much easier to just use map and flatMap. But that won't do, because the virtue of monads is supposedly the abstractions built on top of them.

What was your solution with the rookies ? Keep the for expression and fixing bugs, or rewriting them more explicitly ?

A little bit of both. I kept hoping something would click and I would end up loving the for expressions, but for a few monsters that I could only untangle by translating the code line by line into map, flatMap, and filter, I committed the translations so I would never have to do that again. Neither of the other programmers is writing Scala anymore. I've mostly steered clear of for expressions since then.

If you are writing functional Scala you should be using cats and the ecosystem. Futures are bad for this use case and you should use a proper Effect monad like IO. The for comprehensions will come alive, trust me :)

`For` expressions are not boolean blind compared to map/flatmap/filter. (Boolean blindness: https://existentialtype.wordpress.com/2011/03/15/boolean-bli...)

That might be an advantage.

Have you looked at Scalaz's Task? It's used all over Verizon, it solves a lot of these issues that people run into with Futures (on how it handles errors in a lawful way).

While I am a fan of the few monads I'm using in C# (IEnumerable[T] and Maybe[T] among them), I will admit that composing them is still a black art for me. I haven't been able to find any solutions besides "write specific code for each possible case", which unfortunately grows exponential in the number of different monads.

Reply on news.ycombinator.com