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)

mail-archive.com

Post reply on HN
Print view View original

41–50 of 177 posts

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

#41

Post by 734129837261 »

bdg wrote: 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 would rate you negatively.

If you run into someone who is just in love with functional programming, you'll lose any OO implementation.

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.

And if you get sent a 3-hour long Hackerrank or Leetcode algorithmic test, everybody loses.

Tech job interviews are just horribly biased and the game is won if you read your audience correctly. And even then, if the other person is a racist, or just doesn't like your face, or had a bad day, or feels threatened, or disapproves of how you write "Javascript" instead of "JavaScript", you still lose.

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

#42

Post by substation13 »

fabian2k wrote: post #40
substation13 wrote: post #36

The OOP community fascinates me. It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their way to support this kind of programming. Meanwhile the alternative approaches require you to jump through a bunch of hoops or apply convoluted "design patterns". Writing good, modern "OOP" you are often fighting the OOP language! Things are getting somewhat bette…

The only real difference is that inheritance as explicit language support while composition is something you can easily implement with common language features. It's not really more difficult to use composition than inheritance. As an example, if I want to use composition in C# using ASP.NET, I simply inject the class I want to use into my new class using the built-in DI. This is as simple as extending the class.

Some features are plain missing (or must be implemented in a convoluted manner):

- Discriminated unions

- Immutable data types (records)

- Free functions (or modules of free functions)

- Software transactional memory (STM), atoms

- Ad-hoc polymorphism (traits)

- Custom operators (used sparingly for building DSLs)

- List comprehensions

Instead we get anti-features like automatic properties, implementation inheritance, events, object initializers, etc...

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

#43

Post by BoorishBears »

quietbritishjim wrote: post #30
bdg wrote: 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…

The problem with that is you might feel pressured to talk about Prius extends Car extends Vehicle etc. even if you wouldn't do that in real code because it seems the question is meant to probe the concept of inheritence so it's natural to answer that way. It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no va…

I feel like you picked up on the wrong problem in their example...

> Prius extends Car extends vehicle extends motor extends

The problem isn't that it's too in-depth, or too overbuilt, that answer is as close to objectively wrong as you get on a pretty open ended question and I'd imagine only an extremely junior developer would come up with that.

For example, you could maybe argue that a model of car extends a specific car. I'd expect an experienced developer to favor composition over inheritance at that stage, but that's open to debate.

But if a Vehicle extends a motor, does a motor extend a piston? Does a wheel extend a lug nut?

At that point you're moving away from "arguably correct" to just plain failing to answer the question. It shows they don't know the difference between composition and inheritance.

> It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution".

You're free to ask questions, we're supposed to be trying to collaborate. I don't think it's "brave" to instead say "your problem doesn't make sense". Shows more hubris than anything.

How is it any different than a systems design question?

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

#44

Post by BoorishBears »

734129837261 wrote: post #41
bdg wrote: 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…

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 interviewer who punishes you for asking questions is a huge red flag and you'll be dodging a huge bullet.

I'm a self-taught dev so I definitely have some thoughts on how tech interviewing goes, but an interview runs both ways. I'd much rather miss out on a job because the other person was racist or they hate when people ask questions, than to end up working with them.

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

#45

Post by bdg »

quietbritishjim wrote: post #30
bdg wrote: 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…

The problem with that is you might feel pressured to talk about Prius extends Car extends Vehicle etc. even if you wouldn't do that in real code because it seems the question is meant to probe the concept of inheritence so it's natural to answer that way. It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no va…

> It takes a brave interview candidate to say "the best solution depends on the exact nature of the problem - and your problem doesn't make any sense so there's no valid solution".

I got that a few times and it's a good sign I have a senior candidate.

The real-world use case is simple when you imagine that I want to get a JSON payload describing different car configurations, possibly for a "car configurator" on a sales website, or perhaps for a videogame where there are different cars with different attributes at random. Once I go from "make a car" to "give me some json" everyone started to see it's as a less fictitious problem.

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

#46

Post by everyone »

the_other wrote: post #8
everyone wrote: post #5

I'm a game dev and usually program in C#. I love C# and honestly some features of OO (like objects and classes) are great for programming games. But inheritance is just a shit feature imo. Situations where it would be beneficial are extremely rare . I generally just pretend it doesnt exist. There are much better alternatives to it for most situations (eg. composition, build a class from other smaller classes that do…

Once you've ditched hierarchy, haven't you entered "functional programming" territory? It's just types, structs/maps/dictionaries, factories, and modules/closures now, right?

The atomic element of code is the function. If I just religiously stick the fundamentals of good programming, tiny functions, avoid coupling, avoid duplication (within reason), then I am at least half way to having nice maintainable code already.

Once I have all these really nice tiny functions, Its trivial to reorganise and replace them.

Though I find classes also very useful, a class is mainly a bucket that you put functions into. Ideally a class is a black box that does one thing. All the functions needed to do that thing are in the class and also any relevant fields. Not being able to have fields in there would be counter productive. It's just so handy to have all the functions + fields that govern this one element of your game all in one place.. When you need to make changes everything relevant is one place, and that place also functions as a black box that the other elements dont know about. So to change one feature in the game u just change or replace that one class.

Just looking at the functions, nice maintainable code would look identical in a functional or OO language. I think the big differences between functional and OO are actually not important. I could put functions in a class, or just together in the same file. Putting certain functions and fields into this same bucket is just a convenience and its intuitive to understand imo. Like I said in 6 months time when I have to change feature X I know where to look.

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

#47

Post by lmm »

substation13 wrote: post #36

The OOP community fascinates me. It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their way to support this kind of programming. Meanwhile the alternative approaches require you to jump through a bunch of hoops or apply convoluted "design patterns". Writing good, modern "OOP" you are often fighting the OOP language! Things are getting somewhat bette…

It suits cases (e.g. modelling business logic) where you have that kind of edge case. Until recently non-OO languages had very little support for delegation, and so while inheritance bundles delegation with some other things it really shouldn't be bundled with, it was often the least-bad option. In particular this made it a natural fit for GUI, where you very often want "this widget is almost like this one, except...", and so it was able to ride the coattails of that.

Add on the fact that people somehow seem to think Alan Kay has some insights (even if they can never tell you what they are), and Bob's your uncle.

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

#48

Post by substation13 »

lmm wrote: post #47
substation13 wrote: post #36

The OOP community fascinates me. It's clear that OOP in the sense of "Car extends Vehicle" is not a good idea, yet the classic OOP languages go out of their way to support this kind of programming. Meanwhile the alternative approaches require you to jump through a bunch of hoops or apply convoluted "design patterns". Writing good, modern "OOP" you are often fighting the OOP language! Things are getting somewhat bette…

It suits cases (e.g. modelling business logic) where you have that kind of edge case. Until recently non-OO languages had very little support for delegation, and so while inheritance bundles delegation with some other things it really shouldn't be bundled with, it was often the least-bad option. In particular this made it a natural fit for GUI, where you very often want "this widget is almost like this one, except...…

> non-OO languages had very little support for delegation,

What do you mean by "delegation" here?

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

#49

Post by bdg »

734129837261 wrote: post #41
bdg wrote: 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…

Yes, our industry has a lot of inexperienced managers and interviewers who don't know what to evaluate or how to clarify the goal for a candidate.

I think this is a different challenge related to the "background" hidden context: training interviewers. I think the "foreground" discussion point ("please make me a car") is way less relevant than the skill of an interviewer.

For about a year I tried this with every candidate: literally tell them what I am looking for in the interview and what is on my scorecard. Nobody asked any questions even once.

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

#50

Post by lmm »

substation13 wrote: post #48
lmm wrote: post #47

Earlier quoted context omitted.

It suits cases (e.g. modelling business logic) where you have that kind of edge case. Until recently non-OO languages had very little support for delegation, and so while inheritance bundles delegation with some other things it really shouldn't be bundled with, it was often the least-bad option. In particular this made it a natural fit for GUI, where you very often want "this widget is almost like this one, except...…

> non-OO languages had very little support for delegation, What do you mean by "delegation" here?

I mean something like "this value contains this kind of value and implements the same interface as it by forwarding methods to the corresponding methods on that". E.g. https://kotlinlang.org/docs/delegation.html . (i.e. imagine doing something similar to inheritance but having the "parent" object be explicitly a field of your child object rather than just mushed together with it).
Post reply on HN