This was a tough one to get through - mostly because “data oriented programming,” as defined, came off as a total straw man argument. If the answer to the question: “what kind of advantages does this offer over a statically typed approach” comes as “well, it’s just better,” you might be part of a straw man debate!

I also think that Mr. Sharvit entirely misses the point of static typing - not that they’re alone in this. Their example of generative testing (which is actually just mutation testing, but that’s an aside …) is a great example of missing the forest for the trees. I recently refactored the GitHub Action of a friend from Google’s from JavaScript to TypeScript. One of the first things that I found, while importing the proper types and converting the files, was that a hashed set being passed around had an incorrect value in it. The benefit of static typing isn’t binding your schema to your types - if you’re doing that, you’re just imperatively programming and that’s not really object-oriented anyway. The benefit is that there are whole suites of tests that you don’t have to write, because your program cannot even compile if you get something wrong. I don’t need to mutation test the proper usage of that hash set anywhere; it’s enforced for me at compile time.

Let’s take the creation of an API as another example - the deferral of schema creation from compile time to PR review time is an example of shifting right; the exact opposite of what we want. Shifting left, or getting feedback earlier on in the development cycle, isn’t just some industry buzzword - it’s a methodology that prevents us from having to write the kind of code (or, even worse, some sort of markdown checklist present during a review) to validate that something exists when the alternative would be… letting the compiler do that for us without having to write anything at all.

Lastly - there are plenty of great applications out there which conform to the stated principles of data-oriented programming (passing generic iterables, immutable data, schema divorced from types, etc …). So - data oriented programming (as stated) fits within the confines of both functional and OOP paradigms - much like design patterns, it can be a useful device to keep in mind, but I would describe it ultimately as a tool rather than as something scoped larger than that.