That's the exact premise of Scala, by the way: more object-oriented than most object-oriented languages (including Java), and yet enabling functional programming.
OO gets you a long way, still there are interesting approaches being tried with data-driven programming through either composing lenses and ECS. I have a hard time understanding lenses, seems like a lot of work to reproduce the most strait-forward concept in OO (getters and setters). ECS do away with object and give you almost like a relational database, but it is cumbersome to encode hierarchies, but they do offer a way for non-code tools to interface with code which is important too.
Lenses solve a problem you don't have in OOP. Since OOP allows mutation, to change a value within a nested structure, just mutate it. If you don't want to mutate, then getters and setters don't help and changing nested structures is awkward.
Lenses solve the nested mutation problem for immutable structures but then go past what you can do with getters and setters. For example, you can compose bigger lenses out of smaller ones.
If ECS' Systems are querying Entities / Components the way one would use a SQL query in a relational database, what's needed for hierarchies is the ECS equivalent of a graph database.
The good parts of AppKit (which most OOP frameworks are based on) wasn't just that it came with nouny objects representing controls, it's that it used the "hard and soft layer" pattern with messaging and notifications. Which is not C++-style OOP.
Most of the even more OO frameworks around the same time, like Taligent, failed.
Of course it did win over procedural frameworks like classic MacOS, but some of those are still popular in games or embedded systems.
I assume you are talking about React. It started fairly OOP. Now it's... something else? It's not functional. IMHO hooks and effects are a crazy form of OOP. It's like some weird dynamic scope data definition.
Ah, that does make more sense, and is a language feature I've often thought about. It's usually just a pattern and not a first class feature, but with many problems as a result (many of which React itself encounters).
Lots of use of context managers in Python are for accomplishing this. Smalltalk error handlers are like this (different than try/catch). Or Scheme's with-output-to-file... I got the sense that variables that start and end with stars in Common Lisp are used for this, but I was never clear if it was convention or an actual language feature.
I think I'd like it in React too if they just hadn't tried to be so clever.
Isn't this basically the same tradeoff as Contexts vs Prop-Drilling?
You could achieve the same effects by passing down callbacks.
I thought the reason why this is good for Errors, Themes and Loading (Suspense), is because they're so common, that you can always expect someone up in the hierarchy to consider it, and therefore sacrifice some type safety for less verbosity.
The article mentions that "usually the fact that a function can perform an effect would be encoded into its type signature", which is why I don't understand the need in this example.
Running a function and then looking for magical side effects to effectively get multiple return values from that function sure isn't functional. And it shows in how unintuitive it is to reason about hooks and the leakiness of the whole thing.
I think it looks functional because it's only easy to reason about if you write functional code.
I suppose it tries to solve some of the same problems as OO, like related state and private transitions. But it feels like React itself is the God Object.
React, presumably, with its approach that a UI is well described by nested functions operating on state. It's a good point. I remember long discussions on mailing lists for various FP languages conceding that UI toolkits were the one area where OOP seemed the natural fit. Haven't seen many of those discussions since React emerged.
Switch it to a state with the methods and you got your object. Polymorphism here is not a requirement. It is a feature to be used when needed. Some time in the 80s I was doing exactly the same - operating on state with functions. Same shit different color.
Programmers just love going on crusades. I find it a waste of time and intolerance breeding ground. Instead of heating the air use whatever the fuck suits one. Just do not stalk other people who happen to have different preferences.
Ah that one. Sorry but in my book React is an abomination. Speed of developing decent UI in React vs for example something like ages old Delphi is incomparable. The last one wins hands down.
They guy who hammers nails all day thinks screwdrivers are worthless.