Sunday, January 7, 2024

For about six months now, I have been hacking away in good old C. Somewhat unexpectedly, I find that it still is a great language to program in, even today, despite contemporary beliefs that C is evil, C is dead. It is also undeniably straightforward, uncomplicated. Its simplicity is its strength. I want to share with you a profound piece of monologue delivered by game programmer celebrity Jonathan Blow—this guy knows his stuff, and he preaches the gospel of programming.

“Here’s actually what one of the big problems with software is, that starting in the 80s—

Prior to the 80s, everybody was just trying to solve real problems and trying to get computers to solve real problems. And then, starting around the 80s, computers got fast enough that you had a lot more leeway around how you solve the problems. People started making all these theories about how to solve problems in the best way. Object-oriented programming is one of those theories.

Oh! On the list of things in C++ that are wrong, “object-oriented” is wrong, because of course, Alan Kay invented the term object-oriented and it meant something else; it meant Smalltalk, not C++. So, even the term object-oriented is wrong, the way people use it.

People came up with all these ideas about how to program, and then the problem is those ideas require entire belief structures. So, if you go to program in C++ object-oriented world representation style, then you start to believe from the way that you’re taught, that programming work is about building the hierarchy of objects in the right way or something. But that’s not actually solving a problem; it’s just conforming to a belief structure that you’ve been given. After you’ve decided on that hierarchy of objects, you still don’t have a program that solves any problems. Now you have to go write the program within that framework that you decided on. And so the problem is, as we get further and further away from real actual problems … More and more of what is taught to people as ‘programming’ is actually not doing anything; it’s just shuffling papers around on your desk.

And so the question of how do I do an interface that, blah blah blah, is just shuffling the papers around on your desk, because it’s not actually solving a problem.

What I would say is: write the editor, and then write the plugins, or whatever. Write the functionality. Make the functionality work. And then, if you’re dispatching between them with an if-statement and it feels kind of hacky, and you need more abstraction for a very concrete reason, then put in a function pointer. But I wouldn’t even do that; I would just have an if-statement that turns them on or off for a long time, because it’s actually a relatively … That part of writing an editor is so small and so minor in terms of what it solves, that I wouldn’t even bother for a long time.

On the other hand, if you buy into a weird structure, or many weird structures, which is what happens, in order to preemptively solve this very small problem before it becomes a problem, you end up taking on all these very large belief structures, that are actually very hard to conform to. And you have to conform to those belief structures all the time, because that’s what you made your program be. It actually gives you a much bigger job to do than you actually have to do to solve the actual physical problem that you have in the objective world.

That’s the best thing that I can say about this.”

— Jonathan Blow

He mentions C++, but it’s really about OOP. If you have ever programmed any assembly code, then you realize that at the machine level none of these high-level abstractions exist. They are fluff designed to make thinking about program structures easier, but instead you end up wrestling with problems introduced by the fluff itself. The fluff is unnecessary and limiting; it typically puts limits in place that actually prevent you from reaching your goals easier—which is producing code that works.

Imperative programming is the purest form of programming; it is instructing the computer what to do. Once you start diverting from that, you are preoccupying yourself with how to structure the structure itself, rather than getting actual work done. In that respect, OOP is distracting and counterproductive.

It’s funny how in this day and age the classic debate about OOP still is ongoing. There has been at least one entire generation that grew up on nothing but OOP (Java in particular). Languages like Rust and Go are not full blown OOP, so there is hope for the future. The C language is far from perfect (in fact, it has many flaws) but it does give me something that many other languages don’t, and that is joy.

Jonathan Blow is a funny genius. Watch him talk on YouTube, he is regularly live on Twitch too.