Doubts about object-oriented programming (OOP)...

Doubts about object-oriented programming (OOP)...  I read a long article by Lawrence Krubner this morning.  I have no idea who Lawrence is, but I found his article quite fascinating, and some of his points resonated strongly with me.

My perspective on OOP is a little different than Lawrence's, and in fact probably a little different than the vast majority of today's programmers.  This difference in perspective comes about mainly from my age (I'm 62) and the fact that I never had any formal education in computer science or programming – I'm entirely self-taught.

The age matters because I started programming (in '73) before OOP was adopted by the programming community.  In fact, its predecessor (“structured programming”) was just then being introduced.  The most common form of program architecture then was what we'd call “spaghetti code” today – horrifying, hard to understand, and even harder to maintain.  Furthermore, I learned to program in assembly languages, which (back then, at least) contained absolutely no support for even structured programming, much less OOP.  So I've experienced three “normal” regimes in my career: spaghetti code, structured programming, and OOP.  I've written code in well over 100 programming languages, and production code in at least 50.  I've also played around with functional programming, though much less extensively.  I've written quite a bit in Forth (a language that's hard to categorize) and one large project in Prolog (which also doesn't fit easily into a category).

The lack of education matters because I have very little exposure to the theory of programming languages, or architectures for that matter.  What little I have learned is entirely from real world experience (maintaining existing software and creating new software), and not at all from anyone's idea of what the “right” way to do something is.  I've read quite a few books about the theory of programming, but always after the fact, in an effort to understand something new that I've run across.  In many, many conversations with other software engineers this difference in my education manifested itself – generally because my conversational partner would say something that sounded like utter gobbledegook to me, and I'd have to have them explain it to me in language that I could understand.  My most intense experience like that occurred in the '90s, in the course of conversations with two particular engineers: Julia and Mike.  They spouted OOP jargon I'd never heard before at a prodigious rate, and I had to do a lot of reading and parsing of their utterances to have a prayer of understanding what they were saying.

So my perspective is different than most.  So is my conclusion about programming theory.

I don't think it matters.  Or, to say it another way, I don't think it is substantially easier or more likely that understandable, maintainable code will be written as spaghetti code, structured programming, or OOP.  The vast majority of programmers will write opaque, unmaintainable crap no matter what programming model they're using.

I say this with some confidence, after more than 40 years of working with quite a few substantial bodies of code.  There isn't a single one of them that I can point to as particularly understandable or maintainable.  There are no significant differences in the spaghetti code, structured code, or OOP.  It's all equally bad.

That's not to say that I've never, ever seen good code.  I have.  I like to think that I've produced some of it.  But that good code is always in relatively small chunks – a few thousand lines at a time, at most.  Most of the large bodies of code I've worked with have a few pieces like this, like polished jewels stuck in a cow flop.

So I think Lawrence is right: OOP is crap.  But so are the alternatives :)  I think the only thing that matters is how good the programmer is, and whether he or she did the work with craftsman-like care...