It is said that organizing data a certain way in a computer program will improve performance and reliability. This is what I learned reading the entire website dataorienteddesign.com written by Richard Fabian. You will find numerous advanced concepts discussed on the website including substantive critiques of object-oriented programming; a different view on design patterns; generative and transformative approaches and litany of thoughts on the design of programs that run faster but are more adaptable.
Most programmers who are familiar with data structures, assembly language, and computer architecture know about aligning data design in such a way to gain greater performance. Data oriented design applies that perspective more broadly. Instead of optimizing a small part of a module or deciding to use smaller primitive data types more appropriately, the data oriented approach implies structuring programs to achieve contiguous data processing from the start of the program to the end.
I think the reality is data oriented design is the adaptation of relational database design to computer programs. Make the code work like tables, columns, and rows in which case you gain higher cache locality. The performance is great but the obviousness of the code may seem less appealing than the comfortable taxonomic feel of class/object based designs. Aim for the natural performance I say but remember you have a higher cognitive burden because you are still in an imperative programming environment rather than using SQL.
What is going to win? Your choices seem to be Generic Programming; Functional Programming; and Object-Oriented Component Programming. Procedural Programming is in the running as well. I did various forms of Object-Oriented Component Programming for 14+ years. Prior to that, it was all procedural programming for me and it was also what I was taught in school. Also consider that procedural programming is alive and well in the C language.
C is used to build highly critical technology such as operating systems, Internet routers, and future defense technology such as seL4 designated for next generation drones. I have an open source copy of seL4, have examined it and see that it is straight up procedure programming. I downloaded because security expert, Bruce Schneier referred an article saying some group mathematically proved that some version of it had no bugs or flaws. I wanted to see an example of perfect code. I was disappointed but still learned alot checking it out.
Object-Oriented Component Programming is hard to get out of once you get your mind into it. Especially for business class application development. More than a handful of cutting edge folks who build high throughput systems swear by some form of Functional Programming albeit disguised as Data Oriented Design or classic OOP paired with heavy reliance on SQL stored procedures. Stream processing is a big thing. Yes, data centric. But will it win?
Nobody knows. It will be decided one person at a time and the aggregate sum of those who lean one way or another. I never expected through my research into native code and native graphics that I would encounter concepts like Generic Programming and Data Oriented Design in such a challenging way as I have seen in the last few months. Those things were not on my radar. I was fully content with OOP. Now, I am thinking that the folks who built the Go language over at Google have the right ideas.
The one thing I can say is that I have learned to detect some likely winners. Not among the bunch I cited here. More generally. The winner will be practical, first and foremost. Few people will twist their way around anything that is too obtuse. If simplicity is at least not intimated, that is grounds enough to see that which is too complex as destined for long-term decline despite any initial surge in uptake. Practical, simple, and meets the cross-cutting goals that correspond to acceptable quality. The best approach I have seen so far is to simply subset whatever language or technology you use. That is what I’ve learned this month, or what I already practiced idiomatically (with negative professional costs though) but now accept without reservation. Downsides do exist, but the upside is worth it. Take the best subset in terms of features, practices, and perspectives and apply them consistently.