7 ms·

I think my broader criticism of this complaint is that they aren't considering the pre-requisite mastery problem. > Here’s an example that I think would be bet

by ben509 7y ago

I think my broader criticism of this complaint is that they aren't considering the pre-requisite mastery problem. > Here’s an example that I think would be better to use instead: the `Visible` hierarchy in [Pygmusic][], which is a kind of software drum machine. A `Timer` is a horizontal strip on the screen with a stripe racing across it. A `NumericHalo` is a spreading ripple on the screen that fades. That's how someone experienced in OOP is going to do it. The problem is that this depends on experience and knowledge of how such a system works. I don't think this would be significantly better than the Vehicle-Car examples, because your target audience is seeing this odd layout and you aren't likely able to give them reasons why it should be that way. To fully explain yourself would require information you can't reasonably impart in a tutorial. You know why it's done that way, but the underlying rules are obvious and intuitive to you because you worked on them long enough. These rules manifest in a trained developer as an intuition that is developed by the feedback of doing things and failing or succeeding. Maybe they could be expressed mathematically, but it'd probably be very specialized math like advanced linguistics. > In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication Maybe we should really stop talking about "objects" and "classes" entirely? Non-OOP structured programming doesn't have this problem; it's hard to grasp exactly when two subroutines are overly coupled, but it's easy to explain that sharing state and having action at a distance is a bad idea. And, generally, it's just not claiming any subroutine represents a real life "object". The only hierarchy imposed is the hierarchy of control flow.

jameshart 7y ago
The thing OO tutorials steeped in real world hierarchies are missing, though, is that understanding the concept of a hierarchy is not the hard part. Understanding what hierarchies are interesting in factoring a problem into code is the hard part that the student needs to understand.
- TeMPOraL 7y ago
  And the key part of the problem is understanding that hierarchies and categories are completely arbitrary, and their value is determined by how useful they are. There's no one holy taxonomy. Real-world examples can be used to point that out. Whales are mammals to biologists, but they're essentially fish to the economy. A bat is a mammal and an airplane is a vehicle, but both of them go into the same bag as birds if your main concern is "things that can fly" vs. "things that can't". Square is a special form of rectangle to mathematicians, but it's the other way around if your main concern is how much information you need to draw it. "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad." Etc. Once you crack the student's belief in there being one proper taxonomy for everything (a belief that strangely seems common even in adults in general population), you can then effectively show them that one of the main tasks of a programmer is finding the most useful way of categorizing things they're dealing with - and once that's done, the programming languages tend to have tools that let the programmer exploit such categorizations to minimize complexity.

by ben509 7y ago

jameshart 7y ago

The thing OO tutorials steeped in real world hierarchies are missing, though, is that understanding the concept of a hierarchy is not the hard part. Understanding what hierarchies are interesting in factoring a problem into code is the hard part that the student needs to understand.

TeMPOraL 7y ago
And the key part of the problem is understanding that hierarchies and categories are completely arbitrary, and their value is determined by how useful they are. There's no one holy taxonomy. Real-world examples can be used to point that out. Whales are mammals to biologists, but they're essentially fish to the economy. A bat is a mammal and an airplane is a vehicle, but both of them go into the same bag as birds if your main concern is "things that can fly" vs. "things that can't". Square is a special form of rectangle to mathematicians, but it's the other way around if your main concern is how much information you need to draw it. "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad." Etc. Once you crack the student's belief in there being one proper taxonomy for everything (a belief that strangely seems common even in adults in general population), you can then effectively show them that one of the main tasks of a programmer is finding the most useful way of categorizing things they're dealing with - and once that's done, the programming languages tend to have tools that let the programmer exploit such categorizations to minimize complexity.