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

141–150 of 193 posts

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

#141

Post by saghm »

pjmlp wrote: post #126
saghm wrote: post #122

Earlier quoted context omitted.

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.

That's fair, but I'd still argue that there's a difference in whether code has to be written by defining objects directly or being able to work at a different abstraction level where objects are an underlying implementation detail that get leveraged by other language constructs that are familiar from non-OO paradigms. Whether or not that difference is important or good is a subjective opinion, but I don't see an argument about the underlying implementation as a particularly strong refutation of someone stating that they like having that level of abstraction available.

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

#142

Post by nickitolas »

rr808 wrote: post #82

I really dont understand his reasoning. If you have a pointer to the base class different implementations are polymorphic and its hidden from the caller. That is the whole point and it means you can have an engine with a base class in a library, then different people can derive from it and use that engine. I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different na…

> I think his definition of OO is different to what we've got used to. Perhaps his definition needs a different name.

I've seen "OOP" used to mean different things. For example, sometimes it's said about a language, and sometimes it's unrelated to language features and simply about the "style" or design/architecture/organization of a codebase (Some people say some C codebases are "object oriented", usually because they use either vtables or function pointers, or/and because they use opaque handles).

Even when talking about "OOP as a programming language descriptor", I've seen it used to mean different things. For example, a lot of people say rust is not object-oriented. But rust lets you define data types, and lets you define methods on data types, and has a language feature to let you create a pointer+vtable construct based on what can reasonably be called an interface (A "trait" in rust). The "only" things it's lacking are either ergonomics or inheritance, or possibly a culture of OOP. So one definition of "OOP" could be "A programming language that has inheritance as a language feature". But some people disagree with that, even when using it as a descriptor of programming languages. They might think it's actually about message passing, or encapsulation, or a combination, etc etc.

And when talking about "style"/design, it can also mean different things. In the talk this post is about, the speaker mentions "compile time hierarchies of encapsulation that match the domain model". I've seen teachers in university teach OOP as a way of modelling the "real world", and say that inheritance should be a semantic "is-a" relationship. I think that's the sort of thing the talk is about. But like I mentioned above, some people disagree and think an OOP codebase does not need to be a compile time hierarchy that represents the domain model, it can be used simply as a mechanism for polymorphism or as a way of code reuse.

Anyways, what I mean to say is that I don't think arguing about the specifics of what "OOP" means in the abstract very useful, and that since in this particular piece the author took the time to explicitly call out what they mean that we should probably stick to that.

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

#143

Post by saghm »

atsbbg wrote: post #138
saghm wrote: post #121

Earlier quoted context omitted.

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

That's exactly the context of where this quote comes from. He wanted to introduce Unified call syntax[1] which would have made both of those equivalent. But he still has a preference for f(x,y). With x.f(y) gives you have chaining but it also gets rid of multiple dispatch / multimethods that are more natural with f(x,y). Bjarne has been trying to add this back into C++ for quite some time now. https://www.open-std.or…

That makes sense! It wasn't immediately obvious to me from the context of this discussion though, since it seemed like you were responding to the parent comment's framing of it as a choice between one or the other. This might just be from me never having heard of the term "unified call syntax" though, and I admit that I didn't expect to need to read through the PDF you linked before super carefully after opening it and seeing a bunch of C++-specific details that I knew would go over my head. (On a good day, I can remember what words SFINAE is an acronym for, but I don't think I ever really felt like I got comfortable enough with C++ to fully understand how the template code I saw actually encoded behavior that fit what I'd expect those words to mean).

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

#144

Post by dsego »

tgv wrote: post #112
dsego wrote: post #111

Earlier quoted context omitted.

No offense, but this reads as a GPT generated summary.

I had difficulty understanding what irked me about the comment, but indeed, that's it. The mix of superficiality, congeniality, and random details sound like an AI response. However, I don't think it is. But AI surely fucks up our trust.

Why not, it's a fresh new account, and doesn't bring any new insight, why would anyone genuinely write a comment like that?

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

#145

Post by igouy »

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)

Multi-methods do seem like a missed opportunity:

"Visitor Pattern Versus Multimethods"

https://nice.sourceforge.net/visitor.html

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

#146

Post by MantisShrimp90 »

mrkeen wrote: post #140
vkazanov wrote: post #132

Earlier quoted context omitted.

The problem is that once you exclude domain-specific hierarchy from the discussion, there's not much left of OOP. It's just data + relevant functions. Which is ok. That's all there is, really.

And Rich Hickey calls out even that last feature as a mistake, and I tend to agree. https://gist.github.com/reborg/dc8b0c96c397a56668905e2767fd6...

You get it

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

#147

Post by user____name »

pjmlp wrote: post #124
zaphar wrote: post #108

Earlier quoted context omitted.

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?

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

What do you mean? ECS is simply a game programming pattern to implement an entity system.

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

Conversely how would you implement it in a procedural language like C or Pascal? ECS is just a switch in emphasis from an array of structures (entities) to a structure of arrays (systems) paradigm. I fail to see what the Object Oriented paradigm has to do with any of it.

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

#148

Post by user____name »

antonvs wrote: post #47
cma wrote: post #17

Earlier quoted context omitted.

Not the closed caption button. In the bottom of the description there is "show transcript" which gives a scrollable transcript.

He’s too busy reading thousands of words a minute to actually understand any of them.

I was able to go through War and Peace in 20 minutes. It’s about Russia.

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

#149

Post by vjvjvjvjghv »

lisbbb wrote: post #87
vjvjvjvjghv wrote: post #66

Earlier quoted context omitted.

I was around when OOP became popular in the 90s. I think it was a huge step forward. Problem is that with almost every useful paradigm at some point consultants and zealots take over and push things to an extreme that doesn't work. And when problems show up, it's because you didn't do it right. Happened with OOP, NoSQL, Agile and probably many others. I don't see how functional style won't go differently.

Despite spending untold hours learning and using C++ and Java, I never fully believed that OOP was anything great. It always felt so forced to code everything in terms of classes rather than just modules of code that have similar responsibilities.

The whole code everything in classes idea came up when the purists took over. I (and most reasonable people I know) wrote most of their code in single functions and used instantiable classes only where it made sense. A class with only static methods is basically a module.

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

#150

Post by igouy »

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…

> This is how I was taught OOP …

That's unfortunate.

"The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. …

While superficially appealing, this approach is seriously flawed. 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. …"

"Designing Object Systems", Steve Cook & John Daniels, 1994, page 6

https://archive.org/details/designingobjects0000cook

Post reply on HN