4 ms·

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

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.

dkarl 9y ago
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.
- julienfr112 9y ago
  What was your solution with the rookies ? Keep the for expression and fixing bugs, or rewriting them more explicitly ?
  - dkarl 9y ago
    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.
- eklavya 9y ago
  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 :)
- jkabrg 9y ago
  `For` expressions are not boolean blind compared to map/flatmap/filter. (Boolean blindness: https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ https://existentialtype.wordpress.com/2011/03/15/boolean-bli...) That might be an advantage.
- runT1ME 9y ago
  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).
mdpopescu 9y ago
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.

dkarl 9y ago

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.

julienfr112 9y ago
What was your solution with the rookies ? Keep the for expression and fixing bugs, or rewriting them more explicitly ?
- dkarl 9y ago
  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.
eklavya 9y ago
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 :)
jkabrg 9y ago
`For` expressions are not boolean blind compared to map/flatmap/filter. (Boolean blindness: https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ https://existentialtype.wordpress.com/2011/03/15/boolean-bli...) That might be an advantage.
runT1ME 9y ago
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).

mdpopescu 9y ago

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.