Why OO Sucks by Joe Armstrong (2000)

Objects should be used when you need to maintain invariants between members, or need an opaque stateful "thing" like a resource handle. They shouldn't be used to structure a program, but act like any other type in a functional or procedural setting.

An object should also have completely private members and no concept of inheritance. This greatly simplifies thinking about and designing objects. There should be no distinction between a regular and special method like a constructor or destructor. They should essentially be simple constructs with no magic that force interacts with a particular kind of data through functions that maintain the invariants. That's it. That aligns with the message passing origin of OO and Erlang in that there is no "breaking the rules" to get to an objects state.

This is basically how they work in Rust and Go. The key in both of these languages is the use of traits and interfaces to obtain special behavior and polymorphism. Neither of them forces a composite type to be completely public or private though, and Go limits visibility to the package level.

I used to really hate OO, but I started to think about what the parts I really disliked about it, and saw that in Erlang, Haskell, etc there is always a need for an "object" whether it be a GenServer or a Monad. Java and C++ just took the concept too far, and took an absolutist approach that most features need to be part of the OO machinery, although Java is by far the worst. Objects have their place, but they should be just as common as any of other type, and should not be used to think of program structure in most cases.

OO languages work effectively in spite of OO features. Sounds like a hot take, but throw away inheritance altogether (or use it to automatically delegate to some component, like a dodgier version of struct embedding in Go), use interfaces if the language doesn’t support first class functions, etc and you’ll be effective, which is to say, write it like you would write Go or Rust or similar.

I don’t think I’ve ever seen a useful “Getter” abstraction...

That's a bit weird to see a seasoned programmer harboring those views. I remember that when learning OOP I was equally confused. "I can do all that with functions and structures already." And indeed you can. There is nothing you can't technically do without OOP.

OOP is not a programming feature, it is a software engineering feature. It allows for cleaner APIs and higher levels of abstractions. IMO the core feature of OOP is less the ability to bind functions with data but the ability to overload operators.

Sure, you can have functions that have the "this" pointer as the first argument and have exactly the same things. You can add a bunch of flags and have the core features of inheritance.

You can. Now what do you prefer to write, when finding the middle of a 3d segment?

mid = (a + b)/2

or

mid = scalar_division(vector_add(a,b),2)

?

If you allow operators to be overloard, is there any good reason to not place them close to your structure definition? Isn't it a good practice to force these functions to be defined if your structure is?

The core idea of OOP is that it extends the language by allowing to build more abstract concepts in top of lower level abstractions.

That's a core misunderstanding that I keep seeing with low-level programmers. They want to see the implementation details of everything and refuse to obscure some behaviors and trust the libs/compiler makers.

People who spend more time in higher level algorithms can't bother with all the implementation details. When I do DL, I want the ability to concatenate layers of different types (that inherit the same generic type), be able to check their output(), manipulate tensors of floats, assign them a scalar value or multiply them by some.

You can go a very long way without using any kind of OOP and staying at the implementation level. I am actually in awe of how much one can do that way. But OOP is a tool for teams to work together without knowing the details of each other's parts and build increasingly complex abstractions.

There's nothing about operator overloading that requires OOP. Even in C++ you can overload an operator outside a class definition in a free function. For example... https://stackoverflow.com/questions/2425906/operator-overloa...

Also outside of numerical work and some set stuff there's not really that many times you actually need to overload operators.. And you can easily extend languages without objects (Lisp)