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.
So, it should be clear that OO is not a tool for any problem.
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:
Plain functions
Plain object literals
Compose functions and object literals to get objects with "methods"
Practising my Javascript fu. So far my JS has done what exactly what I expected - funny really I was expecting problems - the trick is to use no frameworks or libraries.
@bartekus
@joeerl forget empty, adding arrays in JS is weird, from any other lang where + results in an array with all elements from both arrays, or simply disallows + on arrays, to this... JS has quirks & can't evolve as easily as other langs because browser fragmentation. (well babel, but...) https://t.co/gtyJFelmVQ
but we should talk more about how people can benefit most of a concept.
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.
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?
Nice to hear that somebody knows "the right way", this usually is more the attitude of a missionar than of an engineer.
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.
For me, OO was one concept to build maintainable logical segments of code.
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.
A second reason to use classes was the ability to keep the namespace tidy
And in JavasScript ECMASCript modules work much better for that purpose. They were introduced with ES2015 (i.e. when class became 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.
I really wonder, how people solve these issues with pure functional programming?
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".
A rules engine is all about providing an alternative computational model. Instead of the usual imperative model, which consists of commands in sequence with conditionals and loops ... rules, each of which has a condition and an action - simplistically you can think of it as a bunch of if-then statements.
i.e.:
Selector lists act as conditions.
Property lists act as actions.
Specificity and source order govern rule priority.
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).
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.
.
While the theory was good on paper, the practice is that only ads and ads providers somehow benefit from this technology
they will need state dependent styling. Yes, you are right, CSS features a top down approach that does not fit to this task.
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.
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 …
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 …