Jon Pretty

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.

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.

The fact that these discussions end up nitpicking on these details of different ways to encode a piece of logic is sad. And is a big reason (in my experience) why ppl shy away from Scala. Use the style that ensures the best readability in a given context.

There was no proclaimed style, just knee-jerk opinion. One day I will write a blog post about this spectacular failure, why I was brought in, and why my marching orders were sidetracked within days of arrival due to consulting partner end-arounds.

marching orders?

#LMGTFY https://www.merriam-webster.com/dictionary/marching%20orders …

Sad to hear you got it, hope you are in a better place now