Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

web.archive.org

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#11

Post by eckza »

overgard wrote: post #7
ben509 wrote: post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You…

> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global.

An aside: It's okay to learn that way, when you're 10.

A lot of my own big programming revelations have come from ignoring best practices and accidentally trying to implement or construct them from first principles once my problem becomes unmanageable.

"Doing it wrong" is an even better teacher than "doing it right all of the time", because the mistakes you make can lead you to a deeper understanding of why things are done a certain way.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#12

Post by jameshart »

ben509 wrote: post #10
ben509 wrote: post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

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

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.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#13

Post by ben509 »

overgard wrote: post #7
ben509 wrote: post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You…

TBH, I haven't written any real games, and the simulation work I do is in finance, so if we have an account, it's really just an account. But securities and accounts and such are all well-defined abstractions that lend themselves very well to direct representation in code, so my experience is not representative.

Maybe it's possible to be less misleading, but I still think it's a mistake to try to write a tutorial that tries to present basic concepts in the fashion that production code is written. There's just so much stuff you do in prod that is not relevant to the concepts you're trying to convey.

> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place...

I learned on a C64 when I was a kid, too. I'd absolutely recommend learning structured imperative programming before OOP.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#14

Post by overgard »

eckza wrote: post #11
overgard wrote: post #7

Earlier quoted context omitted.

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You…

> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. An aside: It's okay to learn that way, when you're 10. A lot of my own big programming revelations have come from ignoring best practices and accidentally trying to implement or construct them from first principle…

Totally agree. I think we make a mistake trying to harp on doing things "right" too much for new programmers, because they end up with analysis paralysis.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#15

Post by colllectorof »

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus.

This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pressure to arrange things in trees. I've been like that when initially learning Java and it took a while to recover from it. It's like fucking brain damage from bad examples.

Inheritance is not about creating taxonomies.

Namespaces are not about creating taxonomies.

Both are practical solutions to practical problems that occur when writing code.

Inheritance is a result of several insights:

1. It's convenient to be able to sketch out a protocol which a set of objects will follow - without having to work out every damn detail about its implementation.

2. Most of the protocol can be implemented once and then reused.

3. Often you want to use the default protocol implementation with some changes. Instead of re-implementing the rest of the protocol, it's highly convenient to be able to specify only the differences.

#3 is the core reason why inheritance was developed.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#16

Post by lonelappde »

LordN00b wrote: post #3
kkarakk wrote: post #2

This is the most obtuse and rambling critique of child extends parent i've ever seen in my life

Are you sure? His argument is one simple paragraph: The `Car extends Vehicle` or `Duck extends Bird` type of tutorial obscures more than it illuminates. 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 (which co…

Indentation breaks HN. Blockquote should not inherit from Codeblock.

Please remove it and use > for quotes.

> The `Car extends Vehicle` or `Duck extends Bird` type of tutorial obscures more than it illuminates. 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 (which comes to the same thing). Without any context as to what the code needs to accomplish, you can’t make a judgment about whether a design decision is good or bad.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#17

Post by TeMPOraL »

overgard wrote: post #14
eckza wrote: post #11

Earlier quoted context omitted.

> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. An aside: It's okay to learn that way, when you're 10. A lot of my own big programming revelations have come from ignoring best practices and accidentally trying to implement or construct them from first principle…

Totally agree. I think we make a mistake trying to harp on doing things "right" too much for new programmers, because they end up with analysis paralysis.

That's my current approach to teaching people programming concepts. I try to provide an example of not using that concept, point out the quickly growing complexity of the code, and then show how that complexity can be reduced with the new concept I'm introducing.

(And yes, as a kid, I was hurt by all those "Cat : public Animal" examples too. It took me many years before I figured out why they didn't work in practice for me.)

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#18

Post by fenomas »

ben509 wrote: post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

> In the context of a game or simulation, such classes can absolutely do all these things

Sure, but the point of TFA is that even then it still doesn't (necessarily) make sense to give them an OO hierarchy similar to their real-world taxonomy.

It might make sense of course, but it might not - you can't tell without looking at the code. The point here is that duck/bird analogies imply that the real-world relationship between ducks and birds tells you something about whether your Duck class should inherit from a Bird class, when in fact it doesn't.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#19

Post by TeMPOraL »

jameshart wrote: post #12
ben509 wrote: post #10

Earlier quoted context omitted.

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

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.

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.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#20

Post by zmix »

Ididntdothis wrote: post #6

I tend to agree. The “duck extends bird” examples sound good at first but they have done a lot of damage to OOP.

But wasn't that how OOP was supposed to be, according to Alan Kay? That objects should have resembled real life objects, as close as possible and exchange messages with each other?
Post reply on HN