Merging data and behaviour into a single unit (the core idea behind OOP) is literally impossible to do in practice.
Just imagine "sending a message to an int to send a copy of itself to a HTTP server" or "send a message to an array of colors to raytrace itself" or "send a message to a file asking it to sort itself and render itself in 3D".
The problem is that everything will literally end up depending on everything. A perfect implementation of the ultimate spaghetti code.
In contrast, split the code into Data, Dumper, Reader, Writer, Verifier, Renderer, Editor etc. modules (or classes used as modules) and the code is simple to understand with zero circular dependencies. And it works for any language including non-OO languages.
> If this is such a great approach, why are some people moving away from it?
My answer is because forcing a type hierarchy, and having to declare where every type belongs in it, is a PITA. Duck typing is far more flexible and good enough imo
Good developers been moving away from it for a long time, and for a bunch of good reasons. OOP-paradigm promised "easy abstractions" at the time when majority of programmers were autodidacts with no solid math and CS background. Instead, that quickly became "institutionalized complexity".
Java, circa 1998, had no first-class functions, no free functions, one public class per file. Every abstraction had to be a class, so every idiom became a class, and then frameworks arrived to generate the classes. That's where we ended up having shit like AbstractSingletonProxyFactoryBean. Add consulting and UML industry had a commercial interest in the ceremony being teachable and billable.
Gosling called it "a blue-collar language, not PhD thesis material" and we started making languages with designs that deliberately distance themselves from math, as if that was the point. But does anyone even remember how it all started? Fortran meant "formula translation" and targeted scientists. ALGOL 60 was designed by mathematicians and specified in BNF. Lisp landed nicely into Church's lambda calculus. The math tradition was there from the start and dominated academia the entire time. Nobody hid it, nobody shied away.
Then instead of simply reminding people "what a mathematical function is" mainstream languages withheld first-class functions for about thirty years after Lisp shipped them, and Java's omission alone generated a decades of pattern ceremony to work around it. That's real, costly, and hard-to-justify. Even today. Yes, sure maybe it wasn't really a plot to spare the self-taught programmers - a mathematical function is total and pure and you can't really piggyback on centuries of mathematics for effects, because effects were not in it. Yet we did pay huge price for distancing ourselves from functions being first class citizens.
And then we still debate and throw half-baked articles like this one, that outright starts with wrong facts "Go and Rust, don’t support it at all". What Rust and Go dropped is inheritance and class hierarchies, but that's not what defines OOP. And the author skips on the real tradeoffs: the expression problem, mutable shared state under concurrency - where most modern hostility to OOP actually comes from. And message-passing lineage the post invokes, says nothing about Smalltalk and Erlang... wtf?
What is the article actually "defending"? From what I'm reading it's defending only encapsulation, but without mentioning the word explicitly even once. But that is broad enough to include Go, Rust, ML modules and Clojure protocols. Where's any arguments for inheritance, class hierarchies, subtype polymorphism, object identity, all that pattern ceremony? Ah, of course, because there's nothing to "defend" there.
> Some newer programming languages, like Go and Rust, don’t support it at all
They clearly do support OOP, the only difference is that it isn't the traditional class based OOP from Smalltalk and Java.
I have coded the Peter Shirley's raytracing tutorial using Rust with exactly the same OOP architecture as the tutorial, based on traits.
Merging data and behaviour into a single unit (the core idea behind OOP) is literally impossible to do in practice.
Just imagine "sending a message to an int to send a copy of itself to a HTTP server" or "send a message to an array of colors to raytrace itself" or "send a message to a file asking it to sort itself and render itself in 3D".
The problem is that everything will literally end up depending on everything. A perfect implementation of the ultimate spaghetti code.
In contrast, split the code into Data, Dumper, Reader, Writer, Verifier, Renderer, Editor etc. modules (or classes used as modules) and the code is simple to understand with zero circular dependencies. And it works for any language including non-OO languages.
> If this is such a great approach, why are some people moving away from it?
My answer is because forcing a type hierarchy, and having to declare where every type belongs in it, is a PITA. Duck typing is far more flexible and good enough imo
> My answer is because forcing a type hierarchy
I happily work in typed languages and nobody is forcing me to create any type hierarchies.
> why are some people moving away from it?
Good developers been moving away from it for a long time, and for a bunch of good reasons. OOP-paradigm promised "easy abstractions" at the time when majority of programmers were autodidacts with no solid math and CS background. Instead, that quickly became "institutionalized complexity".
Java, circa 1998, had no first-class functions, no free functions, one public class per file. Every abstraction had to be a class, so every idiom became a class, and then frameworks arrived to generate the classes. That's where we ended up having shit like AbstractSingletonProxyFactoryBean. Add consulting and UML industry had a commercial interest in the ceremony being teachable and billable.
Gosling called it "a blue-collar language, not PhD thesis material" and we started making languages with designs that deliberately distance themselves from math, as if that was the point. But does anyone even remember how it all started? Fortran meant "formula translation" and targeted scientists. ALGOL 60 was designed by mathematicians and specified in BNF. Lisp landed nicely into Church's lambda calculus. The math tradition was there from the start and dominated academia the entire time. Nobody hid it, nobody shied away.
Then instead of simply reminding people "what a mathematical function is" mainstream languages withheld first-class functions for about thirty years after Lisp shipped them, and Java's omission alone generated a decades of pattern ceremony to work around it. That's real, costly, and hard-to-justify. Even today. Yes, sure maybe it wasn't really a plot to spare the self-taught programmers - a mathematical function is total and pure and you can't really piggyback on centuries of mathematics for effects, because effects were not in it. Yet we did pay huge price for distancing ourselves from functions being first class citizens.
And then we still debate and throw half-baked articles like this one, that outright starts with wrong facts "Go and Rust, don’t support it at all". What Rust and Go dropped is inheritance and class hierarchies, but that's not what defines OOP. And the author skips on the real tradeoffs: the expression problem, mutable shared state under concurrency - where most modern hostility to OOP actually comes from. And message-passing lineage the post invokes, says nothing about Smalltalk and Erlang... wtf?
What is the article actually "defending"? From what I'm reading it's defending only encapsulation, but without mentioning the word explicitly even once. But that is broad enough to include Go, Rust, ML modules and Clojure protocols. Where's any arguments for inheritance, class hierarchies, subtype polymorphism, object identity, all that pattern ceremony? Ah, of course, because there's nothing to "defend" there.