Goodbye, shitty "Car extends Vehicle" object-orientation tutorial • Hacker News Board

Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial

#131

Post by podperson » Tue, Aug 23, 2011, 8:10 PM UTC

Wilduck wrote: post #128

podperson wrote: post #126

Earlier quoted context omitted.

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 stu…

>> 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 sw…

> 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.

Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial

#132

Post by joe_the_user » Tue, Aug 23, 2011, 9:08 PM UTC

barrkel wrote: post #40

joe_the_user wrote: post #31

Earlier quoted context omitted.

It is a key point in design AND it usually feels like a completely pointless and annoying waste of time. Humans have such a marvelous natural facility for attaching a meaning to a sentence that we don't feel like loopholes and contradictions within language are meaningful. Ask the average person "who shaves the barber" in a describing of Russel's paradox and they'll give you a "what was the problem" look rather than…

Please do tell of the occasion you found squares versus rects etc. staring at you out of the debugger. Because the solution to this problem depends on the behaviour you're trying to get, rather than some absolute solution, so philosophical argument about it always seemed pointless to me. If the type is mutable, then per-instance information shouldn't be part of the class; have an isSquare calculated property or whate…

* Whatever your solution demands, there's a way of doing it. What the solution doesn't need - nor even cares about - is the philosophical argument.*

I think the disagreement here is that you seem to believe that philosophy is engaged in some different activity from the kind of "how should X type relate to Y supertype and Z characteristic" is the meat of object oriented design.

But really, what is being here is ontology. Ontology isn't really fancier than this and the here isn't more clear cut that what philosophers try to muddle out.

Ordinary philosophy has been kind of society-wide clarification of definitions, just a design is an organization-wide clarification of definitions. Take a look at the actual text of The Critique Of Pure Reason at some point. While might have been written with various arguments in mind, most of the actual text is a long, long discussion of what objects belong in what category - ie, nothing more "airy-fairy" than most design discussions.

Ordinary philosophy gets less attention than the elaborate debates around the "edges" of definitions. But this also happens with design discussions.

Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial

#133

Post by dtreacy » Wed, Aug 24, 2011, 4:28 AM UTC

lyudmil wrote: post #111

dtreacy wrote: post #95

THAT'S WHY ITS A BEGINNER TUTORIAL. Get off your high horse.

The criticism being put forward isn't at all arrogant. A tutorial for beginners that teaches you the wrong thing is incredibly detrimental. It's good to point that out and fix it.

"Duck extends Bird" is not the wrong thing at all. As other comments have pointed out, the justifications in the article don't apply to someone who is just starting out learning the basics of OO.

Re: Goodbye, shitty "Car extends Vehicle" object-orientation tutorial

#134

Post by barrkel » Thu, Aug 25, 2011, 5:41 PM UTC

joe_the_user wrote: post #132

barrkel wrote: post #40

Earlier quoted context omitted.

Please do tell of the occasion you found squares versus rects etc. staring at you out of the debugger. Because the solution to this problem depends on the behaviour you're trying to get, rather than some absolute solution, so philosophical argument about it always seemed pointless to me. If the type is mutable, then per-instance information shouldn't be part of the class; have an isSquare calculated property or whate…

* Whatever your solution demands, there's a way of doing it. What the solution doesn't need - nor even cares about - is the philosophical argument.* I think the disagreement here is that you seem to believe that philosophy is engaged in some different activity from the kind of "how should X type relate to Y supertype and Z characteristic" is the meat of object oriented design. But really, what is being here is ontolo…

I agree with what you say, oddly enough. Perhaps my beef is actually with all the amateur philosophers who insist on a unique, canonical ontology, rather than the fact of the matter, that there are always multiple ontologies to choose from. So they argue about things like square and rectangle re subtyping, but there is more than one way to validly slice the pie, so the argument is pointless.