Live data from Hacker News

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

web.archive.org

41–50 of 113 posts

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

#41

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.

I definitely agree that like these things aren't going to cause any sort of lasting brain damage or something. It gets overwrought.

I think that the taxonomy thing is kind of harmful though in that, as far as I can tell anyway, it only seems to be now that a lot of programmers are coming around to the idea that modelling things are taxonomies is less useful than other techniques.

Some code sins are pretty easy to cleanup: if someone writes a function that's doing too many things, it's not too hard to break it up, or if someone names things badly, usually it's enough just to rename it to better concepts. But deep inheritance hierarchies are often a massive pain to clean up, if you can even clean it up at all (outside packages might come to depend on your weird structure for instance).

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

#43

Earlier quoted context omitted.

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…

Do any functional languages support partial evaluation using named parameters? That would solve the parameter ordering complaint. As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.

Racket's curry supports keyword arguments.

https://docs.racket-lang.org/reference/procedures.html#%28de... (god links into the racket docs are ugly...)

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

#44
post #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…

Mammal interface is fine

interface Mammal { fun milk() }

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

#46

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

These days I find composition via dependency injection (of interfaces, not concrete implementations) to be a much better way to solve #3.

I would argue you should inject concrete implementations until you need an interface. Why add unnecessary indirection?

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

#47

Earlier quoted context omitted.

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…

Do any functional languages support partial evaluation using named parameters? That would solve the parameter ordering complaint. As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.

> As for higher order functions you would write a function that does the 90% and accepts a function parameter for the other 10%.

Surely you see how this doesn't scale, right?

You would need to first write your code, then abstract every single piece of it as a call to a function passed in parameters. Now your function is accepting five different functions in parameters, and calls them.

This is a terrible and impossible to scale way to emulate class specialization.

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

#48
post #29

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.

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 yo…

> Haskell’s typeclasses and OCaml modules solve this problem neatly.

Neither do, really.

Imagine you have an existing typeclass with three functions. How do you create your own typeclass that reuses two of these three functions but your own instance reimplements the third one?

Try it. It's pretty much impossible, or at least not without a lot of boilerplate and forwarding.

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

#49
post #29

Earlier quoted context omitted.

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 yo…

> Haskell’s typeclasses and OCaml modules solve this problem neatly. Neither do, really. Imagine you have an existing typeclass with three functions. How do you create your own typeclass that reuses two of these three functions but your own instance reimplements the third one? Try it. It's pretty much impossible, or at least not without a lot of boilerplate and forwarding.

Not sure what you mean, exactly. Could you sketch a simple example with some types and typeclasses?

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

#50
post #27

Earlier quoted context omitted.

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…

Mammal interface is fine interface Mammal { fun milk() }

I’m a mammal, Greg. Can you milk me?
Post reply on HN