I'm curious how you would do data oriented programming in a language with no type system and no control over memory layout. And I guess the answer is "you can't, but JITs might exist someday that do it for you"
But you can't wave your hands around and say compiler optimizations will fix performance problems - they can, but they're not magic, and the arrow in the proverbial knee for optimization passes are language semantics that make them impossible to realize (forcing the authors to either abandon the passes, or rely on things like dynamic deoptimization which is not free).
Unfortunately, the terms "data-oriented design" and "data-oriented programming" refer to two different styles of programming. Data-oriented design is the approach to programming made popular by Mike Acton's CppCon keynote—as you say, it focuses on the layout of objects in memory to make the processing of data take advantage of the underlying hardware.
Data-oriented programming is a style of programming that, as far as I know, originates in the Clojure community. It emphasizes using general data structures (vectors, dictionaries) to store all data and make code more re-usable. It has nothing to do with good cache utilization, pre-fetching, or avoiding branch mispredictions.
It's a shame that two styles of programming which are almost diametrical opposites share such similar names.
From the look of the article, it's discussing data-oriented design, but in Python, and I agree that it's kind of a weird match.
There is no book on data oriented design as far as I know. It would be great if someone could take Mike Actons talk and similar talks and condense the ideas into a book filled with real world examples.
By using only coding patterns that are known to JIT well and lower level primitive types and containers if provided by the language. Maximizing the use of packages written in native code also helps.
The resulting code is even more annoying to write than using a lower level language typed language in the first place, but ecosystem access sometimes makes up for it.
Hopefully tools like mypyc get better, letting well-typed python code with reasonable usage patterns be compiled to reasonably efficient native code.
Last time I used it I was pleased with the performance benefits but it couldn't even compile all files in a module to a single shared library, despite this being mentioned as possible (and recommended) in the docs. Maybe I was doing something wrong, but they don't answer their github issues often, alas.
Any little thing helps though, it's one thing for throwaway scripts to be inefficient, but applications? At a large scale it is a monstrous waste of time and literal energy.
I'm not sure what either you or the parent consider a proper type system, but the difference between Python and (say) Java's type system is night and day.
If you using the Typing module you might be able to get a linter to check things for you, but that's a far cry from what other typed languages have.
Those are basically contradiction of terms. Orienting the program structure around the data necessarily requires control over memory layout and how it is interpretted.
But you can't wave your hands around and say compiler optimizations will fix performance problems - they can, but they're not magic, and the arrow in the proverbial knee for optimization passes are language semantics that make them impossible to realize (forcing the authors to either abandon the passes, or rely on things like dynamic deoptimization which is not free).