3 ms·

> There are many paradigms and each one has its place. That's a thought-terminating cliché. The argument against inheritance has been laid out pretty clearly.

by bccdee 11mo ago

> There are many paradigms and each one has its place. That's a thought-terminating cliché. The argument against inheritance has been laid out pretty clearly. It's reasonable to rebut that argument. It's not reasonable to say, "you shouldn't criticize inheritance because Everything Has Its Place." Everything does not have its place. Sometimes we discover that something is harmful and we just stop using it.

bigstrat2003 11mo ago
> Sometimes we discover that something is harmful and we just stop using it. And that is not remotely the case here. So yeah, there are many paradigms and each has its place.
- bccdee 11mo ago
  > And that is not remotely the case here. Isn't it? People have written extensively about why we should prefer composition to inheritance, and you haven't mounted any defence of inheritance beyond the thought-terminating cliché that it "has its place."
  - FpUser 11mo ago
    I use both where choosing what I believe is appropriate for particular case. Frankly I do not give rat's ass about what "People have written extensively". From what I read most of it sounds like spoken by politician: look Jimmy, someone can do a bad thing with it. Well fuckin don't do a bad thing. So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper. >"you haven't mounted any defense" Why would I bother. It does not need a defense. It is like do not use Java because it encourages FactoryFactoryFactory, 20 level of abstraction etc. Well it does not. Architecture astronauts do it and I am not one of those
    - bccdee 11mo ago
      > So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper. I don't think so. "Having" vs "being" are descended from an overly simulationist notion of program design. The fact that John has a key in real life does not suggest that this relationship should be represented by an object John which owns an object Key. I think this kind of ontological approach is behind a lot of bad object-oriented design. > Architecture astronauts do it and I am not one of those This is the same rationale used to defend memory-unsafe languages. I like that as a point of comparison because we can actually measure the relationship between the use of memory-unsafe languages and the number of dangerous memory vulnerabilities that show up even in highly-scrutinized code bases like the Linux kernel. "I write good code" doesn't fly; bad code is getting written, and the tools we have to correct that are our languages and paradigms. > Why would I bother. It does not need a defense. If we take our craft seriously, we need to be able to discuss the merits and drawbacks of our tools without getting defensive and refusing to engage. I'm not saying you have to defend it to me—I'm just some guy online—but if you're disinterested in defending it in general, I think that's a craft issue.
      - FpUser 11mo ago
        >"The fact that John has a key in real life does not suggest that this relationship should be represented by an object" Exactly and that is my point. If you came up with the set of real business entities, their interaction rules and constraints we would have something to discuss and as a curious person and former scientist I would enjoy it. However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value. I do not waste my time on abstract statements taken out of any real life context >"This is the same rationale used to defend memory-unsafe languages." Total BS. What one has to do with the other. And even with memory safe languages it is extreme generalization on your side. Come to a company whose life depends on software running their business that had worked for years without problems and was written in say C++ and tell them that they're "holding it wrong" and must "rewrite it in Rust". >"If we take our craft seriously, we need to be able to discuss the merits and drawbacks of our tools without getting defensive and refusing to engage" I do take my craft seriously and my craft is to design and implement robust solutions for clients, bring them value and get paid for delivering said value. I do not find arguing abstract concepts disregarding of particular situation having much value.
  - lucketone 11mo ago
    - Wording uses “prefer”, not “forbid”. - (java) Least interesting example to rebuke “never”: exceptions, interfaces. - (java) inheritance is used by active and successful projects (e.g. junit5, spring framework). I would argue that success is a pragmatic vindication criteria of a tool/technology.
    - bccdee 11mo ago
      True; I suppose I could concede the idea that inheritance has its place if we recognize that that place is quite small and out-of-the-way. My problem is that "everything has its place," without any qualifications, is effectively a blank cheque to use inheritance anywhere and then just go, "well that was its place." Interfaces are great; I wouldn't consider them inheritance. Sure, good stuff has been written with inheritance, but good stuff has been written with C, and that doesn't make C unproblematic. If Postgres were being written today, the authors would probably choose something other than C—we just have better, safer languages for that kind of work now.
      - FpUser 11mo ago
        >"if we recognize that that place is quite small and out-of-the-way" True Scotsman
FpUser 11mo ago
>""you shouldn't criticize inheritance" I was not talking about criticizing. Valid critique us useful and deserved. And this concerns composition as well as any other area. I was talking about crusades by programmers.
lucketone 11mo ago
Em.. I’m quite nitpicky and want to do the opposite of “thought-terminating”. I’m for encouraging best practice, but most things do have its place. I present to this court two examples:“premature optimisation is root of all evil” and “goto statement considered harmful”. Both well accepted as things should be avoided for good reasons (incl. but not limited to, preserving sanity of coworkers) But both definitely “have its place”. First one’s place is legitimized (with nuance) by author himself in second part of same sentence. The latter one (goto) is routinely used by linux devs (random example: https://github.com/torvalds/linux/blob/master/fs/ext4/balloc.c#L419 https://github.com/torvalds/linux/blob/master/fs/ext4/balloc...) > we just stop using it. We minimise/restrict the usage.

by bccdee 11mo ago

bigstrat2003 11mo ago

> Sometimes we discover that something is harmful and we just stop using it. And that is not remotely the case here. So yeah, there are many paradigms and each has its place.

bccdee 11mo ago
> And that is not remotely the case here. Isn't it? People have written extensively about why we should prefer composition to inheritance, and you haven't mounted any defence of inheritance beyond the thought-terminating cliché that it "has its place."
- FpUser 11mo ago
  I use both where choosing what I believe is appropriate for particular case. Frankly I do not give rat's ass about what "People have written extensively". From what I read most of it sounds like spoken by politician: look Jimmy, someone can do a bad thing with it. Well fuckin don't do a bad thing. So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper. >"you haven't mounted any defense" Why would I bother. It does not need a defense. It is like do not use Java because it encourages FactoryFactoryFactory, 20 level of abstraction etc. Well it does not. Architecture astronauts do it and I am not one of those
  - bccdee 11mo ago
    > So much over very simple and primitive thing: John HAS a key vs dog IS an animal. Both are valid and proper. I don't think so. "Having" vs "being" are descended from an overly simulationist notion of program design. The fact that John has a key in real life does not suggest that this relationship should be represented by an object John which owns an object Key. I think this kind of ontological approach is behind a lot of bad object-oriented design. > Architecture astronauts do it and I am not one of those This is the same rationale used to defend memory-unsafe languages. I like that as a point of comparison because we can actually measure the relationship between the use of memory-unsafe languages and the number of dangerous memory vulnerabilities that show up even in highly-scrutinized code bases like the Linux kernel. "I write good code" doesn't fly; bad code is getting written, and the tools we have to correct that are our languages and paradigms. > Why would I bother. It does not need a defense. If we take our craft seriously, we need to be able to discuss the merits and drawbacks of our tools without getting defensive and refusing to engage. I'm not saying you have to defend it to me—I'm just some guy online—but if you're disinterested in defending it in general, I think that's a craft issue.
    - FpUser 11mo ago
      >"The fact that John has a key in real life does not suggest that this relationship should be represented by an object" Exactly and that is my point. If you came up with the set of real business entities, their interaction rules and constraints we would have something to discuss and as a curious person and former scientist I would enjoy it. However blanket statements like "one should not use XYZ some abstract community thinks so" to me have near zero value. I do not waste my time on abstract statements taken out of any real life context >"This is the same rationale used to defend memory-unsafe languages." Total BS. What one has to do with the other. And even with memory safe languages it is extreme generalization on your side. Come to a company whose life depends on software running their business that had worked for years without problems and was written in say C++ and tell them that they're "holding it wrong" and must "rewrite it in Rust". >"If we take our craft seriously, we need to be able to discuss the merits and drawbacks of our tools without getting defensive and refusing to engage" I do take my craft seriously and my craft is to design and implement robust solutions for clients, bring them value and get paid for delivering said value. I do not find arguing abstract concepts disregarding of particular situation having much value.
- lucketone 11mo ago
  - Wording uses “prefer”, not “forbid”. - (java) Least interesting example to rebuke “never”: exceptions, interfaces. - (java) inheritance is used by active and successful projects (e.g. junit5, spring framework). I would argue that success is a pragmatic vindication criteria of a tool/technology.
  - bccdee 11mo ago
    True; I suppose I could concede the idea that inheritance has its place if we recognize that that place is quite small and out-of-the-way. My problem is that "everything has its place," without any qualifications, is effectively a blank cheque to use inheritance anywhere and then just go, "well that was its place." Interfaces are great; I wouldn't consider them inheritance. Sure, good stuff has been written with inheritance, but good stuff has been written with C, and that doesn't make C unproblematic. If Postgres were being written today, the authors would probably choose something other than C—we just have better, safer languages for that kind of work now.
    - FpUser 11mo ago
      >"if we recognize that that place is quite small and out-of-the-way" True Scotsman

FpUser 11mo ago

>""you shouldn't criticize inheritance" I was not talking about criticizing. Valid critique us useful and deserved. And this concerns composition as well as any other area. I was talking about crusades by programmers.

lucketone 11mo ago

Em.. I’m quite nitpicky and want to do the opposite of “thought-terminating”. I’m for encouraging best practice, but most things do have its place. I present to this court two examples:“premature optimisation is root of all evil” and “goto statement considered harmful”. Both well accepted as things should be avoided for good reasons (incl. but not limited to, preserving sanity of coworkers) But both definitely “have its place”. First one’s place is legitimized (with nuance) by author himself in second part of same sentence. The latter one (goto) is routinely used by linux devs (random example: https://github.com/torvalds/linux/blob/master/fs/ext4/balloc.c#L419 https://github.com/torvalds/linux/blob/master/fs/ext4/balloc...) > we just stop using it. We minimise/restrict the usage.