[Alex3917]

I think it's really time to move on from math puzzles in most programming classes and hiring interviews. If people enjoy doing Project Euler problems or find them beneficial then that's great. But using them to 'teach' others is like forcing your own weird fetish on unsuspecting strangers, and frankly the persistence of this tradition is becoming something of an embarrassment to both academia and industry.

[grahamburger]

While we're at it can we stop using animal or vehicle analogies to teach oop?

[Alex3917]

This is a good point. Because you can't make a car or an animal out of software these analogies always seem to lead to bad teaching.

Much better to use something like Person and Employee/Student, where it's easy to immediately grasp the value based on not having to duplicate the data fields you'd need for a basic CRM. (As opposed to having to make up ridiculous methods about the panda eating bamboo or whatever where no one understands what the fuck is going on.)

[grahamburger]

Exactly! Ugh I hate that. "A cat can be an instance of animal, but it needs a 'meow' function" ... What?

[stephengillie]

By oversimplifying, these examples actually obscure the lesson. It helped me to think of OOP objects as sub-variables, or even as a set of variables grouped by the first part of their name. Like a "multi-key/multi-value" hash table.

The purpose of functions only started making sense after learning calculus and the replacement method, where a complex term was replaced by a single variable. This is where I learned they're mostly for readability, an adaptation to make programming easier for humans to do.

[BatFastard]

Adding a "meow" function is the wrong way to go about it. The base class just needs a protected sound function so that each derived class can set the sound in its initialization routine. So many programmers, so few who truly understand OOP.

[bobwaycott]

Out of curiosity, what are your go-tos for this?

[grahamburger]

Well I'm not exactly a teacher or an expert, just an armchair critic - so I won't pretend that my ideas will be revolutionary or even all that good :) but, because this is something I've been thinking about recently, I'll contribute. My oldest son is 5 and I've been thinking about how I'll start to teach him programming, if he finds himself so inclined. Right now I'm thinking I'll start by working through a Christmas wish list program with him. For OOP specifically, the wish list items might make a good (if simplified) example of classes/objects, with maybe some inheritance for 'things I would like' vs 'things I would like to give to other people' vs 'things I would like to do' etc.

Essentially my gripe with the animal and car analogies is exactly what Alex3917 wrote above - you're (almost?) never going to actually implement anything like a car on an animal in a real program. And if you do, you're almost certainly not going to give it methods like 'Honk' and 'Meow' (which is exactly how OOP was described in my first class on the subject.) It's not that they're bad analogies - in fact it's almost that they're too good of analogies. They represent the OOP concepts very well, just not the practical usage of the concepts.

Actually the truth is I'm a little bit disillusioned with OOP altogether, and it seems like there's a lot of movement in the industry away from OOP with things like Go, Rust and other more purely functional languages.

[TheOtherHobbes]

> never going to actually implement anything like a car on an animal in a real program.

Did you mean "on" or "or"?

Using OOP to implement a vehicle is a no-brainer. It's a completely standard model for games.

Extending the animal class to make a car would be weird though.

One point of OOP isn't that you make classes, but that the classes you make can be easily duplicated and automated.

So you can make an animal with a few simple behaviours, use your animal prototype to make a herd or flock, and suddenly you've got emergent semi-intelligence, which you can define by changing a few lines in the prototype.

It's not just a way of giving properties to something that's kind of like a real object - it's a way of simplifying automation and bulk updates of related entities.

[qbrass]

>Extending the animal class to make a car would be weird though.

Carriage extends Animal with Cart Car implements Carriage with Engine as Animal

[hidroto]

That sounds more like composition then inheritance.

[invaliduser]

Actually, a language not having a class system does not mean it's not object-oriented. Javascript prior to ES6 did not have a class system, but was OO. Classes are just one of many ways to implement objects in a language (just saying, because you mention go & rust)

[grahamburger]

Yeah for sure. I should have specified class based. Regardless, I think those languages place much less emphasis on OO than, say, Java or Ruby, right?

[pbhjpbhj]

Lightbot and code.org are suitable from 5yo or earlier IMO. Code.org uses the "jigsaw" visual programming pane (blockly) that Scratch uses so they work well together - Scratch can export to flash for sharing online.