OOP is a superficial lowest common denominator of programming. Everyone can understand on a superficial level (cat is a animal, dog is an animal, cat does meou, dog does bark, kind of thing), and proceed to write programs. That's why it is popular.

OOP works on low complexity, small projects, but quickly falls apart at certain point, but then it's just head scratching and finger pointing ("this ORM is just bad, next time we will use a different one").

More experienced people figured out some way around OOP to make it more robust, so whenever OOP is criticized they just do the "oh, you just doing it wrong: insert excuse and advise here".

People who really though it through, and tried different approaches are the ones that hate it and are vocal about it. They see through the folly. They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.

> They can tell how core principles of OOP are bad ideas. How encapsulation at object level is usually pointless and costly, how inheritance doesn't make sense, and so an so.

Can you explain these? I'd like to know why people think encapsulation and inheritance don't make sense.

On encapsulation: I joke that encapsulation on a level of an object is like putting a lockpad on your right pocket to protect your left hand from reaching to it.

Normal people keep doors and locks at the entrance of a door or a room (module level), not on every single object they have. That's why OOP software tends to look so schizophrenic: with walls erected between everything against everything, making stuff like https://github.com/Hello-World-EE/Java-Hello-World-Enterpris... possible.

You might check some of my blogposts at dpc.pw if you care to read more of my thoughts on this.