> junior devs

mostly don't make architectural decisions. It's a bit easy to keep on blaming "junior devs". Who keeps on hyping up and marketing useless stuffs ? that's not "junior devs", that's big consultancies that want to sell their crappy services, that's PAAS that want to sell more servers, that's vendors that want to sell more useless stuff. Enough with blaming "junior devs". Junior devs don't lead teams and have very little say when it comes to architectural choices, they don't contract this or that consultancy, they don't decide whether a business will run on Amazon or Azure. Junior devs didn't invent NoSQL, Microservices, "Serveless" and all that bullshit. Well established players sell these services to others, and the people who drink the kool-aid are managers, not junior devs.

Do you really think "junior devs" want to maintain 50 micro servers just because it's trendy? when they could get away with a single one?

Objects are merely collections of partially-applied functions (or often procedures): methods are bound to `this` aka `self`, the instance. When you have a language where partial function application (currying) is a norm, you have little trouble implementing this approach.

What made OOP popular, things like good modularity and hiding of implementation details, has little to do with the "inheritance + encapsulation + polymorphism" trio proper. They can be and often are achieved without these.

What makes FP powerful is higher-order functions / function composition, immutable data / pure functions / referential transparency, and isolation of effects. Technically, all of these are easily available in most popular OO languages, and you can reap many benefits of FP writing in C#, Python, or even Java 8. But the standard libraries of most of them actively resist such usage, and the translators do not rely on the functional features heavily for optimization.

Where pure FP has trouble is e.g. large mutable structures with constant small mutations, like editing a bitmap in a paint program. Real-time stuff can also be harder, because the shape of the machine code is much less obvious than when using a lowest-possible-level language like C.

Since the real world is inherently effectful, there will always be a mix of approaches. Pick the right tool for the job; a job of any serious complexity will likely require multiple different tools.

I can only think of a couple examples: data structures and some APIs.

I love both FP and OOP and especially love using them together. I honestly don't get these arguments.

Whether data structures should be objects rather than primitives depends very much on the data.

Another possibility: senior dev / architect wants to try it on a relatively small project, as a pilot to get a better feel for how it works and where it might be useful. Sure it might cause headaches and extra cost on that one project, but the knowledge gained might be worth it. The resulting blog posts are either public dissemination of that knowledge, or griping by people who either aren't interested in that big picture or who think the cost/benefit call was made incorrectly.

A guy with 30 years of experience that has only exposure to imperative programming, and never really learned OOP, networking, functional programming (it's not new: lisp, scheme, haskell, etc. have been around for decades), never really learned about operating systems, never really cared about automation, testing... unless you work on implementing software at a low level, which is very rare these days... guess what, that guy has a lot to learn from a fresher engineer, or engineers that actually cared about learning.

Since you brought up functional programming, it actually fits the same framework.

In that case P includes problems with a "pure" domain (e.g. compilers) or problems that require lots of multi-threading.

It does not work well for problems that are fundamentally state-full or sequential. It also does not work in "messy" domains - e.g. data mungling.

Someone who is biased towards "getting job done" and seeing technology adoption as a mere distraction, is simply too biased to be of any help during decision making. When evaluating technology adoption, you need to see the pros and cons (including adoption costs), and evaluate things seriously.

I think it's junior ones who lack understanding of how is OS and networks are operating, as they don't needed most of the time in more popular industries (mobile development, web, etc).

source: by the chance I conducted few interviews for software engineers and devops in web industry - and instead of fizzbuzz I started with asking what's the difference between TCP and UDP. Results will surprise you (also too many people want to exploit current hiring system by just cramming algorithms).