Switching to OCaml bois

He died of XML factory injection pattern exposure.

I’m just not sure what the middle guy would be saying

"I hate inheritance! I hate inheritance! I hate inheritance! I hate inheritance!"

But well, inheritance goes brrrrrr.

I have the same problem with oop. 10 levels of encapsulated calls just to see you were in an overridden methods without enough data to find out which implementation it was. Ugh

If the only tool you have is a hammer, everything looks like a nail.

That's the only thing I can think to answer your question. There are some problems that are best solved with other tools, like text parsing for example you might want to call out to some code written in a functional language.

I don't think that the anti-oop collective is attacking polymorphism or overloading - both are important in functional programming. And let's add encapsulation and implementation hiding to this list.

The argument is that OOP makes the wrong abstractions. Inheritance (as OOP models it) is quite rare on business entities. The other major example cited is that an algorithm written in the OOP style ends up distributing its code across the different classes, and therefore

1. It is difficult to understand: the developer has to open two, three or more different classes to view the whole algorithm
2. It is inefficient: because the algorithm is distributed over many classes and instances, as the algorithm runs, there are a lot of unnecessary calls (eg one method on one instance has to iterate over many instances of its children, and each child has to iterate over its children) and data has to pass through these function calls.

Instead of this, the functional programmer says, you should write the algorithm as a function (or several functions) in one place, so it's the function that walks the object structure. The navigation is done using tools like apply or map rather than a loop in a method on the parent instance.

A key insight in this approach is that the way an algorithm walks the data structure is the responsibility of the algorithm rather than a responsibility that is shared across many classes and subclasses.

In general, I think this is a valid point - when you are writing algorithms over the whole dataset. OOP does have some counterpoints encapsulating behaviour on just that object for example validating the object's private members, or data processing for that object and its immediate children or peers.

Operator overloading is adding complexity, making code subtly harder to read. The most important lesson for code is: It should primarily be written to be easy to read by humans because if code is not trash, it will be read way more often than written.

Because an object is good at representing a noun, not a verb, and when expressing logical flows and concepts, despite what Java will tell you, not everything is in fact, a noun.

I.e. in OOP languages that do not support functional programming as first class (like Java), you end up with a ton of overhead and unnecessary complications and objects named like generatorFactoryServiceCreatorFactory because the language forces you to creat a noun (object) to take an action rather than just create a verb (function) and pass that around.

Having to run a debugger to know what gets called at a given time is awful, and this oop practices exacerbate this

But you have used objects I think.

Huh? I've worked with TypeScript + React for the last 5yrs and the only time I see OOP is when someone's done something wrong.

Maybe you're thinking of old react with class based components?

once i learned about defer it became a hard requirement. cpp kinda gives me that but other c like languages do it better.