5 ms·

That's a very interesting observation, that is very much aligned with my own views, but I'll need some time to absorb the details here. I'm myself on the quest

by dpc_pw 6y ago

That's a very interesting observation, that is very much aligned with my own views, but I'll need some time to absorb the details here. I'm myself on the quest to fully understand what is really wrong with OOP and then try to share it with more people. It's actually very hard because it's a complex topic, ridden with subtleties, and even the exact definition of "what is OOP-code" is elusive. I've just recently made a reddit post that you (and other's who find your post interesting) might also enjoy: https://www.reddit.com/r/rust/comments/ju5oqp/how_to_avoid_repetition_without_inheritance/gch4gbp/?context=6 https://www.reddit.com/r/rust/comments/ju5oqp/how_to_avoid_r... I wish there was some "OOP-deniers" community, where we could discuss things like that with an open mindset. Usually discussing OOP degenerates quickly and it's impossible to even establish some shared understanding.

atty 6y ago
I am a little confused about your point - are you saying that OOP is a strictly worse, or has some inherent irredeemable flaw that is not present in other programming styles? Because that’s a statement that would need a lot of supporting evidence, considering the success of OOP over the last 30 years or so. I think a more strongly defensible position is that OOP is not a magic bullet that works for all types of problems, and identifying when and where it is a natural fit is not always obvious.
- dpc_pw 6y ago
  From my experience, the modern Java-style OOP that I've worked with (some of which I produced myself) through all these years leads to terrible code, and all the data-oriented code I've seen and produced seems much, much better in comparison. Other programming styles are often orthogonal. One can have mostly functional OOP and mostly functional data-oriented software, or imperative OOP vs imperative data-oriented software and so on. I'm mostly focused on OOP vs data-orientation. OOP means a fixation on modeling everything as "a graph of encapsulated objects with associated bits of logic calling each other" while data-orientation means: "pure logic decoupled from data, and a data stored and passed in mostly non-abstract, concrete ways to support required computation". The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology tough to people in school. When you look at the actual industry, most of the fundamental, long-lasting software is actually written in some form of data-orientation. From kernels, system tools, things like redis, other databases, etc. Though one could tell that it's because fundamental software is usually system software, and not business-logic software and that's true. I don't have evidence, and it's all just my experience, reasoning and intuition, and I'm intellectually open for debate here, but IMO fundamentally splitting data into small encapsulated chunk that form a graph of native references to each other is just a terrible way to organize any form of computation. I don't want to repeat myself, so please see my reddit post that I linked before for more details.
  - alquemist 6y ago
    The seductive power of OOP has little to do with the technical merits. As you mention data oriented programming leads to better programs. Even when using OOP technology, programs usually tend to become data oriented (hello protos), and 'objects' become glorified pure functions. The big OOP idea is the subject-verb-object interface, confusingly named object-method-arguments. The SVO structure matches the cognitive linguistic bias of the human brain, thus feels obviously right to most humans. Even if better programming alternatives exist. The endless litany of new Verber(args0).verb(args1) is here to stay.
    - dpc_pw 6y ago
      Oh. I find subject-verb-object interface another dimension of debate altogether. Usual it's being mentioned by FP devs, since they are usually very aware of that aspect since they don't get to use it. :D It's not only that SVO is more suited from linguistic reasons. Selecting the "object/doer/subject" first is just a better UX in all sorts of human-interfaces (e.g. games). It allows narrowing down the context naturally, improving discoverability (like auto-completion). Big part of the reason why I switched from Vim to Kakoune. Subject serves the purpose of being a mini namespace/module and context for operations. In a way, I blame FP community for being so stubborn in their mathematically-inclined notation, and not experimenting enough with trying to achieve similar human-friendly notation. But maybe I'm just missing all the historical attempts or something. One of the most interesting spins on the topic is "subject-oriented programming" from Hoon (which is native PL for Urbit OS), where every expression is always evaluated in ever-present implicit subject context, and results in a new subject which will be used for the next expression.
      - alquemist 6y ago
        Speculation. The FP community prizes mathematical beauty, for which symmetry is an important factor. It is simply ugly to promote one function argument (which one?) to a privileged role, even if the linguistic side of the brain screams that's the right thing to do. Re autocomplete, there is no technical reason why auto-complete couldn't trim down the search space based on the arguments of the functions, for example by using reverse polish. But reverse polish is unusual, we really like SVO anyways, and modules as subjects are very useful, if only as an autocomplete anchor, in tooling or in one's brain. OOP/SVO is here to stay for the foreseeable future, and embracing pure functions principle makes it rather pleasant to work with. If only we could decouple 'modules as namespaces' useful idea from all the misguided baggage that comes bundled with OOP, of which the 'active data' antipattern deserves special 'please avoid' mention.
submain 6y ago
One of my problems with OOP is that it is often hard to compose. One could argue that most of the OOP design patterns were made as an attempt to solve that. In FP, composition is done elegantly (at the cost of increased complexity in other areas, such as state management). Scott Wlaschin has a great talk about that: https://www.youtube.com/watch?v=4jusLF_Xz7Q https://www.youtube.com/watch?v=4jusLF_Xz7Q
meheleventyone 6y ago
Probably 90% of the problem is setting yourself up in opposition to OOP at all rather than preaching the gospel of what you consider to be good. Even if you don't have a weak argument it does make your conviction look questionable if the preamble always has to be about how dumb the other thing is. A lot of the criticism of OOP could also use more steelmaning rather than picking on claims that often feel like the opposite.
- dpc_pw 6y ago
  True. Though I guess I don't have a chance to reverse the river made out of a constant stream of developers produced by universities and bootcamps, who think "Cat extends Animal and makes_sound with "meow" and Dog extends Animal and makes_sound with "woof". I'll try to keep it in mind if I'm ever to make a book or something like this about this subject.
  - meheleventyone 6y ago
    Yeah exactly what I mean, if your target is the understanding of OOP that comes out of intro courses at University then it's easy to knock down. To the point even OOP advocates complain about it. Steelmanning for example would be taking successful, performant OOP projects and tackling the way they use it. V8, LLVM or UE4 for example off the top of my head. Steelmanning is realizing that you can write data oriented code in OOP projects. Steelmanning is realizing that you can write an ECS-style database with OOP. It's further realizing that the ECS pattern as described is not inherently data-oriented and requires extension to actually meet that criteria (e.g. archetypes). And to be clear I'm not accusing you of ignoring these things but the discussion around this topic in general. Basically as a game programmer of over 16 years of professional experience I feel a lot of this stuff is dubiously presented. And I don't even like OOP particularly!!
    - dpc_pw 6y ago
      > Steelmanning is realizing that you can write data oriented code in OOP projects. It's going to be arguing about names and definition, but I can't accept that it's OOP, when that put qualifiers on all "4 tenets of OOP", etc. Something like: - Abstraction(*) - Encapsulation(*) - Inheritance(*) - Polymorphism(*) (*) where useful, when necessary, but ... generally avoid. If someone could tell me which book is "The BEST OOP out there, then I would be happy to read it and then argue with it" :D

by dpc_pw 6y ago

atty 6y ago

I am a little confused about your point - are you saying that OOP is a strictly worse, or has some inherent irredeemable flaw that is not present in other programming styles? Because that’s a statement that would need a lot of supporting evidence, considering the success of OOP over the last 30 years or so. I think a more strongly defensible position is that OOP is not a magic bullet that works for all types of problems, and identifying when and where it is a natural fit is not always obvious.

dpc_pw 6y ago
From my experience, the modern Java-style OOP that I've worked with (some of which I produced myself) through all these years leads to terrible code, and all the data-oriented code I've seen and produced seems much, much better in comparison. Other programming styles are often orthogonal. One can have mostly functional OOP and mostly functional data-oriented software, or imperative OOP vs imperative data-oriented software and so on. I'm mostly focused on OOP vs data-orientation. OOP means a fixation on modeling everything as "a graph of encapsulated objects with associated bits of logic calling each other" while data-orientation means: "pure logic decoupled from data, and a data stored and passed in mostly non-abstract, concrete ways to support required computation". The success of OOP is dubious: mostly judged by it's popularity, which is mostly driven by it being a default methodology tough to people in school. When you look at the actual industry, most of the fundamental, long-lasting software is actually written in some form of data-orientation. From kernels, system tools, things like redis, other databases, etc. Though one could tell that it's because fundamental software is usually system software, and not business-logic software and that's true. I don't have evidence, and it's all just my experience, reasoning and intuition, and I'm intellectually open for debate here, but IMO fundamentally splitting data into small encapsulated chunk that form a graph of native references to each other is just a terrible way to organize any form of computation. I don't want to repeat myself, so please see my reddit post that I linked before for more details.
- alquemist 6y ago
  The seductive power of OOP has little to do with the technical merits. As you mention data oriented programming leads to better programs. Even when using OOP technology, programs usually tend to become data oriented (hello protos), and 'objects' become glorified pure functions. The big OOP idea is the subject-verb-object interface, confusingly named object-method-arguments. The SVO structure matches the cognitive linguistic bias of the human brain, thus feels obviously right to most humans. Even if better programming alternatives exist. The endless litany of new Verber(args0).verb(args1) is here to stay.
  - dpc_pw 6y ago
    Oh. I find subject-verb-object interface another dimension of debate altogether. Usual it's being mentioned by FP devs, since they are usually very aware of that aspect since they don't get to use it. :D It's not only that SVO is more suited from linguistic reasons. Selecting the "object/doer/subject" first is just a better UX in all sorts of human-interfaces (e.g. games). It allows narrowing down the context naturally, improving discoverability (like auto-completion). Big part of the reason why I switched from Vim to Kakoune. Subject serves the purpose of being a mini namespace/module and context for operations. In a way, I blame FP community for being so stubborn in their mathematically-inclined notation, and not experimenting enough with trying to achieve similar human-friendly notation. But maybe I'm just missing all the historical attempts or something. One of the most interesting spins on the topic is "subject-oriented programming" from Hoon (which is native PL for Urbit OS), where every expression is always evaluated in ever-present implicit subject context, and results in a new subject which will be used for the next expression.
    - alquemist 6y ago
      Speculation. The FP community prizes mathematical beauty, for which symmetry is an important factor. It is simply ugly to promote one function argument (which one?) to a privileged role, even if the linguistic side of the brain screams that's the right thing to do. Re autocomplete, there is no technical reason why auto-complete couldn't trim down the search space based on the arguments of the functions, for example by using reverse polish. But reverse polish is unusual, we really like SVO anyways, and modules as subjects are very useful, if only as an autocomplete anchor, in tooling or in one's brain. OOP/SVO is here to stay for the foreseeable future, and embracing pure functions principle makes it rather pleasant to work with. If only we could decouple 'modules as namespaces' useful idea from all the misguided baggage that comes bundled with OOP, of which the 'active data' antipattern deserves special 'please avoid' mention.

submain 6y ago

One of my problems with OOP is that it is often hard to compose. One could argue that most of the OOP design patterns were made as an attempt to solve that. In FP, composition is done elegantly (at the cost of increased complexity in other areas, such as state management). Scott Wlaschin has a great talk about that: https://www.youtube.com/watch?v=4jusLF_Xz7Q https://www.youtube.com/watch?v=4jusLF_Xz7Q

meheleventyone 6y ago

Probably 90% of the problem is setting yourself up in opposition to OOP at all rather than preaching the gospel of what you consider to be good. Even if you don't have a weak argument it does make your conviction look questionable if the preamble always has to be about how dumb the other thing is. A lot of the criticism of OOP could also use more steelmaning rather than picking on claims that often feel like the opposite.

dpc_pw 6y ago
True. Though I guess I don't have a chance to reverse the river made out of a constant stream of developers produced by universities and bootcamps, who think "Cat extends Animal and makes_sound with "meow" and Dog extends Animal and makes_sound with "woof". I'll try to keep it in mind if I'm ever to make a book or something like this about this subject.
- meheleventyone 6y ago
  Yeah exactly what I mean, if your target is the understanding of OOP that comes out of intro courses at University then it's easy to knock down. To the point even OOP advocates complain about it. Steelmanning for example would be taking successful, performant OOP projects and tackling the way they use it. V8, LLVM or UE4 for example off the top of my head. Steelmanning is realizing that you can write data oriented code in OOP projects. Steelmanning is realizing that you can write an ECS-style database with OOP. It's further realizing that the ECS pattern as described is not inherently data-oriented and requires extension to actually meet that criteria (e.g. archetypes). And to be clear I'm not accusing you of ignoring these things but the discussion around this topic in general. Basically as a game programmer of over 16 years of professional experience I feel a lot of this stuff is dubiously presented. And I don't even like OOP particularly!!
  - dpc_pw 6y ago
    > Steelmanning is realizing that you can write data oriented code in OOP projects. It's going to be arguing about names and definition, but I can't accept that it's OOP, when that put qualifiers on all "4 tenets of OOP", etc. Something like: - Abstraction(*) - Encapsulation(*) - Inheritance(*) - Polymorphism(*) (*) where useful, when necessary, but ... generally avoid. If someone could tell me which book is "The BEST OOP out there, then I would be happy to read it and then argue with it" :D