Joe Armstrong, the principal inventor of Erlang, is quoted as saying: "The problem with object-oriented languages is they've got all this implicit ...
For further actions, you may consider blocking this person and/or reporting abuse
Every paradigm comes at it´s price. So, it should be clear that OO is not a tool for any problem. Usually it is more work to solve a problem based on classes and we have to decide, if this really pays back.
You can write multithreaded code based on classes. Think of a life game, where every cell is an object. But, you have to be very carefull to avoid typical multithreading problems. I suppose, this would be easier using pure functions.
Sure, every concept has it´s drawbacks, but we should talk more about how people can benefit most of a concept.
The issue is that the mainstream often does not even consider exploring other, perhaps less complex options besides class-based object orientation - Java presented a world view where "class" is the atom that every software product is based on.
In JavaScript things are a bit different:
So I guess if classes are atoms, functions and object literals are quanta.
Function-oriented
You don't need classes
Thinking like an Erlanger - Game of Life
A balanced view requires an honest review of all the trade offs.
These days class-based OOP is often practiced without scrutiny because its practitioners don't explore other approaches or the tooling that shapes their workflow masks the downsides until it's too late.
Before OO became more widely adopted, "structured programming" was practiced just as mindlessly.
Meanwhile Go has down-leveled OO back to the days of C Interfaces and Implementations (1996) and Rust has adopted a largely expression based (i.e. value oriented) syntax (Implementing an Object-Oriented Design Pattern).
And James O. Coplien feels that Data, Context, Interaction (DCI) is the right way to go "full OO".
Nice to hear that somebody knows "the right way", this usually is more the attitude of a missionar than of an engineer. As long as we do not talk about a certain problem to solve, I think there is no right way at all...
For me, OO was one concept to build maintainable logical segments of code. As long as you keep the interface small and well defined, a class can be developed relatively independently by a separate team.
A second reason to use classes was the ability to keep the namespace tidy. Each class has it´s own namespace and it is easy to avoid any conflicts.
Both things apply to larger projects rather to small applications.
I really wonder, how people solve these issues with pure functional programming?
Sure but his rants are always fun to watch especially as there usually is a grain of truth to them. And evangelist or not - he does touch on some downsides of the classic approach that most practitioners wouldn't even think of.
Correct when contrasted to structured programming as it was practiced at the time - however that doesn't change that class-based OO is essentially managing complexity with complexity rather than simplifying the overall approach.
Aside: Kevlin Henney: The Forgotten Art of Structured Programming
And in JavasScript ECMASCript modules work much better for that purpose. They were introduced with ES2015 (i.e. when
classbecame available) and even before that function closures and object literals were used to emulate them.Another issue is hat OOPLs use classes as a surrogate for a proper type system. "Types" don't conflate data with behaviour the way classes do.
Scott Wlaschin:
By the way, the concept of CSS should give any functional programmer a heart attack. Never heard one of the evangelists complain about that?
CSS has nothing to do with functional programming. You are correct that neither an OO or functional mindset is helpful - but that doesn't mean that CSS isn't "fit for purpose".
Martin Fowler Bliki: RulesEngine:
i.e.:
So in writing CSS you are composing rules for a domain specific rules engine (the layout engine) which drives the visual design of the page.
To understand CSS better I'd look into the Inverted Triangle CSS architecture. It makes clear that CSS works from the top down specifying rules that specify the global look and feel - then adding more rules where necessary to override the global settings for more local requirements (Google's web.dev uses it).
CSS Is Certainly Global And That’s Exactly The Point
The entire CSS-in-JS and styled-components movement fails to account for the fact that layout, visual styling and CSS works top-down - not bottom-up.
Keith J. Grant:
The problem is that people are familiar and comfortable with component approaches even when they are a "square peg in a round hole".
No - it's just that many people don't want to but in the effort to
and rather preserve at all costs the ways which they are already comfortable working with.
Front end and back end
Static page performance is the gold standard
From what I can see, people do far more with CSS today than styling the corners of a button. If you where true, why did they invent the shadow dom then?
The more people start to create applications on the web, they will need state dependent styling. Yes, you are right, CSS features a top down approach that does not fit to this task.
.
About Web Components - Why Shadow DOM?:
On the simplest level that is accomplished by adding and removing CSS classes but even techniques like quantity queries are available. So the "component" has control of the class names on the DOM elements to reflect visual state but the top-down styles get to actually act on it - because layout and visual design has to be orchestrated as a whole.
"We all love the Web, but in stories like this one, it feels like the Web doesn’t really love us back … or not as much"
And Andrea Giammarchi has been at it (the web) since before 2006 - and he will keep at it for the foreseeable future. Got to admire that but if that's what it takes …
So don't use "class-based object orientation" unless there is a clear indicator that it will help to solve your problem. It should not be the default approach.
However there is the mainstream attitude that OO is the best tool for any problem simply because it was declared to be better than structured programming in the late 1980's to early 1990's.
Meanwhile technology has moved on and made some of OO's trade offs into liabilities.
Going through Arthur Riel's OOD heuristics (1996) it becomes clear that OO is an approach that manages complexity with complexity. Meanwhile encapsulation doesn't address one core problem:
Mindless mutability and side effects weren't an issue in single thread environments (Thinking Outside the Synchronisation Quadrant) but given that Moore's law is done, software increasingly has to distribute processing tasks across multiple threads, if not multiple cores.
Even many client side web applications running on mobile client devices today are constrained by the legacy single thread model (single core performance was how the web was built) adopted by current frameworks despite the fact that it is becoming more common for devices to feature multiple but lower power cores.
It isn't that functional programming is fundamentally better - however immutability does limit the possibility that something shared is going to unexpectedly change and it forces a style of processing that relies less on sharing values but more on creating new ones.
Value-oriented programming tends to be simpler than place-oriented programming (PLOP) even when PLOP seems initially easier.
The fundamental tenet seems to be:
PLOP still has its place but when performance actually counts OO is overhead.
Data-Oriented Design: Mapping the problem (2018):
So more than a decade ago part of the game industry abandoned object-orientation as a design time representation and embraced a different approach - Entities, components and systems ECS - aligned with the "machine" rather than the problem domain.
Even in 1994 the "Gang of Four" design patterns book stated (p.20):
Classes are types but not all types are classes. Classes are not a substitute for types. Polymorphism is about types, not classes (The SOLID Design Principles Deconstructed). So to get polymorphism one does not need OO - just a good type system, preferably one with abstract data types.
Conclusion: Only adopt "class orientation" which is typically mislabelled as "object orientation" if there is a clear benefit to doing so.
"class-based object orientation" carries an inherent complexity which is only appropriate for limited types of problems. Given that this article has a JavaScript tag it needs to be understood that an awful lot of work can be accomplished with just functions, object literals and modules (in my opinion a far more important addition to ES2015 than class).
That said when working with custom elements one really doesn't have much choice because
class MyElement extends HTMLElementis just how it works.Joe Armstrong's Banana/Gorilla/Jungle criticism was his polite opinion. Why OO sucks dug a bit deeper into his position.
In an interview in 2010 he stated:
Finally in 2019 Alan Kay stated:
So it seems that from Armstrong's perspective Simula 67-derived "class-based object-orientation" lead the industry down the garden path.
If you are interested in exploring functional programming for yourself then keep an eye on Introduction to Functional Programming in OCaml (twitter) just in case they start another session in September/October.
Why OCaml?
Who's using it? (example: Jane Street).
While it's unlikely that most people will ever earn money with OCaml it's a good basis for other dialects like F# (.NET; Scott Wlaschin: F# for Fun an Profit, Domain Modeling Made Functional) and ReScript (front end).
Personally I think learning functional programming with OCaml is a bit harder than with Erlang (twitter) but it comes at a good trade off because that additional difficulty comes from being statically typed (with a sound type system) and is mitigated by excellent type inference.
But OCaml is also more practical and therefore easier than Haskell (twitter) because functional purity is not dogmatically pursued (i.e. immutable by default but there are escape hatches), there is no laziness to deal with and monads and category theory don't come up at every turn.