Moving Beyond the OOP Obsession

I've encountered this code a lot in C, and every time I thought that this style of

> stuff_do_something(stuff, some_parameter)

_is_ OOP and identical to

> stuff.do_something(some_parameter)

, although in language without support for OOP (of course, you can hack OOP on top of C with preprocessors and stuff, but let's pretend we forgot about that embarrassing abominations). And every time I saw that I wished that I could type the second one instead, just because of how more natural it feels.

I like the latter too, but where 'stuff' is a namespace rather than an object in the traditional sense.

What baffles me about OOP is that massive aspects of how to use it have changed, and that change happened after it gained popularity as a good technique. How could it have become popular when people were doing it wrong? The article mentions inheritance, but there's also heavy vs light classes. When I was taught OOP, an object knew how to do all the things to itself. It could draw itself on the screen, modify itself, save itself to a file, etc. Now that's turned on its head and is bad practice.

So if OOP was great with inheritance and heavy classes, how can it now be bad with inheritance and heavy classes? Were the original OOP evangelists doing it wrong and promoting something they hadn't actually tried enough to discover its problems (ie hype)? Was it just misunderstood and inheritance has always been known to be something to avoid and light (single public method) classes always been a good idea but computer science professors didn't understand it?

>What baffles me about OOP is that massive aspects of how to use it have changed, and that change happened after it gained popularity as a good technique. How could it have become popular when people were doing it wrong?

Your arguments boils down to "how come something that had utility X at some point in time, have less than X at a later point", which frankly I don't think is surprising at all, nor logically contradictory (which seems to be the assumption).

How is that surprising? It happens with most emerging programming paradigms/technologies.

They first get popularity for some new benefits they bring, and then, as the dust settles, the community finds out the best ways to do something, shapes their best practices etc.

Two examples:

1) JAVA. Initial lure: runs anywhere, easier to use than C/C++, fast, etc. Java, then went through the crazy J2EE, XML everywhere, etc phases, and after that they found a balance on how you should write code, including adopting more functional styles now.

2) PHP. Initial lure: dead easy to install, comes with every function webdevs needed at the time, runs on all cheap hosts, easy syntax. Community used crappy coding practices, bad idioms etc, but slowly improved their ways, found new ways to structure code, etc.

>So if OOP was great with inheritance and heavy classes, how can it now be bad with inheritance and heavy classes?

That was then, and this is now.

Neither CPUs, nor the available programming languages, nor needs, nor our collective understanding of programming is the same.

The same way "Finding Nemo" might be good when you're 10 (and given your other options at the time), but at 30 you have a lot more movie options...

1) CPUs: are now multicore, and OO is NOT the best way to get advantage of them (push towards pure, functional, etc).

2) Available programming languages: then, at least the mainstream ones where ...assembler, plain Pascal, C, etc, compared to which OO was a novel and handy way to structure programs. Now we have much more options.

3) Needs: back then --80s, 90s-- it was the golden age of Desktop GUI programming, for which OO is a quite good match. For web programming and the kind of work we do now, not so much.

4) Collective understanding of programming: back when a closure was something exotic, and functional concepts totally alien to most programmers, even OO was too foreign for some, but at least they understood it. So it was a good match for the average programmer then. Nowadays programmers come out of universities, or learn on their own with the millions of internet resources, and have a match better understanding of programming idioms, exposure to new ways to code, etc.

I've been saying this for years. Historically, yes, OOP has its own roots. But for all effects and purposes, C++ with headers controlling visibility is the grandfather of OOP. If you got that, then you've got OOP basics. (And, as the author points out, 90% of what you'll ever need)

There's another way of "going beyond OOP" that bears some thought, and that's growing a program by incrementally adding functions, then grouping the functions into modules.

This is actually the same point as the author is making, but looking at it from the other way. It occurs to me that if we started with writing code using pure functions, over time those functions would naturally accumulate into cohesive modules. A methodology that taught this could well end up being the TDD of the next generation of coders.