Minus the formal calculus, I've been saying this for ages. Programmers invent their own complexity, which is always unnecessary, and often accidental. But accidental is because they don't understand the problem well enough.https://twitter.com/garybernhardt/status/982823194846420992?s=19 …
I think that obscurity can be subjective too, though. I can't speak for your code reviews, but developers often extrapolate from their experience and try to overgeneralize it with what appears to be unwarranted conviction to anyone else. I think that's quite common in FP.
-
-
To be explicit, if I write the following, it is wrong, "not FP enough": val a = o match { case Some(x) => f(x); case None => y } I must refactor to this: val a = o.fold(y)(f) I've been told that if-else *expressions* and getOrElse() should be removed from lang/lib.
-
You mean *someone* thinks its wrong... But I think it's useful for projects to have a "house style". FP sometimes presents a few ways of doing the same thing, and it's easier for someone new to understand the code if everyone on the team uses the same style.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.