4 ms·

OOP is a great fit for UI frameworks. OOP is a bad fit for many other things. They guy who hammers nails all day thinks screwdrivers are worthless.

wrnr 5y ago
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.
- garethrowlands 5y ago
  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.
- ummonk 5y ago
  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.
akavi 5y ago
> OOP is a great fit for UI frameworks. The biggest UI framework of the past decade is decisively anti-OOP in its philosophy
- FpUser 5y ago
  What it the name?
  - bspammer 5y ago
    https://reactjs.org/ https://reactjs.org/
  - paragraft 5y ago
    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.
    - FpUser 5y ago
      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.
    - FpUser 5y ago
      >" nested functions operating on state." 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.
  - garethrowlands 5y ago
    React
- ianbicking 5y ago
  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.
  - eunoia 5y ago
    Honest question, I’m very curious. Do you still classify React as closer to an OO paradigm than functional? Agreed hooks are… something else.
    - ianbicking 5y ago
      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.
  - joeldo 5y ago
    I'm not exactly sure how hooks are related to OOP. Their design was inspired by 'Algebraic Effects' which are more functional in nature than OO. This gives a good breakdown: https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/
    - ianbicking 5y ago
      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.
astrange 5y ago
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.
cutler 5y ago
John Carmack came to the opposite view in the end (https://web.archive.org/web/20130819160454/http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ https://web.archive.org/web/20130819160454/http://www.altdev...), favouring pure functions and immutability above all else.
- waynecochran 5y ago
  OOP and functional programming are orthogonal -- you can do both ...
  - ebruchez 5y ago
    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.

wrnr 5y ago

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.

garethrowlands 5y ago
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.
ummonk 5y ago
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.

akavi 5y ago

> OOP is a great fit for UI frameworks. The biggest UI framework of the past decade is decisively anti-OOP in its philosophy

FpUser 5y ago
What it the name?
- bspammer 5y ago
  https://reactjs.org/ https://reactjs.org/
- paragraft 5y ago
  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.
  - FpUser 5y ago
    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.
  - FpUser 5y ago
    >" nested functions operating on state." 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.
- garethrowlands 5y ago
  React
ianbicking 5y ago
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.
- eunoia 5y ago
  Honest question, I’m very curious. Do you still classify React as closer to an OO paradigm than functional? Agreed hooks are… something else.
  - ianbicking 5y ago
    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.
- joeldo 5y ago
  I'm not exactly sure how hooks are related to OOP. Their design was inspired by 'Algebraic Effects' which are more functional in nature than OO. This gives a good breakdown: https://overreacted.io/algebraic-effects-for-the-rest-of-us/ https://overreacted.io/algebraic-effects-for-the-rest-of-us/
  - ianbicking 5y ago
    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.

astrange 5y ago

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.

cutler 5y ago

John Carmack came to the opposite view in the end (https://web.archive.org/web/20130819160454/http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ https://web.archive.org/web/20130819160454/http://www.altdev...), favouring pure functions and immutability above all else.

waynecochran 5y ago
OOP and functional programming are orthogonal -- you can do both ...
- ebruchez 5y ago
  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.