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 …
-
Show this thread
-
This is the worst when a programmer thinks it makes them look smarter than everyone else. I have zero tolerance for this attitude. It's the path to project failure, and when I have the choice I would terminate that programmer. Sadly few managers understand this.
0 replies 2 retweets 10 likesShow this thread -
This Tweet is unavailable.
-
Replying to @someoneverycoo1 @VaughnVernon
It is also subjective. I once had a team lead that get unhappy with me because I used map, filter, reduce. I honestly felt it wasn't anything complex and make things cleaner
1 reply 0 retweets 0 likes -
Replying to @someoneverycoo1 @SnowPolar
Vaughn Vernon Retweeted Jon Pretty
I saw this very opinionated tweet the other day, which to me read like "my goal is to fit in." I also concluded that his suggested code was obscure. Read the replies and see what the consensus is.https://twitter.com/propensive/status/981805791228387328?s=19 …
Vaughn Vernon added,
2 replies 0 retweets 1 like -
Replying to @VaughnVernon @SnowPolar
Saddest to me is, I have worked on projects where if I don't use these obscure Scala expressions, my code won't pass reviews. This is my biggest turnoff to FP. It's infected w entirely subjective, opinionated complexity. As if any other kind of non-imparative expression is wrong.
2 replies 1 retweet 3 likes -
Replying to @VaughnVernon @SnowPolar
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.
1 reply 0 retweets 0 likes -
Replying to @propensive @SnowPolar
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.
2 replies 0 retweets 0 likes -
Replying to @VaughnVernon @SnowPolar
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.
2 replies 0 retweets 0 likes
But then it comes down to a question of what that style should be. A lot of it is bikeshedding: A match or a fold will both work, and there are advantages to concision as well as explicitness. But consistency is also valuable, which I guess is where the pressure was coming from.
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.