back
2 comments
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)

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.