We choose the right tool the same way a painter chooses among oil paint, watercolor, etc. Step back and look at the subject, and think how well each type of paint would represent it. Also consider one's own skill with each type of paint, one's interest in exploring new paints, and the cost of obtaining and storing another kind of paint.
Right -- this is exactly the kind of language that turns people off. It is a vague analogy with no practical advice that compares the act of programming to the art of a skilled painter, giving a field that strives to have the restraint and responsibility of engineering a sort of weird "you have to hear the music" feel.
I want to make clear that I do not necessarily disagree with your assessment, but understand that there are people who are deciding whether to pick up an FP book or OOP book. They have to start somewhere, and this "wholistic" advice isn't tremendous help. Similarly, as an industry, it's hard to translate what you just wrote into the next UI framework. I think we can agree that we feel comfortable enough with loops to not take a completely neutral stance on the "loops vs. lngjmp opcode" debate? If someone asks you whether they should uses gotos everywhere it isn't strictly necessary to say "depends on the problem!" given that they probably aren't writing assembly-level filters for Adobe Photoshop where using a goto might actually make a difference -- since they probably wouldn't be asking in that case?
This isn't even an "all things being equal" situation. We are actively encouraging OOP to entry-level programmers today -- it is fair to ask whether that is the right move, because doing nothing is actually just choosing that OOP should be the default. It is totally fine to say "maybe OOP has not delivered on its promises, and while there may be useful lessons here, I think its safe to say that its probably not the tool you should choose FIRST for any given problem."
I suppose it's an aside to your main point, but after 15 years of doing this stuff (and learning to code by writing procedural PHP first, back in the 4.0 days), I've spent a portion of it investing in OOP and now I'm starting to take a step back from it, and I'm having much more fun writing code without having to worry about classifying the code I'm writing.
The things that OOP does well can be achieved quite nicely using other programming paradigms: you don't need a class system or a hierarchy to encapsulate your state and behaviours. And a good OOP language gives you the resources to model your behaviours in functional and procedural ways so long as you have first-class functions and good support for expressions in favour of statements.
OOP fits much better into an organisational model where you can think about domains, roles, and responsibilities, and all of a sudden your Factories, Validators, Services, Commands, Builders, Entities and Repositories map to the same way of thinking your hierarchy of teams and managers does, with all of the overthinking and bike shedding that comes with it.
You could build the same feature without all that but I think you need an experienced and disciplined team to pull it off well. And I think that supports your point: if the entry point to programming wasn't OOP (like with Java or PHP or even Ruby) but something more fundamental, then maybe that gives you the opportunity to decide when you need the power of abstraction that OOP gives you.
What do those entry-level programmers want to make? They should start with something suitable for that, even if it's harder to learn. A motivated novice will do better at learning hard things than an unmotivated one will at learning easy things.
But I'm getting out of my element here; I don't interact with entry-level programmers that much. For all I know it may be good for that group that we have fads. If the crowd decides that now we're always using composition and never inheritance, they'll get to fully explore composition. Emphasizing a single skill for an extended period is probably good training.
But to get to a more concrete example, say you're not a novice and you're making a static site builder. If you go with the fad of avoiding inheritance you'll blind yourself to the fact that a typical static site has a collection of page types with is-a relationships, totally ripe for inheritance. You'll probably go with the "layout attribute" model of grouping pages and miss the opportunity to make a static site builder that's better than the others.
> We are actively encouraging OOP to entry-level programmers today -- it is fair to ask whether that is the right move, because doing nothing is actually just choosing that OOP should be the default. It is totally fine to say "maybe OOP has not delivered on its promises, and while there may be useful lessons here, I think its safe to say that its probably not the tool you should choose FIRST for any given problem."
the following is my anecdotal opinion but...
that is mostly an economic effect caused by the java “pop culture” and education being seen as a way to “get a job” which is then self-reinforcing (more educated in java, bigger talent pool, increase in default job requirements, more educators by default choose java
economics is a huge factor in this “i hate oop” bandwagon because java isn’t even “good oop” (again my admitted bias) and people dislike being toldwhat tools to use, either by educators and employers when they can see much better ways to do things than DataManagerFatoryFactoryInjectionContainer<T>...
This. Java took too abstractions to absurd extremes. Contrast that with something like python which does things much better and uses a nice data model.
We choose the right tool the same way a painter chooses among oil paint, watercolor, etc. Step back and look at the subject, and think how well each type of paint would represent it. Also consider one's own skill with each type of paint, one's interest in exploring new paints, and the cost of obtaining and storing another kind of paint.