C89-OOP: Thoughts

To me, object-oriented programming is a bit weird. It's like trying to make many small-contained programs in a big program, or to componentize your code to the extend it's becoming lego bricks; plug and play. It's a way of programming loved by enterprises and acedemia for the modularity, protections and standarization, as well as for all the open-ended debate and research that comes with new techniques and philosophies. On the other side, very important programmers like Rob Pike, Paul Graham and John Carmack advocate against the usage of object-oriented design:

"Object-oriented design is the roman numerals of computing." -- Rob Pike

"The object-oriented model makes it easy to build up programs by accretion. What this often means, in practice, is that it provides a structured way to write spaghetti code." -- Paul Graham

"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function." -- John Carmack

"It is not that uncommon for the cost of an abstraction to outweigh the benefit it delivers. Kill one today!" -- John Carmack

OOP considered harmful?

Because of all the standarization efforts, it's much easier for enterprises to look for programmers with a specific set of skills universally understood. This in theory means there are much more job oppertunities, but in pratice it means the programmers are now turned into robots glueing components together others wrote or written by yourself.

Okay that's quite an overstatement, but there is truth to this; businesses like to play it safe, why write it yourself if someone else did it already? There are plenty of arguments to be made in opposition to this, but usually it's not appriciated. That's why these days I just try to avoid the discussion.

I don't think that OOP is bad on it's own, there certainly are cases where OOP is the best solution. However, I believe that most programmers passionate about OOP go too deep into the doctrine of adhearing to principles and paradigms, making them blind to the complexity it brings with it.

Correctness

Something I discovered recently is that imperative program use tuning machines to prove mathmetical correctness of a program. Functional programs can use labda calculus. Event driven languages can use pi calculus. But what about OOP? So far there is no mathmetical model which can validate the mathmetical corectness of such a program, or at least not one agreed-upon solution that I am aware of.

Instead, OOP relies on principles and paradigms like GRASP and SOLID to validate whenever your code is "correct":

• Favor composition over inheritance
• Hollywood Principle
• Program to an Interface, not to an Implementation
• GRASP
  • Creator
  • Controller
  • High Cohesion
  • Indirection
  • Information Expert
  • Low Coupling
  • Polymorphism
  • Pure Fabrication
• SOLID
  • Single Responsibility Principle
  • Open Closed Principle
  • Liskov Substitution principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

To me this is really weird, because we're programming for mathmetical machines and not humans. We don't execute the code, machines do. Sure we as programmers spend all our lives reading code, but that's nothing in comparison how long a program runs on the end-user's machine (customer, server, whatever).

It's even crazier to me that a huge amount of somewhat vague (not mathmetically sound) set of rules dictates correctness of a program. If you truly need the complexity an OOP language brings with it and this amount of principles to define what a correct program is, then why aren't you asking yourself if you are approaching the program from the wrong point of view?

So, what now?

That's why I want to cover in my upcoming article series how to emulate various OOP features and to demonstrate the hidden cost behind it from a best-case scenario (aka without the bloated runtime an OOP language usually comes with)