Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
1–10 of 113 posts
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#2This is the most obtuse and rambling critique of child extends parent i've ever seen in my life
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#3This 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 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 particular design decision is good or bad.Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#4This 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…
Agreed, it’s a really concise and clear articulation of one of the main traps of inheritance thinking.
I also think people are very receptive to this once you point it out. You’re not trying to make a class hierarchy because you come to the problem with a presupposed mental model. Instead you should be letting your attempt to solve the problem with no abstraction teach you about the places where abstraction would help. Maybe it should be organized as inheriting behaviors via mixins instead of specializing behaviors based on a hierarchical relationship with a parent type. Or maybe all the classes just need to be simple record / tuple wrappers and the methods that operate on them don’t belong to any class at all.
The reason examples like car extends vehicle cause harm is that they can be superficially taken as an endorsement that you should bring preconceived mental models of relationships between components into the solution, before trying to solve it with zero abstraction and observing where this breaks down.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#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 absolutely do all these things. And those seem entirely reasonable ways to teach someone about programming, while being more accessible and engaging than "let's talk about how to write an IO stack." *
> Penguins don’t implement the “fly” method that can be found in birds.
That's an important issue, though, which an OO tutorial needs to deal with. It points at two major problems:
1. The circle-ellipse problem[1].
2. That nominative types have all the inherent problems that taxonomy has.
And since one solution is "duck typing"[2] it's worth noting that it's entirely clear what it means, despite being named after ducks.
[1]: https://en.wikipedia.org/wiki/Circle-ellipse_problem
[2]: https://en.wikipedia.org/wiki/Duck_typing
* IO stacks are good to learn, but to do them in OO you have to understand IO first, and though it's very satisfying when you get tricky IO code right, it's not really something you can show to your friends.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#6I tend to agree. The “duck extends bird” examples sound good at first but they have done a lot of damage to OOP.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#7> 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 would see similar things in something like Unreal, or even in-house engines. The implementation is likely also to be way more interested in acting on aggregate data streams rather than enforcing strict encapsulation and object boundaries and such.
It's still very OOP, but not in the sense of representing real-world taxonomies.
I know there's an argument that this real-world metaphor is good for beginners, but at least in my personal experience I don't think that's the case. I remember when I was a kid, my dad tried to teach me coding with a lot of object oriented examples with like Cats and Dogs and stuff. He was really well meaning, but it never really made sense to me. 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. Awful code, but 10 year old me was able to reason about that a lot easier than polymorphism/encapsulation/scoping/etc.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#8[deleted]
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#9Discussed at the time: https://news.ycombinator.com/item?id=2914405
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#10> 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 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.