Jon Pretty

Stop using, opt match { case Some(x) => f(x); case None => y } Stop using, http://opt.map (f).getOrElse(y) Use, opt.fold(y)(f) I feel like I'm very late to this party.

I actually kind of disagree. map(f).getOrElse(y) clearly conveys the intent of your code and makes it easy to understand for other people. fold(y)(f) doesn't. In my case at least, I always have to do the mental gymnastic of "oh, this means map.getOrElse"

But wouldn't you say that map...getOrElse is itself halfway between the pattern-match to the fold in terms of clarity? I think the difference is that right now we're much more familiar with maps than folds, especially when the context is an Option.

Honest question though: is that a proper fold? In my mind, fold is heavily linked to monoids: - takes an "empty" value - takes a merge function that's basically a monoidal append This is not what Option.fold does. Am I misunderstanding what fold is?

Your mixing `Foldable` (the typeclass) with the algebraic fold, the later is basically isomorphic to pattern matching. The fact that folding on a List is recursive, is incidental (because the type itself is recursive), not the opposite.

Ah. So then, on the one hand it makes sense, on the other, I feel it might be a fact in favour of my argument: it might be unreasonable (today) to expect most developers to know about algebraic folds, and map(x).getOrElse(y) *will* be more readable for the majority of them

Why is it unreasonable to expect developers to know the basics of their profession? Is it also unreasonable to expect pilots to not know where the throttle is located?