I was already an Old Turk when OO hit the scene :-) I have actually handled punch cards and even (gasp) paper tape. So my brain is pretty much hard-wired to the Procedural paradigm; but even allowing for that bias, I had a lot of doubts & skepticism when the OO bandwagon started tooting. Never really got won over to it. Reading this article makes me feel a little better about that.
The main problem I had with OO code was that it felt unwieldy, over-formalised, over-architected, like a very high overhead even to write something simple… NASA would have liked it :-) Plus, it seemed (to me, the dinosaur) so darned hard to read and understand for the next maintainer, months or years later. The object hierarchies go on and on (upward and downward) with all their levels of inheritance (rather like indirection carried to extremes) that I found it pretty daunting just trying to figure out what some 8-line function was really doing :-) I felt like OO as written by purists was sort of self-obfuscating code. Maybe if your head was deeply enough into OO, I figured, if you were not a dino like me, it would be more readable and “all fall into place” — but this article suggests that even for the original author, a younger author, with proper OO training, understanding all the implications of the OO style can be a challenge.
To handle the typo-free production of large wodges of boring code that share a lot of attributes with other large wodges of boring code elsewhere in the source tree, what my group did was basically write code that writes code; from a shared SQL database we would generate on demand the huge include files and other boilerplate source that had to be shared and re-used and maintained throughout our large code base. That’s still the tool that I instinctively reach for when I want to “share and inherit”: store the attributes as some kind of database and wrap any desired syntax around them. But I’m a dinosaur, like I said.