[deleted]
Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
81–90 of 113 posts
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#82Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#83>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.
Isn't this just composition? Function A calls B, C, and D. You make a new function E that calls B, C and F. Or higher order functions like map?
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#84I 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.
"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."
From my experience a lot of people get stuck with these introductory metaphors and never progress further. That's why I think they are harmful.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#85Oh my god, not all birds fly, it ruins the whole thing!!!!!
No, it's a perfectly fine place in the analogy, to have a teachable moment. Since not all birds fly, just don't make flight part of your base class. I mean? Or get clever and have flighted and flightless bird classes inherit from Bird? If you want to be that much of a pain about it, you can; the paradigm supports it.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#86Earlier quoted context omitted.
Not sure what you mean, exactly. Could you sketch a simple example with some types and typeclasses?
This is how it would be done in Java: class Parent { public void first() {}; public void second() {}; public void third() {}; } class Child extends Parent { @Override public void third() {}; //change implementation of third function, reusing the first two. }
In OCaml:
module Foo = struct
let first = 1
let second = 2
let third = 3
end
module Bar = struct
include Foo (* Include contents of [Foo] *)
let third = 4 (* Override [third] *)
endRe: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#87>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…
> Inheritance is a result of several insights:
> 1. It's convenient to be able to sketch out a protocol which a set of objects will follow - without having to work out every damn detail about its implementation.
> 2. Most of the protocol can be implemented once and then reused.
> 3. Often you want to use the default protocol implementation with some changes. Instead of re-implementing the rest of the protocol, it's highly convenient to be able to specify only the differences.
> #3 is the core reason why inheritance was developed.
Those insights lead to what was taught in my intro to cs class: abstraction. Inheritance can be used to implement abstraction, but so can many other concepts such as duck typing or aspect oriented programming.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#88> 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…
Even though I disagree with it, I think it was still a valuable point.
And everyone should deliver a litany about ducks at some point in their life.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#89>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.
When I stopped thinking about code and data as being inherently intertwined it liberated me as both an OOP and Functional programmer.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#90Why, these are flavors of CLOS or type-classes (rather type-traits) of Haskell.
Trait define what-it-takes-to-be-a instead of just is-a. This idea is fundamental and have been realized by all serious programmers.
Type-classes is the most important innovation since structural programming.