Live data from Hacker News

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

mail-archive.com

71–80 of 177 posts

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

#71

Does anybody have some actual good examples for teaching inheritance to beginners? I've thought about this for quite some time and couldn't come up with anything that strikes a nice balance between simple and actually useful.

Any sort of plugin architecture, e.g. VST audio plugins. Often there's an interface which you could implement directly, or you could inherit from an abstract class which provides some common functionality. I like this because it stresses that deep hierarchies aren't necessary to be useful. Also, if you're refactoring and see a "switch on type" then a little bit of inheritance is probably OK.

I admit I taught intro to C++ and used shapes as an example. I spent a few weeks building a little "ASCII render" thingy with a 80x30 "canvas" where each character is a pixel. Then you could place Shapes on the canvas and the shape would decide whether a given pixel was contained() inside of it.

I remember my first OO class where the car analogy was proven to be bad using the existence of the El Camino.

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

#72

Earlier quoted context omitted.

In job interviews, people don't write the code they would write normally, they write the code that they think the interviewer wants to see. And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them. If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they w…

Every example you listed would be dodging an enormous bullet. The exact example the grandparent used was essentially a wrong answer, so our "old-school interviewer" (that sounds kind of ageist doesn't it?) marking us down for not using it is a bad thing. An interviewer who loves functional programming and doesn't communicate any preference then marks you down for not reading their mind is someone to avoid. An intervi…

Not every person in the interview process is anywhere near you in the org though, sometimes great jobs are behind a shitty interview

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

#73

Earlier quoted context omitted.

Every example you listed would be dodging an enormous bullet. The exact example the grandparent used was essentially a wrong answer, so our "old-school interviewer" (that sounds kind of ageist doesn't it?) marking us down for not using it is a bad thing. An interviewer who loves functional programming and doesn't communicate any preference then marks you down for not reading their mind is someone to avoid. An intervi…

Not every person in the interview process is anywhere near you in the org though, sometimes great jobs are behind a shitty interview

Yes, and sometimes shitty jobs are behind great people. Candidates get catfished in interviews all the time.

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

#74
post #9

Entity-Component-System is so much nicer paradigm than any hierarchy. I wonder why it's not used much outside of gamedev.

It does not replace OOP because there are no answers to other questions like: does it support polymorphism? Or data encapsulation? Etc. It's a data access design principle, and that's about it.

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

#75
post #21

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements. I've seen it all. Prius extends Car extends vehicle extends motor extends ... Right within the first five minutes of the interview. But I al…

In job interviews, people don't write the code they would write normally, they write the code that they think the interviewer wants to see. And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them. If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they w…

It's always this. Every interview I've had is a quest for the interviewer to demonstrate they know more about the subject they quiz me about than I do. This is especially true with kubernetes, it's a vast project with many areas, but if you don't know whatever niche the interviewer is interested in, you will struggle.

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

#76
I spent a LOT of time in the late 80s and the 90s wrestling with class hierarchies, coming up with one tower of abstraction after another. So much wasted time; perhaps it didn't help that my vehicles were C++ and Java, but I think that I would have fared just as well in any other OOPy language.

What I got as a side-effect was a bunch of re-written code. And I wondered:

Maybe OOP is a terrible paradigm. Maybe the designs that come out of it are so awful that it causes people to rewrite code, over and over. Re-examined systems are often better than first attempts. Once you reimplement something five or six times, you've probably explored most of the problem space and are pretty good at it. It's even likely that you are thoroughly sick of the project and just want to get the stupid thing done and shipped. (Yeah, your PMs and entire management chain just smiled behind your back).

In other words, it's Brook's "plan to throw one away, you will anyway" in action, while telling your boss that you had to rewrite your framework again because it didn't handle the flightless, swimming bird scenarios.

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

#77
post #54

If I had to state a law about how to do OOP correctly it would be: - A base class and its implementation(s) must never be written by the same person. Obviously a bit of a strong opinion, but inheritance should delimit layers of abstraction, technically separating the responsibility of developers.

A base class should only exist where there are implementations -it needs to be plural. Otherwise just fold the base into the child, or better yet use composition not inheritance. I generally do not count any form of test double (mock...) as a an implementation, since only rarely is the real implementation something that you should mock.

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

#78
post #21

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements. I've seen it all. Prius extends Car extends vehicle extends motor extends ... Right within the first five minutes of the interview. But I al…

In job interviews, people don't write the code they would write normally, they write the code that they think the interviewer wants to see. And that brings me to a topic that's entirely different but also very relevant: job interviews bring interviewer-biases with them. If you run into an old-school interviewer who would do exactly that "Prius extends Car extends Vehicle, etc." nonsense, but you don't know it, they w…

> If you run into someone who doesn't like it when you ask questions, you'll lose. If you run into someone who doesn't like you asking questions they don't know the answer to, you lose.

That's actually a win in your book, not a loss!

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

#79
Object oriented programming was meant to be used in a Smalltalk environment, where immediacy & liveliness were key principles of the design.

OOP wasn't meant to be used by professional programmers ever, but this is always always forgotten. Why do we still talk about OOP when it comes to professional / full-time programming? OOP was always meant to be about providing end-users a way to create programs & dynamic behavior without becoming full-time programmers.

- http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

- https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

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

#80

Object oriented programming was meant to be used in a Smalltalk environment, where immediacy & liveliness were key principles of the design. OOP wasn't meant to be used by professional programmers ever, but this is always always forgotten. Why do we still talk about OOP when it comes to professional / full-time programming? OOP was always meant to be about providing end-users a way to create programs & dynamic behavi…

I don’t get this originalist argument. After it’s introduction, OOP very clearly evolved in a professional direction almost immediately. Why would you erase that history, and the work of hundreds to thousands of people working on object technologies, because it wasn’t the original conception?
Post reply on HN