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

The Repeated Deaths of OOP (2015)

loup-vaillant.fr

Post reply on HN
Print view View original

181–190 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#181

Post by bccdee »

jayd16 wrote: post #163
bccdee wrote: post #125

Earlier quoted context omitted.

Being written in an object-oriented language doesn't make code object-oriented. I could write Java using classes as (namespaces for stateless functions) XOR (structs with no methods), and while it'd still technically all be objects and methods, in practice it wouldn't embody the spirit of OOP at all. It is in keeping with the spirit of OOP to wrap up different entities' data in separate objects and have them interact…

>Exposing all of every entity's data to the world and letting unaligned actors unilaterally mutate many entities' state But that is NOT the pattern. Entities are ids, they have component tags that opt entities into some functionality and the systems encapsulate and track the mutable state that system controls. If you want to start sharing ownership of mutable state, that basically comes down to an implementation deta…

Don't systems sometimes have to access each other's components to do work? Isn't any given component exposed to all systems, and not merely one?

Re: The Repeated Deaths of OOP (2015)

#182

Post by carapace »

kaba0 wrote: post #144
carapace wrote: post #137

Earlier quoted context omitted.

That answer is so informative and yet it completely misses the point. The problem is even called out in the answer itself: > For example, our example "Edinburgh has been the capital of Scotland since 1999" signifies the fact that "capital of Scotland" depends on the time at which it is being considered. Such context-dependence is a reality, both in natural languages and programming languages. "Therein lies the rub."…

I agree with you, but this property of FP languages is called pureness/not-having side effects, not referential transparency. The latter is (quoting pron’s older comment: https://elarib.com/item?id=22141647 ): “an expression e is referentially transparent if any sub-term in it can be replaced with any other having the same reference (aka denotation) without changing e's reference”. Perhaps I should have linked this c…

Fair enough. (I'm getting old, it hurts my head to imagine pure-but-not-referentially-transparent language; however, imagining referentially-transparent impure language doesn't.)

Re: The Repeated Deaths of OOP (2015)

#183

Post by ratww »

jayd16 wrote: post #169
ratww wrote: post #110

Earlier quoted context omitted.

ECS is doing a bit more than looping over arrays, though. In modern production ECS systems there's often the case where a System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2) , O(n^3) , O(n^4) , etc, etc complexity), so it's nowhere near as simple as that. Like I said, it's possible to implement anything that is computable in any Turing-…

> System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2), O(n^3), O(n^4), etc, etc complexity), so it's nowhere near as simple as that. Am I missing something? Sort your data structure and quickly loop over them? Why would you ever do things at n^4 complexity? > then it's only fair to say that OOP is also just a design pattern Yup. It is.…

> Am I missing something?

Yeah. You're missing the part where I said ECS is not just looping. It's clearly also not just sorting, if you know how ECS is structured. You need either indexing, like databases, or you need to watch for changes and cache them before usage, like in SQL materialised views. If you want to keep discussing the basics of ECS I strongly suggest searching at least how it is structured, its goals, and how it works.

Re: The Repeated Deaths of OOP (2015)

#184

Post by ratww »

acdha wrote: post #152
ratww wrote: post #123

Earlier quoted context omitted.

Abstraction is good, but it's not a feature specific of OOP, though. From the perspective of Procedural Programming this also works well: brew(coffeemaker) , defrost(oven, "meat", "500g") , accelerate(car) . Same for FP: brewed(grains) , defrosted(meat, time) , withAcceleration(car) .

Nobody was claiming that it was unique - if you reread the thread, I was just pointing out that the dismissal of OOP not fitting the way people thinking about the world wasn’t necessarily approaching it correctly.

No. Your own post your reply doesn't address any of GPs dismissals about OOP, it merely incorrectly attributes the advantages of abstraction itself ("you probably aren’t thinking about how to heat the water") to OOP.

Re: The Repeated Deaths of OOP (2015)

#185

Post by [deleted] »

samsquire wrote: post #149
bccdee wrote: post #125

Earlier quoted context omitted.

Being written in an object-oriented language doesn't make code object-oriented. I could write Java using classes as (namespaces for stateless functions) XOR (structs with no methods), and while it'd still technically all be objects and methods, in practice it wouldn't embody the spirit of OOP at all. It is in keeping with the spirit of OOP to wrap up different entities' data in separate objects and have them interact…

Functions grouped with data is inherently OOP. Even if you don't interact with a graph of objects in a class, you're still using OOP if you define methods on your class and use those methods to interact with fields.

[deleted]

Re: The Repeated Deaths of OOP (2015)

#186

Post by jayd16 »

bccdee wrote: post #181
jayd16 wrote: post #163

Earlier quoted context omitted.

>Exposing all of every entity's data to the world and letting unaligned actors unilaterally mutate many entities' state But that is NOT the pattern. Entities are ids, they have component tags that opt entities into some functionality and the systems encapsulate and track the mutable state that system controls. If you want to start sharing ownership of mutable state, that basically comes down to an implementation deta…

Don't systems sometimes have to access each other's components to do work? Isn't any given component exposed to all systems, and not merely one?

Its a bit of an implementation detail I would say. If you use a single thread and explicitly order your systems then its probably possible to have fully accessible global state.

Unity, for example, encapsulates the actual component data and uses a fairly complex API around command buffers to schedule readonly and read/write commands across many threads.

Re: The Repeated Deaths of OOP (2015)

#187

Post by lolinder »

cout wrote: post #168
lolinder wrote: post #85

Earlier quoted context omitted.

Where do we see prototypal inheritance in nature? I can think of lots of examples of composition, but none of prototypes. The closest I can think of would be DNA, but even that would be better modeled as composition in my mind.

Mitosis is the cellular equivalent of prototypal inheritance; the cell clones itself, and then you have two cells, each a copy of the original. You even get an inheritance hierarchy when pluripotent cells divide and become differentiated; the new cell gains functionality missing from the original as genes are turned on. And yes, there's lots of composition too -- a cell is composed of cytoplasm, organelles, and a mem…

> The mechanism by which the cells are copied does involve DNA, but it and the proteins involved are an implementation detail.

Well, yes, anything inside the cell is, when modeled as an object, an implementation detail. External behavior is all that matters.

What always strikes me funny about prototypal inheritance is that it seems like a special case of composition, one that just happens to do all the necessary delegation for you.

In the case of the cell, I can model mitosis by having the two cells name their parent as the prototype, or I can define in the code that they're composed of the same stuff and delegate method calls the same way. The end result is the same, but composition is more flexible.

In JavaScript, prototypes have less boilerplate, but it's possible to have a language that eliminates most of the boilerplate for delegation as well (see Kotlin's delegation feature [0])

What do I gain by using a prototype instead of composition with delegation?

[0] https://kotlinlang.org/docs/delegation.html

Re: The Repeated Deaths of OOP (2015)

#188

Post by kazoomonger »

cout wrote: post #56
samsquire wrote: post #47

ECS is often implemented in an OOP language. I know of no ECS languages. You have objects that you iterate over and apply changes to the struct or object's fields like x and y coordinates in a game tick for the "next state" Essentially you end up with lots of global functions and very large API space that has no ordering. There's inherent ordering to global function application to produce the correct result. So it pr…

What would an ECS language look like? Would it differ substantially from an OO language? ECS seems to me more like a pattern than a paradigm.

I don't think ECS as such would really make a language on its own, but languages that use traits instead of inheritance would be approximately that. Both ECS and traits eschew using the inheritance-style "is-a" thinking. ECS goes for "has-a" thinking, and traits go for "acts-as" thinking. A few popular trait-based languages that would feel comfortable to someone familiar with ECS are Rust or Go.

Re: The Repeated Deaths of OOP (2015)

#189

Post by ncmncm »

kazinator wrote: post #178
ncmncm wrote: post #175

Earlier quoted context omitted.

C++ was never at any stage a preprocessor. It was, instead, the first of what became many, many compilers that generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator. Nowadays, LLVM IR fills exactly the role C once did, for new languages like Rust and Zig. Zig is just now in the middle of transitioning to its own optimizer and machine-code gener…

> generated C from its AST as the target assembly language, relying then on the C compiler's optimizer and machine-code generator. That qualifies as a preprocessor to me. You can get the sources to it, as late as 3.0.3 from 1994 here. http://www.softwarepreservation.org/projects/c_plus_plus/ind...

If "preprocessor" means anything at all, it means a program that alters incoming text according to textual rules, without analyzing language semantics. The C preprocessor operates strictly on text patterns. Likewise Ratfor. Likewise m4.

Otherwise every compiler is a preprocessor, and the word is meaningless. Making words meaningless could be a way to make yourself feel important, but it does not advance understanding.

Since Cfront, up until LLVM, almost all new-language compilers emitted C code. They were not preprocessors. Compilers that emit LLVM IR are also not preprocessors.

Re: The Repeated Deaths of OOP (2015)

#190

Post by kaba0 »

valenterry wrote: post #173
kaba0 wrote: post #117

Earlier quoted context omitted.

Sorry, it’s my pet peeve, but referential transparency doesn’t mean what many think it does — what you mean is simply side-effect freeness. See the top answer here: https://stackoverflow.com/questions/210835/what-is-referenti...

Why are you so quickly assuming that you know better what I mean than I do? Could you point out a specific point in my answer that is not compatible / or contradcits with the common definition of referential transparency?

I didn’t mean to assume anything, I just wanted to note that the common definition used in FP circles is not correct. So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct — since for example Java is also referentially transparent which I guess you would not consider being a pure FP language. (Exchanging a value with a variable referring to the same value will not change the value denoted by the expression for example neither in Java, but it is not too interesting a property in itself)
Post reply on HN