Live data from Hacker News

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

web.archive.org

51–60 of 113 posts

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

#51

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

It doesn't seem hard to add a parameter and then make two stubs:

  complex_function small_part = do
    a 
There are some issues if you have a lot of parameters where you might want a record to pass them around, but specialization is easier to use than inheritance in all the cases I've seen.

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

#52
post #45
post #42

Geez, chill out. I can't stand profanity.

I don't mean this in a gatekeeping way, but if you've never been inspired to use profanity by an OO design, you probably aren't yet in the target audience.

That doesn't make sense.

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

#53
post #50

Earlier quoted context omitted.

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

I’m a mammal, Greg. Can you milk me?

Depends on your species, Steve

https://en.wikipedia.org/wiki/Male_lactation

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

#54

Earlier quoted context omitted.

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

> Surely you see how this doesn't scale, right?... This is a terrible and impossible to scale way to emulate class specialization.

Heretic! Have not the elders of our holy church indeed canonized the ex cathedra dogmas of variable immutability and higher-order functions with closed variables? And indeed have we not been in ecumenical agreement over the incomprehensible mystery of the trinity of higher order types, dependent types, and polymorphic types? Dare ye teach heresy proudly with thy contumely? Anathema sit!

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

#55
post #42

Geez, chill out. I can't stand profanity.

You’ve given other people control over your emotional states. Not even with elaborate statements. Just with individual words.

What sort of compromising positions do you suppose that’s put you into, or will in the future?

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

#56
post #52
post #45

Earlier quoted context omitted.

I don't mean this in a gatekeeping way, but if you've never been inspired to use profanity by an OO design, you probably aren't yet in the target audience.

That doesn't make sense.

Start here perhaps:

https://www.wired.com/2011/02/cussing-in-commits-which-progr...

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

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

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You…

> It's still very OOP, but not in the sense of representing real-world taxonomies.

1. OOP was never about "representing real-world taxonomies."

2. Real-world taxonomies are often not very good at representing real-word taxonomies.

Programmers are highly susceptible to scientism, and it's ruined whatever chance OOP had of being a tool rather than an ideology.

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

#59
post #49

Earlier quoted context omitted.

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

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.
  }
Post reply on HN