Live data from Hacker News

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

mail-archive.com

61–70 of 177 posts

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

#61

Perhaps this would work: Build a program that... * That has a hardcoded list of strings baked into it * Accepts as inputs a filename (but can be empty) and a substring to search for * At runtime, either (a) (if filename empty) iterates over hardcoded list of strings, or (b) opens file and iterates over lines in it * For each string / line, if contains search string then output to stdout (and maybe also increment a co…

Refactoring something along the lines of static void Main(string[] args) { var filename = args[0]; var needle = args[1]; var linesToProcess = filename != '' ? File.ReadAllLines(filename) : HardcodedLines; ProcessLines(linesToProcess, needle); } static void ProcesLines(string[] linesToProcess, string needle) { // lines-processing code... } into something like static void Main(string[] args) { var filename = args[0]; v…

I'm not clear on what you GetLines() method is returning (thanks to the var keyword - very useful but sometimes problematic, this is one of those times).

If your GetLines() is returning a string[] then I agree there was no benefit. But that's not what I meant. As I said, I'm imagining the base class (ILinesProvider) to have an iterator-like interface. So, rather than string[] GetLines() method, it would have a string getNextLine() method that you call in a loop. That way, with the file, you don't load the whole thing in memory (as I also said).

If your GetLines() method is returning an IEnumerable (since this seems to be C#) then this is the problem I mentioned at the end of my comment - the base class I'm imagining is similar to an existing base class in the language, and it's confusing to write your own similar-but-slightly-different version in an example. But I think it's best to do it anyway and explain it away in a footnote. (But my ILinesProvider wouldn't return an IEnumerable, like in your snippet - instead, ILinesProvider actually is the iterator (but with a slightly different interface).)

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

#62
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…

Not including the racist discrimination example, I'm not sure that this is a bad problem. I believe there is a tendency for us to leave the schooling system and start viewing interviews as though they were our new exams, where failure is your own fault. I argue that interviews are the starting point of a new relationship, so the closest analogy is actually a date. If you're on a date and express your values and the other person rejects you for it, it simply means you don't make a good relationship - even if it's just because the other person has unfair demands.

So don't project programming ideals you don't believe in. If they can't reconcile different opinions, it's their problem. You won't have the conviction or experience to do it convincingly anyway.

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

#64

After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…

I'm reminded of the "Object oriented programming is bad" series: https://youtu.be/QM1iUe6IofM

It's really great, highly recommend it!

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

#65

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…

Not including the racist discrimination example, I'm not sure that this is a bad problem. I believe there is a tendency for us to leave the schooling system and start viewing interviews as though they were our new exams, where failure is your own fault. I argue that interviews are the starting point of a new relationship, so the closest analogy is actually a date. If you're on a date and express your values and the o…

And if they don't like you asking questions, you've really dodged a bullet!

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

#67
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…

"Car/Animal extends..." slowed my ability to comprehend OOP significantly when I was learning to code. It just did not make any sense to me and I felt like an idiot for not being able to equate these "real-world" examples to the code I was trying to write. I just could not make the connection.

It wasn't until I started trying to make a simple video game that these concepts made sense: an "Enemy" class could have properties of health and speed that a "Boss" or "Minion" could inherit from, etc.

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

#69
post #50

Earlier quoted context omitted.

> 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).

Ah I see. What you say is not quite true though, ad-hoc polymorphism (traits) provides the same functionality for non-OOP languages.

> Until recently non-OO languages had very little support for delegation

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

#70

After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…

> “The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” – Joe Armstrong
Post reply on HN