4 ms·

I agree that the proposed replacement is terrible. I'd suggest files are a great example for people who have a programming background because you can quickly s

I agree that the proposed replacement is terrible. I'd suggest files are a great example for people who have a programming background because you can quickly show problems (e.g. streams considered as a subclass of files) that entail the kinds of tradeoffs and decisions the author rightly points out are shortcomings of the duck example (most of the shortcomings listed are in fact more a case of the author trying to show off and not problems with the example at all). But, you know what, duck, bird, and penguin are actually just fine. As the author himself (I assume it's a him) points out, penguins can't fly. And let's say that over hear we're doing vehicle, car, plane, and helicopter. How can we avoid implementing flying twice? And is it a good idea to treat flying like a plane, a helicopter, and a bird (but not a penguin) as the same thing. Oh, and the way penguins swim is amazingly analogous to flying, how can we leverage that? So, bye bye shitty drum machine example. I'm going back to duck and bird.

Wilduck 15y ago
As someone who is only a couple years past my first encounter with car/vehicle, duck/bird examples I can say that they did nothing useful for me. I think the reason they were so useless is not because they were trivially simple, but because they emphasize the wrong type of focus when dealing with inheritance. Presenting inheritance in terms of duck/bird emphasizes thinking in terms of similarities between nouns, which is misleading. I would have much rather seen some contrived example which does something other than print "quack". This, however, is a criticism with most tutorials that I've read. Most would benefit from having more substantive examples and letting the syntax and concepts fall out of them.
- podperson 15y ago
  On the one hand, using examples which do nothing more than print "quack" is a bit of failure of imagination on the teacher's part. But then, _needing_ an example to do something other than print "quack" is a failure of imagination on the student's part. You had, I assume, seen functions before. If I were teaching such material I would keep the content of the functions themselves as simple as possible to allow the student to concentrate on the novel material. Once I had established that the student understood the principle we could then examine or at least discuss more "real world" cases. If we go back to the original article for a moment, I can far more easily see an immediately accessible problem-set emerging from bird / duck / penguin (e.g. programming the behavior of animals in a virtual world) than a particular drum machine whose operation might make no sense to many people. Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied? Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate.
  - Wilduck 15y ago
    >> Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate. A drum machine may not be the best example (as the author mentioned) but it is a concrete example. You argue that an animal based example illustrates all these different possibilities in an object oriented approach. >> Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied? The problem is that this is completely divorced from anything that any sane person learning programming would want to do. Sure, printing "quack" is interesting for the first page of a tutorial, but I would expect that the usefulness of the examples in a tutorial would scale with their difficulty. If you're using multiple inheritance, mixins, and templates, you should be using code that either requires these techniques or benefits from them. Imagine you're a novice programmer. You've used a computer your whole life, and do awesome things with it every day. You want to learn how to make it do cool things. In and of themselves templates, mixins, and inheritance are not cool things. They are only cool if you know what they can help you do. A novice programmer will have no idea what they can help him do. So, for a tutorial aimed at teaching someone their 12th programming language, use birds/ducks. But if you're aiming at teaching a novice, and you use a birds/ducks example you have almost certainly failed to keep your student engaged. Instead, go with something that doesn't cover all the bases, but starts to show how much work can be accomplished with some simple OO structures.
    - podperson 15y ago
      > The problem is that this is completely divorced from anything that any sane person learning programming would want to do. It sounds to me a lot like a typical game-programming kind of design question. Games are pretty popular. Can you think of a more generally popular problem domain? Certainly, one can imagine very similar examples (car / vehicle / truck etc.) which would bear directly on very popular game analogies. > So, for a tutorial aimed at teaching someone their 12th programming language, use birds/ducks. I think your point here is well-taken. If the student knows about conventional programming, introducing OO coding is a different task than otherwise. But the whole 'print "quack"' point is pretty silly -- of course you'll initially teach about inheritance using trivial functionality that doesn't distract from the teaching point. I've seen OO tutorials that talk about point, square, and circle classes that never actually draw a point, square, or circle. Is printing "width = 100" more profound than "quack"? In the end, you teach a topic by focusing on that topic, not adding a bunch of distracting detail. The distracting detail may be useful for motivation, but you need to get it out of the way to actually explain the point. I might finally add that teaching a specific person you're talking to is a different task than writing a book. When you're teaching a specific person you can find out what they're interested in and use that as both motivation and example. But, if you're writing a book you want to find analogies that are are universally accessible and appealing as possible.

Wilduck 15y ago

As someone who is only a couple years past my first encounter with car/vehicle, duck/bird examples I can say that they did nothing useful for me. I think the reason they were so useless is not because they were trivially simple, but because they emphasize the wrong type of focus when dealing with inheritance. Presenting inheritance in terms of duck/bird emphasizes thinking in terms of similarities between nouns, which is misleading. I would have much rather seen some contrived example which does something other than print "quack". This, however, is a criticism with most tutorials that I've read. Most would benefit from having more substantive examples and letting the syntax and concepts fall out of them.

podperson 15y ago
On the one hand, using examples which do nothing more than print "quack" is a bit of failure of imagination on the teacher's part. But then, _needing_ an example to do something other than print "quack" is a failure of imagination on the student's part. You had, I assume, seen functions before. If I were teaching such material I would keep the content of the functions themselves as simple as possible to allow the student to concentrate on the novel material. Once I had established that the student understood the principle we could then examine or at least discuss more "real world" cases. If we go back to the original article for a moment, I can far more easily see an immediately accessible problem-set emerging from bird / duck / penguin (e.g. programming the behavior of animals in a virtual world) than a particular drum machine whose operation might make no sense to many people. Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied? Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate.
- Wilduck 15y ago
  >> Now explain to me how a drum machine illustrates these problems in a way everyone can immediately appreciate. A drum machine may not be the best example (as the author mentioned) but it is a concrete example. You argue that an animal based example illustrates all these different possibilities in an object oriented approach. >> Are ducks a "subclass" of bird? How do we handle the face that penguins and ducks can swim and penguins can't fly? Is it useful to consider be the penguin as a "bird" at all. Perhaps we shouldn't have a "bird" class but an "animal" class. Should we do multiple inheritance? Mixins? Templates? Perhaps we'd be better with an "animal" class and allow some animals to fly and some to swim? Are complex classes like this bad? How could all these different approaches to OO design be applied? The problem is that this is completely divorced from anything that any sane person learning programming would want to do. Sure, printing "quack" is interesting for the first page of a tutorial, but I would expect that the usefulness of the examples in a tutorial would scale with their difficulty. If you're using multiple inheritance, mixins, and templates, you should be using code that either requires these techniques or benefits from them. Imagine you're a novice programmer. You've used a computer your whole life, and do awesome things with it every day. You want to learn how to make it do cool things. In and of themselves templates, mixins, and inheritance are not cool things. They are only cool if you know what they can help you do. A novice programmer will have no idea what they can help him do. So, for a tutorial aimed at teaching someone their 12th programming language, use birds/ducks. But if you're aiming at teaching a novice, and you use a birds/ducks example you have almost certainly failed to keep your student engaged. Instead, go with something that doesn't cover all the bases, but starts to show how much work can be accomplished with some simple OO structures.
  - podperson 15y ago
    > The problem is that this is completely divorced from anything that any sane person learning programming would want to do. It sounds to me a lot like a typical game-programming kind of design question. Games are pretty popular. Can you think of a more generally popular problem domain? Certainly, one can imagine very similar examples (car / vehicle / truck etc.) which would bear directly on very popular game analogies. > So, for a tutorial aimed at teaching someone their 12th programming language, use birds/ducks. I think your point here is well-taken. If the student knows about conventional programming, introducing OO coding is a different task than otherwise. But the whole 'print "quack"' point is pretty silly -- of course you'll initially teach about inheritance using trivial functionality that doesn't distract from the teaching point. I've seen OO tutorials that talk about point, square, and circle classes that never actually draw a point, square, or circle. Is printing "width = 100" more profound than "quack"? In the end, you teach a topic by focusing on that topic, not adding a bunch of distracting detail. The distracting detail may be useful for motivation, but you need to get it out of the way to actually explain the point. I might finally add that teaching a specific person you're talking to is a different task than writing a book. When you're teaching a specific person you can find out what they're interested in and use that as both motivation and example. But, if you're writing a book you want to find analogies that are are universally accessible and appealing as possible.