I'm not sure what is meant by "data-oriented programming" (I know what "data-driven" means...) but, yes, "Data-Oriented Design" has a distinct (if somewhat nebulous) meaning which comes from game programmer culture. (And my guess is the difference between it and data-oriented programming is not slight.) Data-Oriented Design is, basically, the name given to the bag of techniques listed on the submitted webpage. I don't know if the term was coined by Mike Acton, but it was popularized by the talk he gave that is linked to on the submitted webpage. (It's an inspiring talk! You should watch it, if you have not, yet.)
As far as I can tell, Data-Oriented Design is a reaction to trauma experienced by game programmers trying to undo damage inflicted by the... inapt... application of OO techniques in game codebases by their (probably well-meaning, but ignorant) peers. (Hence the contrast in the names: OBJECT-Oriented Design -> DATA-Oriented Design.)
The keystone idea seems to be, instead of organizing your program's data as objects in an inheritance hierarchy, figure out which data will be accessed together in tight loops, and pack that data together in arrays. (I.e., prefer structs of arrays to arrays of objects.)
P.S., There's an interaction during the Q&A section of that presentation by Mike Acton which I love: one questioner asks, somewhat incredulously, (and I'm paraphrasing here) "If I were to follow the principles you have laid out in this talk, then, if I ever needed to alter the layout of my data--after having invested (perhaps significant) time already writing my program--I would subsequently be required to rewrite all the code which accesses that data." and Mike Action answers, basically, with a stone-cold "Yes."
As far as I can tell, Data-Oriented Design is a reaction to trauma experienced by game programmers trying to undo damage inflicted by the... inapt... application of OO techniques in game codebases by their (probably well-meaning, but ignorant) peers. (Hence the contrast in the names: OBJECT-Oriented Design -> DATA-Oriented Design.)
The keystone idea seems to be, instead of organizing your program's data as objects in an inheritance hierarchy, figure out which data will be accessed together in tight loops, and pack that data together in arrays. (I.e., prefer structs of arrays to arrays of objects.)
P.S., There's an interaction during the Q&A section of that presentation by Mike Acton which I love: one questioner asks, somewhat incredulously, (and I'm paraphrasing here) "If I were to follow the principles you have laid out in this talk, then, if I ever needed to alter the layout of my data--after having invested (perhaps significant) time already writing my program--I would subsequently be required to rewrite all the code which accesses that data." and Mike Action answers, basically, with a stone-cold "Yes."