> 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.
> 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
> 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.