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

171–180 of 193 posts

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

#171

Post by pjmlp »

sirwhinesalot wrote: post #170
pjmlp wrote: post #168

Earlier quoted context omitted.

People without CS background say a lot, like confusing ECS with data oriented design.

I have a PhD in computer science and I'm also able to stop for two seconds and understand what ECS as used by game devs means. It is pointed out in the talk that the design pattern was used in sketchpad of all things and reinvented in 1998. They call that pattern ECS. It is unfortunate the name is overloaded but that doesn't mean that when they say ECS they're referring to the ECS you are and it is somehow a gotcha s…

Then lets sort this out, point an github repo of your choice for a game engine using ECS and lets discuss the implementation from CS point of view regardling programming language features used for the implementation.

Given that both of us have the required CS background should be kind of entertaining.

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

#172

Post by ahonhn »

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…

This mention of verbs reminds me of Steve Yegge's blog post "Execution in the Kingdom of Nouns" from 2006.

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...

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

#173

Post by phlakaton »

morkalork wrote: post #152
robertlagrant wrote: post #104

Earlier quoted context omitted.

> Suddenly clicked for me why some people/languages prefer doThing(X, Y) vs. X.doThing(Y) It's when you start writing ThingDoer.doThing(X, Y) that you begin questioning things.

But if you make it thingService.doThing(x,y) you're all good.

In Go, of course, thingService would implement the interface Thinger.

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

#174

Post by sirwhinesalot »

pjmlp wrote: post #171
sirwhinesalot wrote: post #170

Earlier quoted context omitted.

I have a PhD in computer science and I'm also able to stop for two seconds and understand what ECS as used by game devs means. It is pointed out in the talk that the design pattern was used in sketchpad of all things and reinvented in 1998. They call that pattern ECS. It is unfortunate the name is overloaded but that doesn't mean that when they say ECS they're referring to the ECS you are and it is somehow a gotcha s…

Then lets sort this out, point an github repo of your choice for a game engine using ECS and lets discuss the implementation from CS point of view regardling programming language features used for the implementation. Given that both of us have the required CS background should be kind of entertaining.

Sure, the Bevy engine is the one I'm most familiar with:

- An entity is a 64 bit integer wrapped in a struct for typesafety (newtype pattern). This is a primary key.

- A component is a struct that implements the "component" trait. This trait is an implementation detail to support the infrastructure and is not meant to be implemented by the programmer (there is a derive macro). It turns the struct into a SoA variant, registers it into the world object (the "database") plus a bunch of other things. It is a table.

- A query is exactly what it sounds like. You do joins on the components and can filter them and such.

- A system is just code that does a query and does something with the result. It's basically a stored procedure.

It is a relational database.

EDIT: forgot to link the relevant docs: https://docs.rs/bevy/latest/bevy/ecs/component/trait.Compone.... It is really critical to note a programmer is not expected to implement the methods in this trait. Programmers are only supposed to mark their structs with the derive macro that fills in the implementation. The trait is used purely at compile time (like a c++ template).

There's also flecs which doesn't rely on OOP-ish traits in its implementation: https://www.flecs.dev/flecs/

Either way, it doesn't matter if OOP is used in the implementation of an ECS, just as it doesn't matter if MySQL uses classes and objects to implement SQL.

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

#175

Post by virgilp »

pjmlp wrote: post #128
virgilp wrote: post #116

Earlier quoted context omitted.

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.

> Since when do OOP languages have to be single paradigm?

What I really meant to say with that was that it's lisp at its core -i.e. if one wants to place it squarely in one single paradigm, imo that one should be "Functional".

I was just surprised to see it listed as an example of OOP language, because it's not the most representative one at that.

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

#176

Post by igouy »

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

> "OO is not bad when there is an actual entity - i.e. a stream, a socket, a window, etc to which an object corresponds, or in a simulation of actual entities. That's where it was born and where it shines. … For instance, don't customers buy products? Which should own the functions that involve both?"

What is the purpose of the customers / products app?

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

#177

Post by constantcrying »

igouy wrote: post #150
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…

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

I encourage you to listen to the talk, because it gives a very specific reason why historically that thinking about OOP was so common. Notably it was Stroustrups motivation, to allow exactly that kind of thinking to be implemented in C, which became C++. Simula was developed to allow this structuring.

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

A great line. I just wished it wasn't out shone by all the lectures, tutorials, books which explain OOP by saying "a Labrador is a dog is an animal" and then tell you how this abstraction is exactly what you should be doing.

OOP revisionism is always very surprising, because the only people aware of it are OOP revisionists, the vast majority of developers are completely unaware of it.

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

#178

Post by [deleted] »

sirwhinesalot wrote: post #174
pjmlp wrote: post #171

Earlier quoted context omitted.

Then lets sort this out, point an github repo of your choice for a game engine using ECS and lets discuss the implementation from CS point of view regardling programming language features used for the implementation. Given that both of us have the required CS background should be kind of entertaining.

Sure, the Bevy engine is the one I'm most familiar with: - An entity is a 64 bit integer wrapped in a struct for typesafety (newtype pattern). This is a primary key. - A component is a struct that implements the "component" trait. This trait is an implementation detail to support the infrastructure and is not meant to be implemented by the programmer (there is a derive macro). It turns the struct into a SoA variant,…

[deleted]

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

#179

Post by olvy0 »

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)

C# does support a form of multiple dispatch, through the dynamic keyword. Used it myself for writing a parser.

https://shawnhargreaves.com/blog/visitor-and-multiple-dispat...

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

#180

Post by igouy »

masfoobar wrote: post #115
cloogshicer wrote: post #38

Can someone point to a real life example or tutorial/guide of the ECS architecture he proposes? I'd like to learn more about how to implement this.

While people are likely to hand useful links or videos, I will attempt another method of understanding. When it comes to organising your code in an ECS-esque fashion, it is much closer to normalising a database except you are organising your structs instead of tables. With databases, you create tables. You would have an Entity table that stores a unique Id, and tables that represent each Component.. which there would…

So global functions to configure functionality defaults and the functionality may be reconfigured later.
Post reply on HN