> I'm also wary of functional programming gurus that tend to over-abstract things and use all the language latest features, making code very hard to read. Want

> I'm also wary of functional programming gurus that tend to over-abstract things and use all the language latest features, making code very hard to read. Wanted to echo this point. I'm a huge FP proponent, and I do believe that liberal use FP paradigms can result in code that's in many ways measurably more expressive and less complex than code that make liberal use of imperative looping, in-place mutation, and inheritance, etc. When I'm coding on my own for side projects, I always strive to use the most elegant and expressive FP constructs I can think of. However, at the end of the day, most of the coding we do is part of a social activity. And in a social setting, familiarity matters. Writing slightly less expressive, more complex code in a way that most people who read it will be already familiar with can result in more productivity in aggregate than writing code that's super expressive and simple but requires everyone reading it to first learn the paradigms/patterns that enabled the code to be written that way, especially in a fast growing startup where people are constantly onboarding into the codebase. Optimizing too much for familiarity can also become detrimental though, in that it results in stagnation and closes the doors to paradigms/patterns that can have an outsized impact on overall productivity compared to their cost in learning/education. The real challenge is striking a good balance between familiarity and expressiveness in the choice of paradigms/patterns to use.