3 ms·

When I’m in student mode, I do think to myself “how much of what I’m reading/hearing is from direct observation and thought, and how much is (conveniently) not

When I’m in student mode, I do think to myself “how much of what I’m reading/hearing is from direct observation and thought, and how much is (conveniently) not as well considered?” I read authoritative stuff such as what is highlighted in parent comment all the time in my studies. It makes sense, since that’s the voice we expect educators in info sharing contexts to have. But like… We “know” today that inheritance leads to bad outcomes… But what would have to be true in a student to be able to “know” this back then? To ask differently, what am I learning today that will be seen as a mistake over time? I’ve learned over time to listen when being educated and be very critical when attempting to integrate knowledge.

aryehof 5y ago
> We “know” today that inheritance leads to bad outcomes… Inheritance used inappropriately likely leads to bad outcomes. Knowing when that is the case makes one a good programmer, not popular opinion.
- gmfawcett 5y ago
  You're missing the point. He's wondering how a student would assess this, not an experienced programmer. A student generally assumes that their instructor's opinion is informed.
  - voakbasda 5y ago
    > A student generally assumes that their instructor's opinion is informed. The first thing a student should learn is that teachers are not infallible. Question authority. Doubt everything.
    - dgb23 5y ago
      That’s what teachers typically say too. At least the one’s I respected most.
- raldi 5y ago
  This also reads like social commentary :)
Jtsummers 5y ago
Hopefully a good student wouldn't stop listening at that point, because the rest of the linked paper describes how to clean things up precisely because an overdependence on inheritance can create bad outcomes. Quoting from the discussion at the end that GP apparently failed to read: > In our aggregation pattern we discuss how inheritance is overused and sometimes is incorrectly used. Our pattern addresses how to fix one common misuse of inheritance - but in proposing this pattern, are we (improperly) encouraging an undisciplined use of inheritance, with the idea that one can "fix things later"? We think not. As noted earlier, "is-a" relationships are not always clearly distinct from "has-a" relationships. Points of view change over time, which does not imply that the original use on inheritance was incorrect. In fact, they're addressing your concern in their own document! Does encouraging early use of inheritance with the intent to refactor later (when you actually know what you're building) cause problems? They don't think so, but that's an opinion born (presumably) from their own experience. Yours may be different, mine hasn't been. Their discussed model has you (somewhat) abuse inheritance early, while prototyping, and then lists several ways to change the structure of the program once you properly understand the model you're implementing.
- dgb23 5y ago
  > Quoting from the discussion at the end that GP apparently failed to read What implies that? The quote I gave hints at exactly the stuff you are discussing here.
  - Jtsummers 5y ago
    Your "Well it turns out..." part is what threw off my reading of your comment. That turn of phrase is usually meant to imply that the preceding is, in some way, bogus. If that's not what you intended, I apologize. But it's how it reads to me. Under that reading, it really seems you stopped at that point in the text and didn't continue to where the authors talk about why stopping at that point in the program development is problematic and how to correct it (the later sections).
    - dgb23 5y ago
dgb23 5y ago
> But what would have to be true in a student to be able to “know” this back then? By studying! A hint is right there at the end of the quote I provided: > The resulting subclasses are not yet truly general. More desirable, from a software maintenance standpoint, would be an inheritance hierarchy that models a type hierarchy This implies that the common approach at the time in OO introduced too much unnecessary coupling. And at the time and before that, there were already approaches being explored that avoided this in some way or another. Another way is to just as basic questions: What does this try to achieve? What problem does it solve? Why do they think it is a problem? How is it implemented? Can this be achieved/solved with a different implementation? Can this be achieved by removing something, like an assumption/perceived requirement or dependency? Here is a simple example for illustration: JavaScript at some point introduced syntax for classes. A relatively common "compiles to JS" language was CoffeeScript at the time, which had classes. Ask some of the questions above and others about this change. For me the reasoning for this was never really compelling. In JS you can introduce objects on the fly, you have first class functions, real closures. The only reasons I can think of for this was familiarity or other cultural ones. Another one: I've been reading and learning more about SQL lately. Trying out different types of modelling, playing with advanced features and so on. Naturally I want to get some kind of overview and look up stuff on the web. I read "anti pattern"-this and "you should do"-that. First, I was confused and started to second guess myself. But in the end I got it: Most of this stuff is written by people who just happen to work with a certain mindset and with certain types of tooling. For them these guidelines make sense, for me? It depends... In the end it's very cultural. The tools people use, the environment they work in and the types of problems they have to solve all shape the way they think and communicate. And this is especially pronounced for the academic types, or the people who mostly write documents and little code.

aryehof 5y ago

> We “know” today that inheritance leads to bad outcomes… Inheritance used inappropriately likely leads to bad outcomes. Knowing when that is the case makes one a good programmer, not popular opinion.

gmfawcett 5y ago
You're missing the point. He's wondering how a student would assess this, not an experienced programmer. A student generally assumes that their instructor's opinion is informed.
- voakbasda 5y ago
  > A student generally assumes that their instructor's opinion is informed. The first thing a student should learn is that teachers are not infallible. Question authority. Doubt everything.
  - dgb23 5y ago
    That’s what teachers typically say too. At least the one’s I respected most.
raldi 5y ago
This also reads like social commentary :)

Jtsummers 5y ago

Hopefully a good student wouldn't stop listening at that point, because the rest of the linked paper describes how to clean things up precisely because an overdependence on inheritance can create bad outcomes. Quoting from the discussion at the end that GP apparently failed to read: > In our aggregation pattern we discuss how inheritance is overused and sometimes is incorrectly used. Our pattern addresses how to fix one common misuse of inheritance - but in proposing this pattern, are we (improperly) encouraging an undisciplined use of inheritance, with the idea that one can "fix things later"? We think not. As noted earlier, "is-a" relationships are not always clearly distinct from "has-a" relationships. Points of view change over time, which does not imply that the original use on inheritance was incorrect. In fact, they're addressing your concern in their own document! Does encouraging early use of inheritance with the intent to refactor later (when you actually know what you're building) cause problems? They don't think so, but that's an opinion born (presumably) from their own experience. Yours may be different, mine hasn't been. Their discussed model has you (somewhat) abuse inheritance early, while prototyping, and then lists several ways to change the structure of the program once you properly understand the model you're implementing.

dgb23 5y ago
> Quoting from the discussion at the end that GP apparently failed to read What implies that? The quote I gave hints at exactly the stuff you are discussing here.
- Jtsummers 5y ago
  Your "Well it turns out..." part is what threw off my reading of your comment. That turn of phrase is usually meant to imply that the preceding is, in some way, bogus. If that's not what you intended, I apologize. But it's how it reads to me. Under that reading, it really seems you stopped at that point in the text and didn't continue to where the authors talk about why stopping at that point in the program development is problematic and how to correct it (the later sections).
  - dgb23 5y ago

dgb23 5y ago

> But what would have to be true in a student to be able to “know” this back then? By studying! A hint is right there at the end of the quote I provided: > The resulting subclasses are not yet truly general. More desirable, from a software maintenance standpoint, would be an inheritance hierarchy that models a type hierarchy This implies that the common approach at the time in OO introduced too much unnecessary coupling. And at the time and before that, there were already approaches being explored that avoided this in some way or another. Another way is to just as basic questions: What does this try to achieve? What problem does it solve? Why do they think it is a problem? How is it implemented? Can this be achieved/solved with a different implementation? Can this be achieved by removing something, like an assumption/perceived requirement or dependency? Here is a simple example for illustration: JavaScript at some point introduced syntax for classes. A relatively common "compiles to JS" language was CoffeeScript at the time, which had classes. Ask some of the questions above and others about this change. For me the reasoning for this was never really compelling. In JS you can introduce objects on the fly, you have first class functions, real closures. The only reasons I can think of for this was familiarity or other cultural ones. Another one: I've been reading and learning more about SQL lately. Trying out different types of modelling, playing with advanced features and so on. Naturally I want to get some kind of overview and look up stuff on the web. I read "anti pattern"-this and "you should do"-that. First, I was confused and started to second guess myself. But in the end I got it: Most of this stuff is written by people who just happen to work with a certain mindset and with certain types of tooling. For them these guidelines make sense, for me? It depends... In the end it's very cultural. The tools people use, the environment they work in and the types of problems they have to solve all shape the way they think and communicate. And this is especially pronounced for the academic types, or the people who mostly write documents and little code.