I was just reading through a bit of OOP Is Much Better in Theory Than in Practice (via).

A lot of these kinds of critiques trigger my grumpy curmudgeon bit, so I often dismiss them (maybe this is a sign of ageism on my part). Often I think they blame a concept for the effects of a process, or take one concept and use it as a symbol for everything they dislike, regardless of the applicability. Here, he critiques OO, but to me it seems like he's really complaining about B&D programming.

It's weird, because I'd never think about condemning OOP. It would be like condemning the for statement. I've read some bad code that uses for, but I certainly wouldn't blame the construct for it. It's like blaming carbon for war, or gravity for an icy sidewalk, or arithmetic for Enron. Is this a generational gap, that I have objects ingrained as a basic metaphor for programming? No doubt I am very suspicious of many parts of OOP (like inheritance)... maybe I choose to project those things I like onto OOP, while dismissing the things I don't like so much (like encapsulation) as separate.

My first OOP influences were C++ and Oberon (in school) and Squeak (independent study). C++ was really used like C, and objects were fancy namespaces; not very compelling (though it still excited me after too much GW-BASIC). Oberon was surprisingly easy to dismiss as a language -- decent compiler, interesting UI, but a lousy language. Maybe if I had used Eiffel or some nice B&D language I might have a different perspective -- I doubt I'd like it, those kind of languages just don't fit my personality, but I may not choose to dismiss that perspective on OOP as being Not The True OO Way.

Now I've grown to see OOP as a mechanical process. Or you can say I've become just slightly more curmudgeonly. Python certainly encourages this mechanical view, as the OO system is quite transparent, and reduceable to simple operations (getattr, the mro, and a couple other concepts). I don't think about is-a vs. as-a very much, I just focus on the mechanical aspects and I think I get by pretty well.

There's a lot of critiques about ideas that Aren't Good Enough; like OOP, or static typing, or metaclasses, or macros, or whatever. I think it all comes down to: (a) programming is hard, (b) programming with objects is also hard, and while we're at it, (c) functional programming is hard, (d) concurrent programming is hard, (e) type-safe programming is hard, (f) programming with dynamic types is hard, and (g) extreme programming is hard. Some other kinds of programming are also known to be hard. Some people might say there's no silver bullet; but damn, isn't that obvious? Programming is clearly AI complete. Oh well, at least I don't have to worry about losing my job to automation anytime soon.