The interesting thing about living through a period of rapid change is that most people don't even realize what's really going on until it's already complete.
For example, most people are completely blind to the effects of "user-tailored search" in that as it evolves, they will see fewer and fewer opinions, theories, and even facts that disagree with their current world view. Rather, they see this as a good thing!
What does this have to do with programming? OOP is a dead end. It failed, it's a stinking rotting carcase, and yet we continue to use it because it caters to our prejudices - in particular, to the idea that we are SO clever because we an build ever more complex systems. And because OOP resembles empires in another way - they all get their biggest and bloatiest (is that even a word???) right before the fall.
The problem is, more complex OOP systems eventually become more complex than they would have been with a non-OOP solution. While initially OOP allows us to kick the complexity can down the road a ways, as systems evolve, the extra overhead (brain space, code, maintenance, debugging, etc) more than makes up for any "win" that OOP brings to the table.
After spending some time converting re-implementing some code as OOP, and looking at the bloated and much less flexible results that a "proper" encapsulation/inheritance/whatever-the-heck scheme once again produces, I took a break, and played around with an old friend I had been ignoring
Haven't touched it in years, but it really is like riding a horse. Better than riding a bike, because you don't have to do as much work pedaling. I looked at it, and realized that compared to todays "modern" solutions, it would be much easier to teach someone assembler from scratch than, say, Java.
So why does assembler have a reputation for being "hard" when you don't have to have an IDE to code-complete for you because the required libraries in Java have proliferated like rabbits? Who knows - probably because people who teach it make it hard to learn. Or because they're afraid of the big bad macro.
this next section replaces a bunch of language-specific OOP fails
Why? Because you either already know what they are, or you're not yet at that place where it's become painful enough, so what's the point?
Instead, take a few minutes to zone out and read one example of how messy inheritance can get
The end result is that, after spending a week or so on re-impementing code as OOP, I now have to undo it, because OOP once again fails to deliver on the promise of better maintainability. And that is going to be the last time that happens. OOP is like the "Year of the linux desktop" - sounds good in theory, but the reality is that it's mostly more work than it's worth. Sure' it's attractive, in an intellectual sense. I think that's part of why it's so popular. But it doesn't deliver.
That's too bad, because I can still remember how exciting it was using BC++ 3.1, back in the days when Borland was the only vendor that produced a decent c++.
Moral of the story
The only way to manage complexity is to *ahem* actually manage complexity. OOP is just another fake silver bullet along the way. But like any empire, it's going to take a LONG time to die, because there's just too many people who have invested too much psychologically and economically to even consider that OOP may be the disease, not the cure.