
OOP Is Dead, Long Live Data-Oriented Design [video] - ibobev
https://www.youtube.com/watch?v=yy8jQgmhbAU
======
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.

