I'm glad I'm not the only one who was scratching their head at seeing FP being taught as the antidote to bad OOP. Scheme was my third language (after BASIC... the kind with line numbers... and COBOL...). The things that people admire about FP that can help reduce bugs and such *can* be done in OOP, or imperative, or any other approach that could come up. Things don't *have to* produce side effects, for example. And FP as a development paradigm is not only very difficult for many (most?) developers to wrap their brains around, but the languages and toolsets and all of the other stuff we use to "get stuff done" is less developed for it. And honestly, FP is great for certain things, but it's absolutely terrible for a lot of other things, which is true of all programming paradigms.

I think the real problem is that, in large part, the world of development turns on people with relatively little experience. People come in and learn whatever is hot at the moment, and then 5 - 10 years later become disaffected when they realize that it isn't suitable 100% of the time to 100% of all situations and their reaction is "let's dump it for some other new hotness".

Between the Java JVM, the .NET CLR, *Nix style piping, and microservices, there is no reason for people to confine themselves to one language or one paradigm; it's perfectly reasonable to compose applications with building blocks where each block is built with the tool that is appropriate for that block's composition.

What's really missing for so many of these teams is someone like you or me (not to toot my own horn) with the experience and perspective to step back from trends and say "hey, I've seen this situation before, let's do X because that is what's best for these kinds of problems" rather than getting caught up in the excitement in something new and the frustration of the old thing, without having experience in something that looks similar to the "something new".

J.Ja