Axilmar’s Blog responds to “Object Oriented Programing is an expensive disaster”

Axilmar’s Blog has a very strange post. I can not know if English is their native language, and I am sympathetic that some ideas get lost in translation. Still, they seem to have misread most of the article. On Hacker News they were asked how they extracted points from the article, and they wrote:

I just read it, skipping the non-essential parts, after quickly scanning them. I might have missed one or two points, but it doesn’t really matter.

But they frequently mistook the quotes as things that I was saying, not realizing when I was quoting someone else.

The claim I made this logical fallacy:

“OOP is not a good programming paradigm because modern OOP languages do not implement message passing in the way Alan Kay, creator of Smalltalk, envisaged.”

I gave a historical review of Kay’s ideas and then I wrote:

When I get into a conversation with a proponent of OOP, I try to point out that the reality does not live up to Alan Kay’s original dream, at which point the original dream is usually dismissed. At this point in the conversation I typically hear some variation of “Modern OOP has evolved into something much more powerful and flexible than its original vision.” Which is fair enough. Time goes by, and software development, as a field, has undergone many changes since the early 1980s. So what are some modern understandings of OOP? Let’s review a few of the sites that try to teach OOP to beginners — what do they view as the core ideas of OOP?

At which point I moved to talking about moderns ideas of OOP.

Also, in my essay I link to a half dozen articles, aimed at students of OOP, which claim that a key benefit of OOP is static typing. And then Axilmar’s Blog says:

“No one ever, in their right mind, says that. I have never seen this being said, outside of the above-mentioned article. There is no definition anywhere about OOP that includes the words ‘static typing’.”

But I linked to several articles that all make that claim. How many articles do I have to link to before they are accepted as evidence?

And then they write this about encapsulation:

OOP never promised to shield the programmer from the pitfalls of multithreaded programming. What OOP promises, and delivers, is to shield the programmer from the pitfalls of shared responsibility.

In the above example, fixing the problem is easy because it is only the UniqueId class that is responsible for delivering ids. So, in order to fix the problem, the delivering operation can be managed with a thread synchronization primitive, like a mutex, embedded into the object.

But in my original essay I had written:

Whenever I make this point in conversation, someone will tell me that I am confused — locks have nothing to do with encapsulation, I am making a big mistake by running these 2 ideas together. But what is the goal of encapsulation? Encapsulation is a form of “data hiding”. Why do we want “data hiding”? We want it because we want protection from unexpected changes to state, and OOP encapsulation rarely gives us this — we have to combine this kind of encapsulation with other tools, such as locks, to achieve the goal. This suggests weakness in the way that OOP enables data hiding.

Then they go off on a long tangent and ascribe to me things that other people said. All of the following assertions were in quotes from other articles:

OOP is bad because Inheritance is bad; inheritance allows for large hierarchies.

OOP is bad because Inheritance is bad; inheritance does not allow the separation of behavior and types.

What I actually wrote was:

Inheritance is crucial to the software that I write. Inheritance is one of the most important ideas in software development…

Inheritance is good. Nearly all data-types belong to a hierarchy, and my code should be able to represent that hierarchy without fear. If I write software for a store, I will probably have a “sell price” and a “buy price”, both of which are children of “price” which is a child of “transaction metric” which is a child of “decimal” (or “number”). I don’t want to model this with composition, nor do I want to worry about brittle base classes and tight-coupling between the interface and the implementation. To escape from these worries, I want my data-types declared in a hierarchy that is all-together separate from my code’s behavior (the functions that I write). Functional languages like such as Shen, Haskell or Clojure allow for data-type definitions that are separate from the behavior of my code. Java does not. Ruby does not. Python does not.

And then they write this:

Java has interfaces, which can form a hierarchy. Doesn’t the author know that?

But in my original essay I showed several examples of Java interfaces, so I suspect Axilmar perhaps has trouble reading English, or Java.

And this also shows simple ignorance:

“…a comparable in features FP program would have just as many data types, because the classes in the OOP system would represent different concepts.”

One has to assume that Axilmar has very little experience with functional programming.

And this also is simply incorrect:

Well, no trivial program can afford having data types in a single source file. It does not matter if that program is OOP or FP, putting all the data types into a single source file is simply bad practice. It may work for small projects, but not for large ones.”

In my original article I quoted Joe Armstrong on this subject:

In an Object Oriented Programming Language (OOPL) data type definitions belong to objects. So I can’t find all the data type definition in one place. In Erlang or C I can define all my data types in a single include file or data dictionary. In an OOPL I can’t — the data type definitions are spread out all over the place.

And this also shows a shocking misunderstanding of both Object Oriented Programming and Functional Programming:

OOP is bad because OOP drives us to instantiate objects in the middle of our code, making our code more difficult to test because the code depends on that particular instance we create, whereas in FP we don’t have to do that.

He says this: “the OOP version is worse because if we wanted to test it, we have injected a dependency in it, making testing harder”.

How is that different from testing a function that calls another function?

The difference, of course, is that objects carry state and functions don’t. If Axilmar was unable to understand that, then they are unable to understand any part of the debate between OOP and FP.

This bit is simply incredible:

Erlang is clever in the way that it manages services, but it is not due to the language: the same design pattern can be implemented, let’s say, in Java, using messages coded manually (instead of message passing supported by the language).

So, according to Axilmar, Erlang is more clever than Java but we should keep using Java.

Axilmar’s post is pure nonsense. I’m not going to waste any more time on it.