CppCon 2018: Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”
CppCon 2018: Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design” on HackerTube: recommended by 3 Hacker News commenters across 3 separate months, 2018–2021.
A CppCon 2018 talk arguing that OOP has failed to deliver on reuse and performance, and presenting data-oriented design for C++ with practical worked examples from real systems.
What HN commenters said
10 Hacker News comments link this video. Each one links back to its thread.
nikki93Aug 2020Recommends
Glad to see some agreement there. I'm interested in building an ECS-based approach for a UI system at some point. The Yoga layout engine (implements flexbox -- [link] ) seems to actually be pretty amenable to just incorporating as a `Layout` or `Flex` component, then you could have components for platform-specific renderings (eg. `iOSTextInput`, `AndroidTextInput`, `DOMTextInput` in wasm, ...) that could read from cross-platform common components (`TextInput`). A core aspect would also be a `Hierarchy` component that just has a parent entity id and a list of child entity ids (that it keeps in sync properly). Then bind things to JS and allow you to code it from React, while still being able to eg. run an animation thread for some specific animations that just queries and reads/writes the `Layout` and `AnimationSpec`s etc. Interesting talk re: data oriented design for a webby animation engine here actually: ▶ this video
in “Unity Software Inc S-1” · View on HN
michael_j_wardDec 2019Recommends
Just adding a more recent video on it from CppCon 2018 where the presenter goes over a specific worked example. ▶ this video
in “Practical Examples in Data Oriented Design” · View on HN
phaedrusOct 2018Recommends
That's a very good point. It might be question of high versus low level. From a video I watched today (the rest of the video is worth watching, too, but the following stand-alone quote is apropos): "Polymorphism and interfaces have to be kept under control. I don't believe that their role is in a very low level system like interpolating a couple of numbers in the animations, but they have their place in high level systems, in client facing APIs. They are amazing if you do a type of plug in and you really need some type of dynamic polymorphism." ▶ this video
in “C++17 constexpr Compile-time Ray Tracer (2017)” · View on HN
jfpardyJun 2021Cites it
There's been a few talks: CppCon 2014: Mike Acton "Data-Oriented Design and C++": [link] CppCon 2018: Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”: ▶ this video Building a Data-Oriented Future - Mike Acton [2019]: [link] And a blog/book has been created: [link]
in “Data-oriented design or why you might shoot yourself in the foot with OOP (2009)” · View on HN
nikki93Aug 2020Cites it
Some UI rendering engines for games do something like this, eg. [link] -- talk by one of the devs of that at ▶ this video
in “Kosmonaut: web browser from scratch in Rust” · View on HN
valandJan 2020Cites it
Static typings + type inference Parse, don't validate [link] All libs/products should be pure functions, with input output documented, making libs/products predictable Use in-app event sourcing to reduce the need for global states states DoD ▶ this video In non bare-metal languages, this will be useful for readability For errors, return instead of throw
in “Ask HN: What change in your programming technique has been most transformative?” · View on HN
Show 4 more comments
valandDec 2019Cites it
Having your PR rejected in a healthy environment means that your PR is radically far from the reviewer's expectation. Having your PR rejected in a toxic environment can mean a lot of things, and a company sought after doesn't mean that it MUST be not toxic. First, you have to make sure if both of YOU and YOU ENVIRONMENT is healthy. If both are healthy, proceed reading. > The challenge here is to deliver good quality code, while maintaining a decent speed of delivery. You made it sound like producing good quality code = slowness. FALSE. Seeming slow, good quality code boosts your team's velocity. BUT keep in mind: "quality" is "the standard of something as measured against other things of a similar kind; the degree of excellence of something". Your team has its standards, either is a derivative of other globally acknowledged standards such as [link] , [link] , [link] , etc, or self-made standards. You go follow them, make them happy! Coding and design skill has a different definition than code quality. It is what punches up to the sky: the overall velocity, the success of the team, the balance of growth and culture retainment of the company, the development experience, the users' thumbs ups, amazements, and "this app is life changing" comments, the number of milestone celebration in All You Can Eat restaurants each years, the number of people rising up from junior to senior each years, etcetera etcetera. Not only you make your team happy with the quality code based on their st
in “Ask HN: How to improve code quality while maintaining decent velocity?” · View on HN
drainyardJul 2019Cites it
There's plenty of good talks and literature on the subject and why it is applicable to game development, but also more generally. This talk by Mike Acton (Formerly Insomniac now Unity): [link] I recommend this talk all the time, since it is the one that got me convinced to look into DoD seriously. Also: More Mike Acton (now at Unity): [link] Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”: ▶ this video Overwatch Gameplay Architecture and Netcode (More specifically about ECS): [link] The main argument is that you work with data so you should care about data. All a program does is take some input, do something with it, and give you an output. If you structure your program around this mindset, a lot of problems become much simpler. Concurrency is one thing that becomes much simpler to reason about now that you understand how your data is managed and moved around. Realisations that most of the time you have multiple of something and very rarely do you have a single thing. So having a lot of small objects of the same type each doing some work within their deep call-stack, rather than running through an array of them and doing the work you need to do. I disagree that encapsulation is a brilliant idea _in general_, because it promotes hiding data, and hiding data is not inherently good. There's obviously cases, where there is internally critical, but since all your state is simply tables of data, your program is just choosing to represent that data in some way, which can mak
in “Data-Oriented Design (2018)” · View on HN
DeathArrowJun 2019Cites it
People are starting to use data oriented design instead of OOP. Data oriented design doesn't hide state, is generally faster and easier to comprehend as it doesn't abstract too much. [link] ▶ this video [link]
in “Classes vs. Data Structures” · View on HN
leni536May 2019Cites it
In the article they mention that most programs are not dominated by arrays but objects. An other cure for that is to use arrays of primitives a lot more: ▶ this video
in “Compress objects, not cache lines: an object-based compressed memory hierarchy” · View on HN