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

91–100 of 220 posts

Re: The Repeated Deaths of OOP (2015)

#91

Post by mercer »

cout wrote: post #36
ncmncm wrote: post #13

Classes were never definitional for OO, so prototypes, as originated in Self and adopted in JS, are not a violation of it. Function calls and messages are, fundamentally, isomorphic. Messages were never definitional. The notion of "purity", everything is an object, was never definitional. That was a Smalltalk conceit. Alan Kay named the idea, but stole it. So he doesn't get to impose his religion. What is definitiona…

Why do you consider inheritance definitional? Is it definitional by de facto, or is there an authoritative definition that you are using? The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world. But inheritance as adopted by most simula-derived languages does not exist in the real world. What does exist in the real world is prototypal inheritance (spec…

> The reason OO is a powerful organizational too is because it mirrors how many people naturally think about the real world.

I've never found myself thinking that my pan fries an egg. I fry an egg and use the pan and the stove to do it. I've also not found myself thinking that my pan hits an intruder and dents itself. I hit the intruder (well, if I had the courage) and the resulting 'data/object' now has 'dent' as a property.

The idea that my coffee machine is making coffee, or that my combo-oven is making my food is perhaps a bit more palatable, but even then it's now how I think about things. I am the one making coffee, or heating up food, and the actions needed are not inherently part of the object.

IMO, the problem is that people do NOT think about the world in terms of objects, at least not in a way that conforms to what is generally considered OOP. Rather, when we think of 'objects' we generally think of data structures that we then operate on. The idea that there are objects that contain both properties/state and behavior is pretty weird irl.

Re: The Repeated Deaths of OOP (2015)

#92

Post by anonymoushn »

hgs3 wrote: post #69
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…

> I know of no ECS languages. Any language with mixins and reflection can do ECS. e.g. Use mixins (components) and reflection to check which mixins an object (entity) has, then executing a code path (system) based upon that answer. Many dynamic languages, like Ruby, support this combination of features. I think the issue is many game developers work in C++ which lacks them. There is a school of thought that design pa…

ECS is commonly implemented without reflection. What are these implementations missing?

Re: The Repeated Deaths of OOP (2015)

#93

Post by ratww »

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…

ECS can also be implemented in functional or imperative languages, and it often is.

The fact that ECS can be implemented in OOP languages doesn't make it an OOP pattern, only that OOP languages have Turing-completeness. You could also write Pure-FP code or implement Prolog in an OOP language, or vice-versa.

> If you move the global functions to the entity objects themselves, you end up with OOP.

You're probably talking about moving the global functions (also called Systems) into the the Component objects. Entities in ECS are normally just integers to which components are attached to, the global functions you're talking to correspond to

This is possible for the simplest usages of ECS, however this is very limiting. One of the most important aspects of ECS, especially in modern frameworks, is the possibility of Systems (the "global functions") to operate in more than one kind of Component at a time.

For example: a collision detection System might want to operate on both "Position" and "Visibility" Components to avoid performing collision detection on invisible components.

This ability is crucial to ECS for two reasons: to have good separation of concerns, but also for performance.

With your suggestion in OOP, you would have to do that with multiple inheritance, or maybe by picking one Component to host the System and break encapsulation.

Re: The Repeated Deaths of OOP (2015)

#94

Post by bob1029 »

In my experience, OOP works great until you run into a problem domain with circularly-dependent types that actually make sense as such to the business. Certainly, there are ways to manage this within the realm of OOP, but I strongly argue that these solutions are half-assed at best.

Also, nesting of complex types (i.e. making assumptions about the shape of the domain model) also seems to be a large part of what causes pain in larger code bases.

> Most programmers I have met in person tend to divide the world thus:

> Wacky research stuff. Unproven, Scary, Unmaintainable.

For us, the "Wacky research stuff" is how we finally solved many frustrations we had with implementing software against our particular business. A relational/functional hybrid model (implemented using C#8 & SQL) has proven to be far superior to any other approach we have taken over the last 6 years. But, we still do OOP in other places where it still makes sense to do so.

Re: The Repeated Deaths of OOP (2015)

#95

Post by slver »

ehnto wrote: post #24
dragonwriter wrote: post #18

Earlier quoted context omitted.

> I've never seen MVC used in anything but single-run applications that end with an discrete output. MVCs original use was GUIs, which are not “single run applications with a discrete output”, but instead “software with a perpetual state and loop”. Yes, its since been adapted to web use, which usually fits that single-run description, but still...

That's interesting, I knew it was a pattern older than it's use in the web but hadn't given it much thought. There's certainly nothing inherent in either design that limits them to either use case.

Keep in mind the "web" use of MVC originates with Ruby on Rails. Which actually significantly misunderstood what MVC is...

Re: The Repeated Deaths of OOP (2015)

#96

Post by Zababa »

valenterry wrote: post #58
Rochus wrote: post #10

Earlier quoted context omitted.

> "functional programming" which in comparison has a glas clear definition Does it?

Yes, please see my other answer - it is much stricter/clearer defined than any OOP definition that I've seen.

If I understood you correctly, you say that functional programming is what people usually call "pure fonctional programming"? If that's the case, the definition is better than OOP, but I don't think it's a property of functional programming but just that OOP is talked about more by more diverse people.

Re: The Repeated Deaths of OOP (2015)

#97

Post by ratww »

galangalalgol wrote: post #64
cout wrote: post #56

Earlier quoted context omitted.

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.

And that pattern is easy to implement in C or fortran 77 without being unidiomatic. So I don't vthing you need anything special. Edit: to clarify, a system can just be a function, an entity just an ID and a component should be plain old data anyway, so a struct is perfect.

> a system can just be a function, an entity just an ID and a component should be plain old data anyway, so a struct is perfect.

Correct. This is exactly how most ECS frameworks are implemented today (except when it's implemented in languages that doesn't have those features, of course).

Re: The Repeated Deaths of OOP (2015)

#98

Post by dkarl »

> The question is, how do you add those components together? One solution is to use mixins. This gives us some flexibility back, but we can go even further. See, mixins still tie the data of the component to the code that processes it. But when you think of it, some data, like the position of an object, can be useful for several systems (rendering, collision detection, AI…).

Typeclasses allow you to treat your entities as objects with behavior, while at the same time separating concerns in your codebase. The behavior is defined wherever makes sense according to the separation of concerns and then "added" to the bare entity object where it is needed.

You don't really even need typeclasses to achieve this behavior. It's just the adapter pattern.

You might not get the absolute best efficiency this way, but it's not a fatal blow to combining ECS style and OO style.

Re: The Repeated Deaths of OOP (2015)

#99

Post by dkarl »

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…

I agree. I think the author leans too much on the supposed incompatibility of OO style and ECS style, which they explain only by linking to the Wikipedia page for object-relational impedance mismatch. I've worked in many systems that satisfy the author's description of ECS in their treatment of the central domain objects, and they were all built in OO languages and were thoroughly OO in the rest of the codebase.

I think the author was on the right track in recognizing OO as "a set of mechanics we can cherry pick," but I really don't follow how they think an embrace of ECS style would force programmers to abandon most or all OO mechanics.

Re: The Repeated Deaths of OOP (2015)

#100

Post by ratww »

rualca wrote: post #61
Hermel wrote: post #16

Earlier quoted context omitted.

The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program.

> The essence of OOP is not inheritance, that’s a nice to have. The essence of OOP is to encapsulate the data and the functions that operate on that data into an object and hide the internal state of the object from the rest of the program. What is inheritance but a way to encapsulate data and methods in a way where you only need to override a subset of very specific methods and/or data to specialize an implementatio…

Inheritance is a bit more complicated than that.

Your definition is closer to what the Template Method pattern [1] is, rather than inheritance in general.

Keep in mind also that neither inheritance itself nor the Template Method pattern guarantee encapsulation.

[1] https://en.wikipedia.org/wiki/Template_method_pattern

Post reply on HN