Why Object-Oriented Programming is Terrible

There is this myth that object-oriented programming is worth anyone's time. It's not. It's a total waste of time. It's just garbage. Complete, complete garbage. There's nothing good about it. And it's all very sad, stupid stuff. I don't know why people came to believe this would make any sense. It does not.

Object-oriented programming never works except for very few times, sometimes, you know. But apart from that, it doesn't work. It's just not good. It has no upsides and lots of downsides.

The Taxonomy Problem

The idea behind object-oriented programming is to have everything that you code be part of a taxonomy of objects. A giraffe is an animal. No, a giraffe is a mouth breather, and every mouth breather is an animal or something like that. And everything has to fit into exactly one position in this tree of things.

And this doesn't even work for biology. It doesn't work almost anywhere, right? And that's why it's stupid.

In real life, when you code stuff, you don't know how things relate to each other before you write them. The taxonomy just grows over time. How things relate to each other changes over time as you code. So your neat tree of objects starts to become spaghetti.

Private Members Are Stupid

I would even go so far as to say private members of classes are stupid. That's what I would say. And that's because you don't even know what field of your class somebody else will need to access at some point or not. You should just be honest with yourself here. You have some data and you want to run some code on it, and you have no idea what kind of code will be run on it. You just don't know. So don't waste your time on these abstractions, on hiding stuff. That's all stupid. It's all pointless.

I mean, I guess there are very few situations where you really can come up with an API and then there's stuff that's part of the API and there's stuff that's not part of the API. And then there are different ways to model that. Object-oriented programming and private methods and fields can be one way to express that.

But what I'm seeing is that people write a class and then they just come up with private fields. They just put everything that currently is not needed as part of their public methods as private. That's what they do. And if that's how you do it, then why aren't you just defining a struct and some functions in a file that you don't export to the other files? Why so complicated? I don't get it.

The Invariant Myth

Why do you need private fields? The idea behind it is so stupid. The idea behind it is that there are some kind of invariants in your object. Right? And that the functions you defined on the object, they all make sure that the invariants stay fulfilled. And so everybody who now uses your API to the object can be sure that the invariants are not violated and everything's fine. The right way to use your object is to only use your API and then they don't have to understand the invariants or how your object works. That's kind of the idea.

But who codes like that? I don't, right? The way I code is I look at your code. I just read it all. I read your implementation. I read your class. I read your private stuff. I read your public stuff. I just read everything. Just everything. And then I go on from there.

To me, there's no difference between what's private and public. I just read it all. Because your abstraction is too shitty anyway, your invariants. You can't even express them well enough because you don't understand them yourself very well when you coded it. So I don't give a shit either. I just want to see the code. I want to read it like left to right, top to bottom, and then I just add my code. That's the only sensible way. Everything else is crazy. Everything else is made up shit.

What Actually Works

Except for the very few cases where you do have a good API. But you usually do not have a good API, right? And this should be accepted.

If you want to help people and have a nice API, have a couple of functions that do something very reasonable with good names and good comments describing what they do. That's what you need. Everything else nobody cares about. Waste of time. Utter waste of time. Your weird ideas of classes and subclasses and inversion principle shit. Nobody cares about that. Really, nobody cares about that.

The C community is doing it right with their man files, right? They just have a function and then they describe in great detail what the function does. That's it. And even that you can trust, right? Because there's some detail there.

The Abstraction Problem

Maybe this is also the point where I argue against abstractions in general. There's this idea that you could abstract over things. And this is kind of true to some extent for simple stuff like strings and numbers, right? Like depending on your application, you can abstract over those things. But if you do system level programming, you can't even do that. Even that gets crazy. But usually you can abstract over numbers, you can abstract over how adding and multiplying is happening. You can have a concept of a string. These things work.

But all the other abstractions, they kind of suck. They just usually don't work because nobody understands your abstraction. Nobody understands how your abstraction is supposed to work, how you're supposed to use it. You yourself implemented your abstraction wrongly. There's bugs in your abstraction. So when somebody uses it, they can't actually think about how your abstraction is supposed to work, but they have to think about how it actually works. So they have to actually read your source code.

Performance Matters

And this is really important. Usually when you code, you have to think about performance also. And often this is not part of the abstraction somehow. People just ignore performance stuff and how much memory stuff uses when they make their abstractions. Very often that's just ignored. And then I use your stuff and once I get into performance issues, I'm just fucked. And I can't do anything.

But a good programmer then just goes and reads your code and finds out why your code is slow in this particular situation and what should have been done instead. And then your whole abstraction shit doesn't matter anymore.

Just Use Structs and Functions

Instead of building these weird code edifices, these monuments of code, you should just give people a function that does a thing and you tell them how it does it also so they can kind of guess how fast it will be. If it's fast enough for them. That's what you should do. Fuck the rest, really.

It's really dumb. It makes no sense. Why would you not just do structs and functions? You can do everything with it. The Linux kernel is written like that. Why would you need anything else? Why do you need all these complicated things? I don't get it. It just seems made up. It seems stupid.