Richard Fabian's Data-Oriented Design goes into great detail to show how OO-style C++ completely negates the performance enhancing features of modern CPUs.
The most amazing achievement of the computer software industry is its continuing cancellation of the steady and staggering gains made by the computer hardware industry. — Henry Petroski
So as such DOD is about optimizing code to take advantage of modern hardware performance features such as generously sized CPU caches. So it is highly "place-oriented" (rather than "value-oriented") and embraces in-place mutation. It is incredibly important to collocate data that is processed and used together. So to practice DOD you have to have control over memory layout. High level languages don't let you control memory layout - systems languages like Rust do.
From that perspective something like ECSY is nothing but a curiosity because it is written in JavaScript.
Because of these requirements Unity created HPC# (High-Performance C# - a custom language based on a subset of C# with some adaptations from C/C++) for their "Data-Oriented Technology Stack" (DOTS).
PS: While your approach seems to borrow some of the organizational principles from Entities, Components, Systems (ECS) the games industry has already established some semantics around the "Data-Oriented" space for the past 10+ years (and it has been spreading from there) that don't align with your ideals. So it may make sense to shift to a different moniker like "data-centric" (though there the relation to data-centric architecture needs to be carefully considered).
The term data-oriented programming was coined by Eugene Kuznetsov in 2004.
That's fine but a quick google will demonstrate that the "other meaning" has been gaining a lot more momentum in the intervening years and with Unity pushing its Data-Oriented Technology Stack (DOTS) (largely guided by Mike Acton's work) it's that much closer to gaining mainstream acceptance.
However this book's stated objective goes beyond the confines of Clojure:
You’ll learn to write DOP code that can be implemented in languages like JavaScript, Ruby, Python, Clojure and also in traditional OO languages like Java or C#.
i.e. more mainstream — and it's in this arena where the other meaning of DO is already that much further ahead.
Most recently (2021 August) this made an appearance:
Pyret doesn't look anything like Scheme — it deliberately borrows heavily from Python — but Python doesn't have an ingrained practice of "Value-Oriented Programming" (I argue quite the opposite).
So it's at this point that they decided that "Value-Oriented Programming" needed a name and that in the contemporary climate Data Centric made the most sense (leaning a bit into the hype around data science).
Then apparently data-oriented programming has nothing to do with data-oriented design.
Data-Oriented Design came about to address the growing performance gap between CPU caches and conventional memory - Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP), Noel Llopis, 2009.
source
Richard Fabian's Data-Oriented Design goes into great detail to show how OO-style C++ completely negates the performance enhancing features of modern CPUs.
So as such DOD is about optimizing code to take advantage of modern hardware performance features such as generously sized CPU caches. So it is highly "place-oriented" (rather than "value-oriented") and embraces in-place mutation. It is incredibly important to collocate data that is processed and used together. So to practice DOD you have to have control over memory layout. High level languages don't let you control memory layout - systems languages like Rust do.
From that perspective something like ECSY is nothing but a curiosity because it is written in JavaScript.
Because of these requirements Unity created HPC# (High-Performance C# - a custom language based on a subset of C# with some adaptations from C/C++) for their "Data-Oriented Technology Stack" (DOTS).
Data Oriented Design Resources
PS: While your approach seems to borrow some of the organizational principles from Entities, Components, Systems (ECS) the games industry has already established some semantics around the "Data-Oriented" space for the past 10+ years (and it has been spreading from there) that don't align with your ideals. So it may make sense to shift to a different moniker like "data-centric" (though there the relation to data-centric architecture needs to be carefully considered).
The term data-oriented programming was coined by Eugene Kuznetsov in 2004. Here are the two references I found for it:
adtmag.com/articles/2004/08/05/dat... and
community.rti.com/sites/default/fi...
As the idiom says: naming is hard!
That's fine but a quick google will demonstrate that the "other meaning" has been gaining a lot more momentum in the intervening years and with Unity pushing its Data-Oriented Technology Stack (DOTS) (largely guided by Mike Acton's work) it's that much closer to gaining mainstream acceptance.
Now within the Clojure community Data Oriented has been used as a synonym to Rich Hickey's 'value-oriented' — for example the 2014 Joy of Clojure and later in Paul deGrandis's 2017 Speaking Data: Simple, Functional Programming with Clojure.
However this book's stated objective goes beyond the confines of Clojure:
i.e. more mainstream — and it's in this arena where the other meaning of DO is already that much further ahead.
Most recently (2021 August) this made an appearance:
A Data-Centric Introduction to Computing
Their definition:
In the 2004 paper The Structure and Interpretation of the Computer Science Curriculum both Shriram Krishnamurthi and Matthias Felleisen (among others) advocated for a "Value-Oriented Programming"-first computer science education based on their experience with How to Design Programs. They didn't explicitly call it that because it's the defacto style of programming in Scheme.
Eventually though they had to concede that the Scheme-like student languages didn't work for some students. This lead to the development of Pyret.
Pyret doesn't look anything like Scheme — it deliberately borrows heavily from Python — but Python doesn't have an ingrained practice of "Value-Oriented Programming" (I argue quite the opposite).
So it's at this point that they decided that "Value-Oriented Programming" needed a name and that in the contemporary climate Data Centric made the most sense (leaning a bit into the hype around data science).
Naming is definitely hard!