There are several kinds of FP: There's FP as in, it isn't horrid C++/Java class-making with virtual functions and constructor boilerplate. There's FP as in, h

There are several kinds of FP: There's FP as in, it isn't horrid C++/Java class-making with virtual functions and constructor boilerplate. There's FP as in, hey we've got lambdas and are doing stuff with them (like chaining callbacks or using futures). There's FP as in, a language that materially inhibits your ability to be non-explicit about what your code is doing. So it might be good to be aware of what mechanisms by which FP provides a benefit. Much of it is, it's not horrid class-making and workarounds to do basic stuff the language should support. It's just half-decent language design. But then there's the matter of being materially or somewhat culturally being explicit about side effects. And these are two different aspects. And many devs don't get the latter. They're kind of smart-sounding words and they'll agree with them if you say it, but they don't really get it. And among people who don't really get it, there's also the FP people who cargo-cult it. I'm talking about the people that rewrite their for loops in terms of map/reduce/std::transform or what-have-you, because they're crazy people unwilling to make mutable local variables. (Kind of like how some will never make a function-local goto statement.)