Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mail-archive.com

Post reply on HN
Print view View original

101–110 of 177 posts

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

#101

Post by pphysch »

randyrand wrote: post #90
DeathArrow wrote: post #20

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 just wrote 60k lines of C code and have never once felt the need for OOP. And I say that as someone who has spent their whole career with OOP. If I need some functionality, I write a function and pass it a struct. I’ve yet to find a time when this approach is too limiting, or chaotic. Even for interfaces, function pointers achieve that goal entirely. I do miss type safe vectors, e.g templating. Thats above and beyo…

Bound methods simply has the potential to be a tiny bit more readable:

`thing.doWork(arg)`

`doWork(thing, arg)`

`doThingWork(thing, arg)`

The first example is marginally more readable IMO. The second one sucks from a human perspective because we don't immediately know (unlike the IDE) that the function signature only accepts Things. The last one addresses this but is even longer, and we still have to mentally unpack the args.

IMO there is not much profound about OOP, but it can lead to slightly more readable code if used appropriately.

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

#102

Post by nmilo »

Obviously modelling your program like Car extends Vehicle is bad, but thinking in terms of real-life relations makes thinking about complex subtyping relations like covariance much easier to grasp.

Compare:

> If B and C are subtypes of A, then List must be invariant over T since List should not be a subtype of List, which can contain both B and C.

with:

> List can't become List, because you might add Dogs to that list!

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

#103

Post by Banana699 »

dgb23 wrote: post #60
DeathArrow wrote: post #20

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 best thing that object orientation popularized is the interface/protocol abstraction. All the modern languages I learned put this front and center: Go's interfaces, Clojure's protocols and multimethods, Rust's traits. This apparently goes back to part of the inspiration of Smalltalk (dataless programming). It enables you to create an ubiquitous language and radically improves your ability to structure a program i…

>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.

- Alan Kay -

Other remarks from him about OOP are (paraphrased):

- OOP is a recursion on the notion of the computer itself

- The internet\Erlang is more OOP than java

His vision for OOP is something akin to distributed computing: Each object is a seperate computer with its own private memory that absolutely nobody can write to, it presents to the world an interface which is the set of all messages it can respond to (messages might or might not be asynchronous, and might or might not be unreliable in order,delivery,etc...). "Late Binding" because you have zero gaurantees about anything not explicitly stated in the object's contract, anything the object doesn't promise to respect will be violated, you better not depend on it. This is to give freedom to as much different implementation of the same interface as possible.

Two other analogies I encountered are

- Objects are like hardware ICs (their interfaces are the external pins and the type of signals the IC expects on them, their internals is the private hardware and signals that nobody is expected to inspect or modify)

- Objects are like seperate programs (their interfaces are the GUI/cmd the program presents and the set of all possible actions you can do, their internals are the executable code and in-memory data structures that nobody is expected to inspect or modify)

Inheritance actually precedes mature OOP, it was introduced way back in Simula-62, the proto-OOP language that wasn't a proper language as much as a simulation framework. Inheritance makes perfect sense in a simulation framework, because you're modelling a small world with a definite ontology that you can articulate and be sure of, the creators of Simula stumbled on it when they found they were repeatedly duplicating code verbatium. The analogies of Car<Vehicle and Cat<Animal make perfect sense, this is what inheritance is really made for, it's just that most real software isn't discrete event simulations with platonic ontologies.

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

#104

Post by jansan »

Ensorceled wrote: post #83

As someone who has been using OOP since C++ was Cfront and you fetched it from usenet ... I find these conversations fascinating. It's like listening to a conversation about cars where someone says they hate cars because you have to figure out a manual choke and the many inner tube failures. Do people still use these crazy inheritance trees? I haven't encountered it since the early 2000's.

Does this count?

    EventTarget -> Node -> Element -> SVGElement -> SVGGraphicsElement -> SVGTextContentElement -> SVGTextPositioningElement -> SVGTSpanElement
And the whole tree could be described as "crazy", but it does actually make sense.

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

#105

Post by igouy »

DeathArrow wrote: post #20

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

> … using objects you can model or imitate real life, but that is silly.

1994 "It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does.

… we use different sets of building blocks for modelling the world and modelling the software …"

page 6 "Designing Object Systems"

https://www.google.com/books/edition/Designing_Object_System...

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

#107

Post by hikarudo »

mackman wrote: post #106

Long ago in the games industry I was applying for a position at a studio. Didn't end up getting a job but a friend did. A few months later he was bemoaning their terrible code base which included a car class that inherited from wheel four times.

"A car is a wheel, and is a wheel, and is a wheel, and is a wheel".

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

#108

Post by igouy »

qsort wrote: post #39
DeathArrow wrote: post #20

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

For all its blemishes it's still the most natural way to represent the concept of "user-defined data type" in a procedural language. "Modeling the world as OOP", OTOH, is a load of bull.

"It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does.

… we use different sets of building blocks for modelling the world and modelling the software …"

1994 "Designing Object Systems"

https://www.google.com/books/edition/Designing_Object_System...

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

#109

Post by JoshCole »

redisman wrote: post #96
dymk wrote: post #88

I disagree with the article, which talks about building a holistic understanding when learning, and then ironically misses the forest for the trees regarding programming metaphors. The author is obviously an experienced programmer, so I suspect they've forgotten what the mindset of an absolute novice is like, and to start programming with zero prior exposure to the concepts. For the novice being introduced OOP, the `…

I disagree. Teaching people to think about abstractions wrong is not in any way helpful. Everyone I know including myself had to spend years writing bad code before realizing that this way of thinking is counterproductive. It reminds me of this quote from Kung Pow Don’t worry about Wimp Lo, he’s an idiot. We’ve purposefully taught him wrong… as a joke. Composition is an infinitely better method to teach if you have t…

Abstractions are useful because they simplify and if you don't allow error you don't allow maximization of simplification. You can formally relate this to learning problem formulation complexity. When you do you encounter things like branching factors which effect solution times which lead to natural results like fast but finishes being better than optimal but never terminates. This can hold even despite error in the abstraction and there are techniques for recovering that error at runtime because a particular problem is a less general and more specific situation and so isn't as cursed by branching factor.

Edit: A previous version of this comment was more wordy in stating this and mentioned that there are formal proofs to this effect.

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

#110

Post by dang »

Related:

Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011) - https://news.ycombinator.com/item?id=21298341 - Oct 2019 (101 comments)

Goodbye, shitty "Car extends Vehicle" object-orientation tutorial - https://news.ycombinator.com/item?id=2914405 - Aug 2011 (128 comments)

Post reply on HN