HN Theater @HNTheaterMonth

There's been a few talks: CppCon 2014: Mike Acton "Data-Oriented Design and C++": https://www.youtube.com/watch?v=rX0ItVEVjHc

CppCon 2018: Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”: https://www.youtube.com/watch?v=yy8jQgmhbAU

Building a Data-Oriented Future - Mike Acton [2019]: https://www.youtube.com/watch?v=u8B3j8rqYMw

And a blog/book has been created: https://www.dataorienteddesign.com/

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 -- https://github.com/facebook/yoga/tree/master/yoga) 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: https://youtu.be/yy8jQgmhbAU?t=620

Some UI rendering engines for games do something like this, eg. https://coherent-labs.com -- talk by one of the devs of that at https://www.youtube.com/watch?v=yy8jQgmhbAU

Static typings + type inference

Parse, don't validate https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

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 https://youtu.be/yy8jQgmhbAU In non bare-metal languages, this will be useful for readability

For errors, return instead of throw

⬐ j88439h84

> in-app event sourcing

What's the difference between in-app and not?

⬐ valand

Event sourcing is already widely used as app to app communication. But few realize that it is plausible to take that paradigm and use it for module to module communication in-app.

That line serves as reminder to utilize that, not to exclude non in-app event sourcing

⬐ jlokier

I'd love to see a good example of in-app module-to-module event sourcing.

By module to module, do you mean between very loosely decoupled systems such as microservices, or closely associated things like queues and method calls in a single-process process?

⬐ valand

Both in-process, inter-process, and inter-machine. The event sourcing technique really helps decouple components, reduce the need for higher order state.

I work with TypeScript on daily basis and I'm in the middle of building this library to help with event sourcing and other stuffs. https://github.com/Kelerchian/florcky

I'll be working with rust, C++, and C# in a few weeks due to professional demand and I might get somewhere with event-sourcing using those language.

In the long run we might be utilizing wasm and ffi to introduce universal protocol for event sourcing.

⬐ charlieflowers

Thanks for that "Parse, don't validate" link. It definitely is the clearest explanation for type driven development I've found.

Turns out, years ago I was writing some C# code and I found myself wanting to explore something like that. However, it wasn't idiomatic for C# (especially at the time), and I talked myself out of it.

Since then, I've wondered if that's what people mean by type driven development. It's cool to see that is at least in the general ballpark.

⬐ valand

Is C# nowadays friendly enough for type driven development?

Using TypeScript daily, I have a great time with type driven development. (C# and TS was created by the same guy)

I was never comfortable with Java community approach of automating stuff, with their heavy use of reflections, method name parsing instead of being strict in typings, use generics, macro, templating, etc.

⬐ charlieflowers

Well, you can "force" some of it ... make an object whose ctor can only succeed if a certain check passes, for example.

You'd be using types in a way that pretty much no one in C# does (not idiomatic), except for maybe those who are explicitly trying to go for type driven development (for example, people doing things like railway oriented programming).

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 https://blog.golang.org/go-fmt-your-code, https://github.com/microsoft/TypeScript/wiki/Coding-guidelin..., https://twitter.com/dan_abramov, 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 standards. You must always exercise to always improve your team, whether your team agrees or not AT THAT TIME. Keep searching for improvements, internally and externally. Occasionally fight with your team if you have to, if you have the right cause. And if it turned to be a wrong cause, accept and move on.

So...

> Are there any good ideas to improve one's coding/design skills significantly?

Yes. These are the tricks to a good code/software/system design and architecture:

1. Know the fundamentals! Go lower than frameworks and libraries! Analyze why existing codes are made that way! Think in strings, C, algorithm, data structure! Always pay attention top-down and bottom-up! Think in terms of time and space complexity! Separate complexity from complications! Be thorough.

2. Know the team! Know what is valuable for the team! Understand how your code impacts your team's velocity! Understand the mood of the team and use it! Contemplate how existing processes help or hinder the team! Consider suggesting to add or remove them if necessary! Make interfaces for others! Learn from the team! Cooperate with your team so that you guys can reach higher! Be critical to your team, conflicts can make you stronger! Be humble.

3. All that glitters is not gold. Some very popular libraries and tools that might not be as good as you think. Learn harder. Make something better if necessary. Think of both the big picture and the details at every step you make. Don't overweigh technicality over business requirement, and vice versa. Be critical.

> Now I'm a little worried that if my situation doesn't change, my career would suffer.

Be strong. Feel strong. But stay thorough, humble, and critical. And you need to care achieve them.

I've been there, laying afraid that my career might suffer. I've been in the reviewer's spot too, being too strict, forcing engineers to change the design, sometimes compromising the engineer's personal feeling.

BUT I've also successfully convinced and lead a rewrite the core of a pretty big project (which people are really afraid of the risk) so that the engineers feel safer when building on top of the core, and in turn make them tens times faster, while at the same time growing some newer engineers to the point of one of them being a lead of a team handling a pretty big project for a customer which is pretty prominent in the gaming industry, IN JUST HALF A YEAR. (sorry, but not sorry for bragging lol :D)

You never know what good things are coming to you when you start caring.

Some random nice stuff to learn that I remember might help you with the design stuff:

https://martinfowler.com/

https://medium.com/@thisdotmedia/the-cost-of-premature-abstr...

https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....

https://www.youtube.com/watch?v=yy8jQgmhbAU

https://blog.dropbox.com/topics/work-culture/kim-scott-inter...

Just adding a more recent video on it from CppCon 2018 where the presenter goes over a specific worked example.

https://www.youtube.com/watch?v=yy8jQgmhbAU

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): https://www.youtube.com/watch?v=rX0ItVEVjHc

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): https://www.youtube.com/watch?v=p65Yt20pw0g

Stoyan Nikolov “OOP Is Dead, Long Live Data-oriented Design”: https://www.youtube.com/watch?v=yy8jQgmhbAU

Overwatch Gameplay Architecture and Netcode (More specifically about ECS): https://www.youtube.com/watch?v=W3aieHjyNvw

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 make it easier to centralize a bug early.

There's obviously pros and cons, but I don't think you should discount the possibility of it being a good idea just because it questions ideas that seem standard.

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.

https://www.youtube.com/watch?v=QM1iUe6IofM https://www.youtube.com/watch?v=yy8jQgmhbAU https://www.youtube.com/watch?v=rX0ItVEVjHc

⬐ danmaz74

Data oriented design makes sense in video games where perfomance Is very important, but in most business applications having good abstractions which are flexible and easily maintainable is much more important than optimising for cache usage.

⬐ atoav

I tend to disagree — although I thought the same one or two years ago. Data oriented design doesn’t automatically mean you have to sacrifice useful abstractions on the altar of performance. You’ll have to find different abstractions and ways of composing them together to get a maintainable, flexible result.

In fact I find good data driven designs easier to maintain than good OOP ones..

⬐ eska

I keep hearing this from OOP proponents, but I just don't find it to be true in my experience. Programs written with DOD in mind have very clear data flow and only pass on and use data that is relevant. Programs written with OOP in mind primarily care about some notion of beautiful code and abstractions, which I find to be highly subjective. As a result they generally have very muddy data flow where e.g. unrelated data is passed around that isn't even required to implement a feature. This creates all kinds of poor modularization, dependency hell, huge monoliths, difficult testing (mocking, fakes, etc...), among many other problems. Whenever I have had to rewrite large parts of a program, I have always found it to be easier to do this in a DOD program rather than an OOP program. The biggest reason why DOD is used in video game programming to begin with is flexibility in mixing and matching functionality of game objects (entity-component-systems etc).

⬐ crimsonalucard

It is not muddy or subjective. OOP as described by JAVA is categorically less modular than functional programming. You feel it is worse subjectively because it is worse definitively, you just haven't grasped why yet.

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:

https://www.youtube.com/watch?v=yy8jQgmhbAU

⬐ idsout

Another great talk on data-oriented design, given by Mike Acton at cppcon 2014 https://www.youtube.com/watch?v=rX0ItVEVjHc

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

https://youtu.be/yy8jQgmhbAU?list=WL&t=2553

⬐ leowoo91

Functional programming is always been my passion since my Lisp days. OOP itself promotes mutation thus falls ineffective for overall statement of the computation trying to be achieved.

Alright, I made the comment above to get bit attention because post about this subject before (which has fn paradigm top comment), and this video is mostly about game programming, not about patterns in general.

In game programming, mutation is inevitable because performance is vital. Whoever persuade game engine design, likely to start with OOP, then contaminate game logic with same because devs don't go extra step to have DoD like pattern for entities. You can see few popular engines holding back, notably UE4.

While it is not perfect, pretty sure companies figured out their ways out of complexity with their fiat paradigms and delivered on time. Still, components such as UI/Audio manager has been done a lot easier using OOP.

My point is, OOP is not dead; it just doesn't have to be silver bullet for every situation. In that case, dense environments such as game entities under load. Sounds better if we could just embrace combining patterns as necessary.

TL;DR; I think title of presentation is misleading, and evaluates OOP in specific use case which it falls short (game entities/systems)

⬐ repsilat

Talk about the title isn't terribly productive. I think the link to FP is on the money, though.

A lot of code is easier to read and reason about as a pipeline (or DAG) of data transformations, usually as top-level functions on "raw" (and often immutable) data.

In Python it's often easiest to use a single-purpose namedtuple or some arrays and dicts rather than special classes. In JS "objects" are most commonly just hash tables used as structs to group related data together. And when I say "related", I mean "related by use", not "related by some taxonomy."

Redux/reselect is built on a similar model, too. Often the what the speaker calls "existence-based predication" is also employed by selecting "just active animations" so the consumer doesn't have to branch. Again, usually not for performance reasons, just softeng/maintainability stuff.

I still write classes with constructors and methods and private state etc, and sometimes still use inheritance and "virtual" functions, but not nearly as often as I did when I graduated from uni. That weight is just not always necessary, and it's not often the "right language" with which to express what I want to do.