Live data from Hacker News

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

web.archive.org

21–30 of 113 posts

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

#21

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

Well said.

And #3 is also an area where Functional Programming falls completely flat.

There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%".

Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.

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

#22
The article completely misses the point because it sets up a large amount of straw men that are completely unrelated to the point

The fact that "Car extends Vehicle" is sometimes a subpar modelization has nothing to do with OOP or inheritance and everything to do with the fact that the English language is not specific enough to describe what a Vehicle is well.

Same goes with "Duck extends Bird". Yes, there are a few birds that don't fly. This problem has nothing to do with programming languages, inheritance, or OOP.

I still find these two examples, "Duck extends Bird" and "Car extends Vehicle" as extremely powerful to teach beginners what OOP is about.

Like all metaphors, they tend to leak if you push them too far, but they do a splendid job at introducing beginners to the concept of OOP, which is going to serve them well for probably most of their professional life.

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

#23

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

Well said. And #3 is also an area where Functional Programming falls completely flat. There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%". Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.

Functional programmers will reply that you can use partial evaluation and higher-order functions to do that.

The sad reality is that since so many people are only familiar with the strawman version of OOP rather than the real thing intelligently discussing the advantages and disadvantages of these paradigms is very hard.

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

#24

I tend to agree. The “duck extends bird” examples sound good at first but they have done a lot of damage to OOP.

I find this a largely unsubstantiated claim, much like the "Once you learn BASIC, your brain is damaged beyond repair" from Dijkstra that is so depressingly repeated over and over, and which is complete nonsense.

These are introductory metaphors that help people get up to speed with a complex concept. You refine your understanding of these as you become more expert on the subject.

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

#25

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

Well said. And #3 is also an area where Functional Programming falls completely flat. There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%". Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.

>There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%".

Honest question: why does the Common Lisp Object System not do this for you?

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

#26

Earlier quoted context omitted.

Well said. And #3 is also an area where Functional Programming falls completely flat. There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%". Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.

Functional programmers will reply that you can use partial evaluation and higher-order functions to do that. The sad reality is that since so many people are only familiar with the strawman version of OOP rather than the real thing intelligently discussing the advantages and disadvantages of these paradigms is very hard.

Yes, I've heard them say that indeed. They often gloss over a lot of issues about these.

For example, partial evaluation is limited by the fact that parameters need to be ordered a certain way and you can't realistically cover all combinations.

Higher order functions don't enable any kind of useful specialization at all. And of course, all modern OOP languages also support higher order functions, so they are the ones giving you more tools.

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

#27

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

We spend so much time in college learning about tree structures that hash tables are almost an exception. Which is weird because I use hash tables every single day.

I also didn’t learn about the Liskov Substitution Principle in college or in my first few years in an OOP. Had to find it on my own and start teaching others. But I was in good company because Josh Bloch also didn’t understand it and a whole generation of devs aped his solutions.

People think of inheritance as additive but if you look at the code they write it’s often subtractive. Mammal is not a contract. Every fork in the tree is carving out more negative space than it adds.

Mammal is really a pretty terrible root. Some mammals are nocturnal. Some fly. One lays eggs. A few have no hair and we think hairy humans are gross. Some can hold their breath for hours and live four hundred years. Others measure life in days.

But not a single one is all of these things. If we talk about what mammals can do we include it all. But you can’t ask these things of most of them. You don’t even organize them by these traits (what’s in the tropical or night exhibit at a large zoo? Why are the seals and penguins together?)

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

#28
post #25

Earlier quoted context omitted.

Well said. And #3 is also an area where Functional Programming falls completely flat. There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%". Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.

>There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%". Honest question: why does the Common Lisp Object System not do this for you?

Honest answer: you have a point :-)

Yes, CLOS offers all of that.

I just didn't quite consider it to be in the bucket of FP languages I had in mind (which to me means: statically typed, and some derivative of Haskell or OCaml).

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

#29

>In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. This correctly identifies one of the worst problems with how people construct OO programs when they get out of college. They are infected with the idiotic desire to make neat taxonomies. They don't know why. They can't even explain the rules that make one taxonomy good and another one bad. They just feel some immense pres…

Well said. And #3 is also an area where Functional Programming falls completely flat. There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%". Specialization is a very, very powerful aspect of OOP, one that's extremely easy to explain and which comes in handy to model a surprisingly wide variety of problems.

And #3 is also an area where Functional Programming falls completely flat. There is simply no easy way in any FP language that I know to capture such a simple mechanism as: "Reuse 90% of this piece of code but alter just this 10%".

Haskell’s typeclasses and OCaml modules solve this problem neatly. It is not as easy as in Java, because you need to spend a few minutes thinking how to abstractly specify the interface you expect, but really if your object hierarchy is supposed to satisfy Liskov’s substitution principle, you need to do that just the same.

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

#30
post #5

> You can’t add code to ducks. > You can’t refactor ducks. > Ducks don’t implement protocols. > You can’t create a new species in order to separate some concerns (e.g. file I/O and word splitting). It's odd he makes these complaints, because the comment he's responding has this caveat: > unless they are talking about writing a clone of The Sims or something In the context of a game or simulation, such classes can abs…

> It's odd he makes these complaints, because the comment he's responding has this caveat:

> > unless they are talking about writing a clone of The Sims or something

Although I formatted it as a quote, I wasn't quoting or responding to somebody else in that part. That part about the Sims was part of the somewhat flippant principle I was proposing. The litany about ducks was just to explain the reasons for it. It wasn't a rebuttal.

We regret the inconvenience.

Post reply on HN