Object Oriented Programming is usually not the best choice, especially not good for startups

Have you ever tried to tell a beginner developer, that Object Oriented programming (or any other tech which is in the main stream opinion) is bad? Young students are finishing university and automatically doing what everyone else are doing: object oriented programming, so the reaction would probably be like of religious fanatic as if you entered the Vatikan naked or ate a pork-pie inside a synagogue: usually developers respond in an aggressive manner when you try to tremble the boat of technical methodology, especially if two of the holy grail of 2020 tech is on discussion: Object Oriented, and Node.js. Both are fairly problematic technologies -especially for startups. I will devote this article to Object Oriented.

Lets go back to the 1980’s. I was a kid then and was compiling my first Cobol program. It was a simple program (I can’t recall what it was), it took days if not weeks to compile it though (my first program was PL1, it was written on punch cards when I was 12 years old and it took me 9 months to make it run). Computers were slow, and compilers where very picky. It took ages to make a program run well.

Then Object Oriented was introduced: the idea was, that instead of writing a “one full” program (procedure), you identify objects which could be reused, and program them first. Once an object is compiled, you can reuse it in other programs: no need to wait for it to get compiled again, if you planned that object in a very generic way, you could use it for many other specific similar objects. A simple smart idea – which saved a lot of pain!

However… we are not in the 1980’s, and computers today are million if not billion times stronger than what we had then. Object Oriented has developed into a complete methodology and science – which has some usages I admit, but not to the extent that it is being used today. I will explain why.

1. First, not everything is an object

As a starting point, we need to understand, that not everything is an object. A database query, for instance, is not an object: it is a function. Yes you can wrap a database connection / query as an object, but this is like taking a fly and dressing it up with a costume of a shark so it could go the a baby shark birthday: it does not fit. Classical objects, are things which can be constructed of elements, which are constructed of other elements, which are constructed of other elements, until you reach the atom level of those elements: if a generic object can be defined, and it needs to be replicated to different types of objects, than OO is most likely useful. Otherwise, it does not.

Object Oriented does not always fit

2. Object Oriented is designed for compilers, not for interpreter languages

I was shocked to find out that a software engineering graduate which is a fairly good developer, didn’t know the difference between compiled languages (like Java and C++) and interpreted languages (like Php and Ruby): OO is designed for compiled languages, and in general, does not fit with interpreted languages. Reason is, that when you create an object, it needs to be stored someplace. In compiled languages, it is stored as a binary file (what causes – in some cases – to another problem with OO, see below). In interpreter languages it is stored in the cloud so it does not take any resources – naahh this is nonsense – because nothing can be stored without consuming resources – so in interpreter languages, objects are stored in the memory (or in caches)…. and it is stored as long as your script is running. This is a huge overhead when it comes to web programming, since in web programming you are serving not one user, but thousands of concurrent users. If you are missing some server’s RAM or feeling that you have a memory leak – consider stopping to use OO!

3. Machines understand procedures, not objects

With all the respect to OO, CPUs and common machines understand procedures, i.e. a step by step sequential execution of code, and not object oriented code. It means that any OO code has the potential to be longer, and more resource consuming, than a well written procedural code. It means that something (OO) needs to be translated to something else (procedure) – there is always an overhead when converting one form of something to another form. You need to pay a price for that, in the shape of processing time or memory usage.

Machines understand procedural code

4.Object Oriented Programming tends to overuse the file system and turn into a spaghetti code

I mentioned before, that objects need to be saves someplace, and that most commonly it is saved as files. Lets look at the Facebook Graph API SDK, this is how one of the files looks like:

Facebook PHP SDK – Object Oriented looks like a spaghetti code. Their Ruby SDK looks as bad

Count with me: that file is including 19 other php files, taking into account that no other files are included by any of those files. But actually, a quick look inside, and you find more files included:

Lets leave for a moment the fact that it is already looking like a spaghetti, and the fact that in procedural programming this whole SDK could be done in one file of 500 lines max (I actually connected to Facebook Graph API with custom made CURL and procedural code of 20 lines). I want to speak about resources, and the file system: including files while running a script language (interpreter) is using the server I/O requests and Hardisk: it is way slower than any database query, and obviously slower than any execution of any procedural code. It is slower, and does not scale good. It is bad programming.

5. Object Oriented is bad for small teams / projects

Are you competing with Boeing or Martin Lockheed – designing the next jet airplane with hundreds of engineers working on the same invention? Then probably Object oriented is the methodology you want to look at: when assembling code from hundreds of developers, it may be easier and cheaper to use Object Oriented to assemble code from thousands of different developers especially if many of them will not be with you at the finish line i.e. would leave work before the end product is delivered. However… I find it had to believe that such big pieces of software really exist, and I also believe that a smart team of engineers (like the NASA Voyager team did) can assemble pieces of project together without the necessity to use OO and therefore keep the code efficiency to its highest standards. In fact, if they did use Object Oriented programming of today, the voyager wouldn’t fly: when it comes to smart projects, you must make your code targeted and condensed as much as possible.

6. Object Oriented is obscuring bad programming

By its nature, Object Oriented is obscuring bad code. This is very simple to understand: the idea behind OO is that you pack objects, and then reuse them without the need to look at the inside code – they even have a nice word for it – “encapsulation”. Imagine the above Facebook SDK for example… would you dig inside hundreds of php files to audit each line of code? Obviously not… what almost guarantees you that the bad code is hiding there under a mask.

Object Oriented is obscuring bad code

7. I did a little experiment and this is what I got

So one of the developers I worked with just emerged out of university. He developed our project of a REST API in Object Oriented, and then I required him to convert it to procedural code. Lets not discuss the dramas and tears and even not the end result – which still included some objects which he refused to define as objects in order to tick the mark that his code is procedural, mission accomplished (it wasn’t). In summary, this is what we got in the end – now try to guess – which line is OO and which one is procedural?

Object Oriented code vs. Procedural code of a REST API program

10. “Mutation”, “Encapsulation”… move on, we are not in the 1980’s

If you go on OOP tutorials and blogs, you will hear programmers proudly describing the the main advantages of OOP are encapsulation, mutation, and polymorphism – big words indeed, but when you check the details – in modern procedural and even functional programming languages, all this is ABC and can be done easily without any objects involved. In PHP for instance, you can define global variable or local variable, and you can define a function inside a function. There is nothing fancy here with OOP. In fact, think about this idea: to create objects, you must use procedural functions. To create procedural functions, you don’t need any objects.

9. Object Oriented is structured bad

Annoyed by the fact that I stick clause 9 after clause 10? Well that is how Object Oriented Programming looks: if you don’t enjoy it, you get my point.

11. And finally.. what others think?

I felt the need to copy this from Wikipedia, as a summary what others say about Object Oriented Programming:

• Richard Stallman wrote in 1995, “Adding OOP to Emacs is not clearly an improvement; I used OOP when working on the Lisp Machine window systems, and I disagree with the usual view that it is a superior way to program.”
• A study by Potok et al. has shown no significant difference in productivity between OOP and procedural approaches.
• Christopher J. Date stated that critical comparison of OOP to other technologies, relational in particular, is difficult because of lack of an agreed-upon and rigorous definition of OOP. A theoretical foundation on OOP is proposed which uses OOP as a kind of customizable type system to support RDBMS.
• Alexander Stepanov suggested that OOP provides a mathematically-limited viewpoint and called it “almost as much of a hoax as Artificial Intelligence” (possibly referring to the Artificial Intelligence projects and marketing of the 1980s that are sometimes viewed as overzealous in retrospect).
• Paul Graham has suggested that the purpose of OOP is to act as a “herding mechanism” which keeps mediocre programmers in mediocre organizations from “doing too much damage”. This is at the expense of slowing down productive programmers who know how to use more powerful and more compact techniques.
• Joe Armstrong, the principal inventor of Erlang, is quoted as saying “The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”
• Richard Mansfield, author and former editor of COMPUTE! magazine, states that “like countless other intellectual fads over the years (“relevance”, communism, “modernism”, and so on—history is littered with them), OOP will be with us until eventually reality asserts itself. But considering how OOP currently pervades both universities and workplaces, OOP may well prove to be a durable delusion. Entire generations of indoctrinated programmers continue to march out of the academy, committed to OOP and nothing but OOP for the rest of their lives.” and also is quoted as saying “OOP is to writing a program, what going through airport security is to flying”.

Keep well 🙂

Eran