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

111–120 of 177 posts

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

#111

Post by codemonkey-zeta »

mynameisash wrote: post #38
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'm reminded of the "Object oriented programming is bad" series: https://youtu.be/QM1iUe6IofM

For anyone unfamiliar, I recommend the whole series, but it also culminates in the presenter rewriting an entire nontrivial OOP program into a procedural one and saving whopping amounts of code/complexity. The big example helps to show this isn't just abstract rambling against OOP.

https://m.youtube.com/watch?v=V6VP-2aIcSc

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

#112

Post by igouy »

jhbadger wrote: post #93
a4isms wrote: post #57

Earlier quoted context omitted.

The thing about the natural world is that “Nature does not practice OOP.” Our nice hierarchies of animals reflect our desire to build hierarchies. Those hierarchies are tools that are useful for many purposes, but they weren’t blueprints for constructing life. I speculate that if we think of our hierarchies as tools, they say at least as much about our own brains and the problems we’re trying to solve as the do about…

I disagree. Nature does practice OOP and taxonomic hierarchies are real things in nature if they are based on their evolutionary history. People say penguins are "flightless birds", but look how they swim. They don't swim like fishes. They basically are flying in water because they share the same genetic programming as other birds, just slightly modified to use a different medium. Nature doesn't re-implement things f…

Nature doesn't do design, period.

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

#113

Post by skadamat »

pbourke wrote: post #80
skadamat wrote: post #79

Object oriented programming was meant to be used in a Smalltalk environment, where immediacy & liveliness were key principles of the design. OOP wasn't meant to be used by professional programmers ever, but this is always always forgotten. Why do we still talk about OOP when it comes to professional / full-time programming? OOP was always meant to be about providing end-users a way to create programs & dynamic behavi…

I don’t get this originalist argument. After it’s introduction, OOP very clearly evolved in a professional direction almost immediately. Why would you erase that history, and the work of hundreds to thousands of people working on object technologies, because it wasn’t the original conception?

Fair point! I guess when I see people saying "OOP isn't getting us what we want" ... then I want to point out that it was adopted for a different use case for which people are claiming it's falling short for?

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

#114

Post by tester756 »

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'm not sure if we gained anything from OOP,

Yea, sure, we didn't gain anything.

Except milions of programmers being able to model complex real world into their software that powers almost everything now.

Even if it is "shitty" "hard to maintain"

then it at least works

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

#115

Post by sumy23 »

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

Class inheritance in OOP seems to be largely derived from such contrived examples as "Duck extends Animal." It's basically a worthless concept and OOP would be better without it. Composition over inheritance leads to much better code.

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

#116

Post by random314 »

JoshCole wrote: post #109
redisman wrote: post #96

Earlier quoted context omitted.

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…

I don't think this constitutes a formal proof on any way at all.

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

#117

Post by lamontcg »

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

It is useful to talk about "Bicycle inherits from Car with NumWheels set to 2" and "Boat inherits from Car with Surface set to WATER and not GROUND" as examples of Liskov violation.

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

#118

Post by jerf »

Banana699 wrote: post #103
dgb23 wrote: post #60

Earlier quoted context omitted.

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

I respect Alan Kay as a programmer and an intellectual, but the plain and simple reality is that his definition of OO is not the one that carried the day, and his definition has very little relevance in the world today.

If one squints hard enough, one could argue that we are continuing to move in his direction even so, slowly and in fits. But it's not because we have an Alay-Kay-OO language, and to the extent it is happening, it's not clear that it's happening at a level of abstraction that languages matter much with. When people use OO as a term today, it's a different definition.

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

#119

Post by random314 »

pphysch wrote: post #101
randyrand wrote: post #90

Earlier quoted context omitted.

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…

I kinda agree. But my personal take is different.

Functions can be invoked in at least 3 different ways or a mixture of the three

1. Prefix - C style f(x,y,z)

2. Infix - x + y; x.f(y,z); a join b

3. Post fix- (x,y,z) $ f

Infix is the best style in most cases, OOP accidentally helped programmers use a more readable infix style.

A lot of the benefits of OOP can be had by allowing good infix invocation support and interface support in an imperative non OOP language. Might as well throw in generics.

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

#120

Post by lamontcg »

sumy23 wrote: post #115
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 `…

Class inheritance in OOP seems to be largely derived from such contrived examples as "Duck extends Animal." It's basically a worthless concept and OOP would be better without it. Composition over inheritance leads to much better code.

You still need to extract the right components and abstractions.

And inheritance can be expressed in terms of composition, the base class(es) can be represented as composition and delegation instead (with a protected interface, a public interface and the implementation details all tightly coupled behind a single name which is what really makes it so poor).

Post reply on HN