Comment by zamadatix | Hacker News Reader

Comment by zamadatix | Hacker News Reader

Parent Full thread

I just went through a CSCI degree program after a long time in the field (figured I'd have some fun + try to catch a few things I may not have had a chance to mess with much over the years, like databases) and I gave myself a pretty decent lean on C++ programming courses where I could.

The introduction to class inheritance started with the classic "Dog extends Animal" example. Honestly though, that was actually really good for new programmers in the course for exactly the reasons you point out: it's completely abstract and meaningless without immediately inviting urges of "well, why wouldn't I just do something like <x> instead" yet is also relatively straightforward way to learn "well, what the hell even IS class composition?" before you move on to the "more practical" examples where it can start to be better to dive into "well, when and why would I USE inheritance over something else?" type probing.

The course actually did pretty good with both halves of that around the Dog/Animal example... and then it all fell off the rails a bit as inheritance was given far too much weight in the content of that and the following courses. I think even my last C++ final project still had using inheritance as a design requirement, and by that point the things the projects were about weren't really great fits for inheritance so you had to just shove it in anyways.

To me it seems exactly like how implementing "uint32_t factorial(uint32_t x)" is a GOD AWFUL practical example of when to use recursion but a FANTASTIC way to introduce what a recursive function is, because that's exactly how you already learned about it in math classes. In the same way, once recursive functions are introduced with a basic understanding of what it is, it's good to move to more practical examples and poke at "why was that actually not a great way to implement factorial but it was great for traversing trees or..." type exploration/questioning.

Meaningless toy examples have the problem that they can appear to make sense, planting the seeds of terrible ideas.

If in a course example Dog extends Animal, it can be an arbitrary demonstration of language mechanisms (with an uncontroversial is-a relationship) but even in that case it is implicitly suggested that it is a good or "normal" design, implying an alarmingly complex program that has good reasons to deal with those two types.

Such a program is usually not described for brevity, giving the false impression that it exists: if the problem were analyzed with any diligence, usually Dog would appear a completely pointless complication.

More or less, this is the https://en.wikipedia.org/wiki/Lie-to-children debate. It'd be nice to always be able to learn the best known things up front, it's not usually a particularly practical approach to learning a complex field.

I.e. planting a terrible idea is alright so long as by the end the terrible idea was able to be replaced down the line in less time than trying to learn everything "correctly" from the get go. The latter part is where I felt the class failed, it held on to bad idea through the end instead of quickly replacing it with the "next level" of conceptual thinking.

The problem is that treating the incorrect simplification as good can be very tempting for teachers.

For example, in an introductory physics course teaching Newtonian dynamics without the brutal complications of special relativity and general relativity is fine because it doesn't take much to explain that it is an approximation and it is good enough for "everyday" situations. Students are aware that a better model is available: worst case, they try to get away with not using it.

On the other hand in an introductory programming course teaching that if you have Animals in the program the dog instances "should" belong to a Dog subtype is logically consistent and elegant; the only opposing force is the abstract and uncool engineering principle of keeping software simple, and many teachers are dogmatic and enthusiastic.

Everything seems drastically simpler after you've already learned it vs when you're trying to learn everything about it for the first time. Hell, even explaining what the difference between a class and a struct is in C++ ends up going into weeds about public/private that makes many people who just learned what variables were a few weeks ago, let alone trying to teach them what different attributes of classes do by comparing best practices of their usages.

I.e. they aren't trying to say what is elegant yet, they are just trying to get people to understand what the building blocks of classes they can compare are even supposed to do so they can get to comparing when you'd do different ones.

But there are bad teachers and they tend to be bad regardless of the example chosen.

Reply on news.ycombinator.com