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

The Big OOPs: Anatomy of a Thirty-Five Year Mistake

computerenhance.com

Post reply on HN
Print view View original

121–130 of 193 posts

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#121

Post by saghm »

shuaiboi wrote: post #105
DavidPiper wrote: post #65

So much gold to mine in this talk. Even just this kind of throwaway line buried deep in the Q&A: > I prefer to write code in a verb-oriented way not an object-oriented way. ... It also has to do with what type of system you're making: whether people are going to be adding types to the system more frequently or whether they're going to be adding actions. I tend to find that people add actions more frequently. Suddenly…

bjarne (creator of c++) has a quote about this: Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. https…

The main benefit of x.f(y) IMO isn't emphasizing x as something special, but allowing a flat chain of operations rather than nesting them. I think the differences are more obvious if you take things a step further and compare x.f(y).g(z) and g(f(x, y), z). At the end of the day, the difference is just syntax, so the goals should be to aid the programmer in writing correct code and to aid anyone reading the code (including the original programmer at a later point in time!) in understanding the code. There are tradeoffs to using "method" syntax as well, but to me that mostly is an argument for having both options available.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#122

Post by saghm »

pjmlp wrote: post #102
treve wrote: post #101

Earlier quoted context omitted.

This is less about what metaphors are under the hood, but the patterns used on top of them. You can get technical, but it's definitely possible to write primarily functional, imperative or object-oriented code in Python, irrespective of what the syntax is for dealing with primitives.

Not really, because in machinery requires OOP to work. That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM. It is like arguing one is not driving a steam engine only because they now put gas instead of wood.

I think you have things backwards; you're the one complaining about the the underlying implementation, whereas the others are talking about the interface for it. They're talking about whether they prefer to drive cars or trains, and you're basically claiming that there's no difference between a car and a train if the train also runs on gas.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#123

Post by xg15 »

OOP has lots of flaws and is not a good choice in every context, but I still don't understand the universal hatred it seems to get now.

I think OOP techniques made most sense in contexts where data was in memory of long-running processes - think of early versions of MS Office or such.

We've since changed into a computing environment in which everything that is not written to disk should be assumed emepheral: UIs are web-based and may jump not just between threads or processes but between entire machines between two user actions. Processes should be assumed to be killed and restarted at any time, etc etc.

This means it makes a lot less sense today to keep complicated object graphs in memory - the real object graph has to be represented in persistent storage and the logic inside a process works more like a mathematical function, translating back and forth between the front-end representation (HTML, JSON, etc) and the storage representation (flat files, databases, etc). The "business logic" is just a sub-clause in that function.

For that kind of environment, it's obvious why functional or C-style imperative programming would be a better fit. It makes no sense to instantiate a complicated object graph from your input, traverse it once, then destroy it again - and all that again and again for every single user interaction.

But that doesn't mean that the paradigm suddenly has always been bad. It's just that the environment changed.

Also, there may be other contexts in which it still makes sense, such high-level scripting or game programming.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#124

Post by pjmlp »

zaphar wrote: post #108
pjmlp wrote: post #96

Earlier quoted context omitted.

ECS is a part of OOP, hence why languages like Objective-C introduced protocols, while others like C++ and Eiffel went the multiple inheritance route. Even Smalltalk, post Smalltalk-80 implementations eventually added traits, alongside its single inheritance model.

I am not sure what the link between ECS and protocols, traits, and multiple inheritance is? ECS is mostly about memory layout not typed interfaces as far as I know.

Nope, that is the gist that game devs then apply to ECS story.

If you want to go down the rabbit hole, lets start with the first question, how are ECS systems implemented in any random C++ or Rust game code?

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#125

Post by pjmlp »

constantcrying wrote: post #117
pjmlp wrote: post #95

Earlier quoted context omitted.

There is no such thing as non-OO Python, the language is like Smalltalk, everything is an object, even plain numeric values. This wasn't true with original Python, however since new style classes became the default type system, everything is indeed an object. So for the anti-OOP folks out there using languages like Python as an example, Python 3.13.0 (tags/v3.13.0:60403a5, Oct 7 2024, 09:38:07) [MSC v.1941 64 bit (AM…

The talk makes a very specific complaint. That complaint is not that you are associating data with the functions operating on that data. What the talk is about compile time (and maybe execution time in the case of python) hierarchies being structured as a mapping of real objects. This is how I was taught OOP and this is what people are recognizing as "OOP". >So for the anti-OOP folks out there using languages like Py…

What matters are language implementations and CS definitions, not layman understanding on the street.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#126

Post by pjmlp »

saghm wrote: post #122
pjmlp wrote: post #102

Earlier quoted context omitted.

Not really, because in machinery requires OOP to work. That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM. It is like arguing one is not driving a steam engine only because they now put gas instead of wood.

I think you have things backwards; you're the one complaining about the the underlying implementation, whereas the others are talking about the interface for it. They're talking about whether they prefer to drive cars or trains, and you're basically claiming that there's no difference between a car and a train if the train also runs on gas.

I am complaining about the distortion field OOP haters happen to have regarding language semantics.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#127

Post by pjmlp »

SeanDav wrote: post #120
pjmlp wrote: post #102

Earlier quoted context omitted.

Not really, because in machinery requires OOP to work. That apparently non-OOP code, requires bytecodes and runtime capabilities that only exist with OOP semantics on the VM. It is like arguing one is not driving a steam engine only because they now put gas instead of wood.

You stopped too soon - those apparently OOP semantics ultimately require decidedly non-OOP machine code at the real level it is executed. Everything else is just abstraction. Trying to argue that you are, in fact driving a steam engine, requires one to assume a level of abstraction and definition, in order to set an arena in which a discussion can occur.

Except we are talking about the layer written on top of Python, not underneath.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#128

Post by pjmlp »

virgilp wrote: post #116
pjmlp wrote: post #94

Earlier quoted context omitted.

There are OOP languages that use doThing(X, Y), though. Ada, Julia, Dylan, Common Lisp for example. Yet another example why people shouldn't put programming paradigms all into the same basket.

There are a handful of (somewhat exotic) languages that support multiple dispatch - pretty much, all those listed by you. None of the mainstream ones (C++, Java, C# etc) do. (also Common Lisp is hardly a poster child of OOP, at best you can say it's multi-paradigm like Scala)

I guess Julia and Clojure are exotic.

Since when do OOP languages have to be single paradigm?

By then point of view, people should stop complaining about C++ OOP then.

Re: The Big OOPs: Anatomy of a Thirty-Five Year Mistake

#130

Post by constantcrying »

pjmlp wrote: post #125
constantcrying wrote: post #117

Earlier quoted context omitted.

The talk makes a very specific complaint. That complaint is not that you are associating data with the functions operating on that data. What the talk is about compile time (and maybe execution time in the case of python) hierarchies being structured as a mapping of real objects. This is how I was taught OOP and this is what people are recognizing as "OOP". >So for the anti-OOP folks out there using languages like Py…

What matters are language implementations and CS definitions, not layman understanding on the street.

What a silly objection. You just made up a random argument in your head what that talk was about or what arguments are being made.

It actually does matter a whole lot what developers think. It matters far more than any "CS definition", not that anything here is about computer science.

>What matters are language implementations

No, they do not matter at all. They are totally irrelevant to the topic. In python you can construct your hierarchies to match real world hierarchies. You also can not do that. It is totally irrelevant how the language is implemented.

Post reply on HN