The main difference between Data-Oriented programming and Functional Programming is about how we represent data inside a program. What are the pros and cons of each approach?
In both DOP and FP data is immutable.
In FP, we tend to represent data with specific types while in DOP we represent data with generic data structures (e.g. maps and lists)
Data-oriented programming is about representing data with immutable generic data structures (e.g. maps and lists) and manipulating data with general purpose functions
That's no definition of DO I've ever heard. A list is a classic example of a non-data oriented structure!
DO as I understand it is about recognizing how data is actually laid out and interacted with by a processor, as opposed to meaningful abstract relationships to a programmer. It's about breaking down costly abstractions, rather than ignoring the cost of higher level abstractions.
DO exists primarily in opposition to OO, not FP. The classic example is the array of structs to struct of arrays (OO to DO transformation).
I didn't choose the term "Data-Oriented programming"
It was used by Cognitect folks to promote clojure [1] and actually it was coined by Eugene Kutznetsov in 2004 [2]
As you know, naming is one of the two hard things in programming.
He's defined that elsewhere in a book he just wrote for Manning. What is mildly annoying is that he is not really asking HN for advice here. He is pimping his book.
Wouldn't it be more honest to actually put that in your message and make it a "Show HN"? "I have a book on DoD and am looking for critical feedback from FP experts".
p.s. given that I strongly disagree with your definitions of DO and FP.
DOD/P: Data oriented design and programming is structuring code in light of form, size, access patterns of data. Efficient access and ops on domain specific data is the name of the game. Strictly speaking, this is an optimization approach and not a genuine general programming paradigm. In sum: organize your data layout to maximize efficient processing suited to your application. (DB analog: 1st normal form is DoD. 5th normal form is anti-DOD.)
FP: true to its mathematical origins, FP is mainly about transformation of data via a methematical treatment. Arguably, algorithms are far more central to FP than data. A significant manifestation of this fact is the existence of "lazy" and "strict" evaluation in FP runtimes which flies in the face of the primary concerns of Data Oriented Programming (which came from gaming). FP in no way addresses memory layout as a primary concern. FP is a conceptual general purpose paradigm.
I feel you're making a distinction that some people decided to make, but that is not really widely shared by others to warrant imposing it.
I see you also posted two differently-titled links to your "Data Oriented Programming" book last month. That does make it feel a bit like you're submarining your book with an 'Ask HN'.
My apologies if I sound negative. On a more positive note: perhaps write a good blog post about this, and perhaps the core of what your book is about? I imagine that would be much more appreciated than just a low effort link to the book or "Ask HN".
You should probably be less into philosophy and categorizing and more into building shit. Go watch some Feynman and then try to get something to work on the gpu
The specific structure can be part, but the difference is exactly as is on the name.
Niklaus Wirth say:
Algorithms + Data Structures = Programs
Most paradigms pay a bigger attention to the "Algorithms" side. And data is a distant second class citizen.
"Functional Programming" is about functions. All discussions are centerer in the algorithms related to it.
"Object oriented" is about objects. All discussions are centerer in the algorithms related to it.
But this is distracting:
Show me your flowcharts, and conceal your tables, and I shall continue to be mystified; show me your tables and I won’t usually need your flowcharts: they’ll be obvious.
Fred Brooks
That is why a lot of people get drown in abstractions, instead of solve what the problem is.
---
Now, if we instead make data the driver of the decisions a lot of things can be simplified. A common example is when we ditch "abstracting-away" ORMs and just use SQL (that is data oriented), because hide/not use at full what a RDBMS is moronic.
----
But both are part of the same coin. So if data become truly important, WHICH algorithms fit it better?
This is where become easier to work on data with structural comparisons, immutability, etc. Is in fact a relational way of think, just with other names and probably a small part of it.
---
Now the answer is more like "yes" because focus in how represent data is actually big part of the deal, but that still can make some to get carry away by the algorithms of it, like get too focused in make use of persistent structures instead of exactly think on HOW to represent the data that allow the best way to manipulate it.
In the Clojure culture it tends to be seen as virtuous and desiereable when instead of writing out logic that implements rules or state tracking, you work with the rules and state as plain data in nested data structures of maps, vectors, sets, keywords used as symbols, etc.
Things like http routing, schemas of data (malli / spec), having an in-memory "app-db" storing all state for a CloureScript web frontend, etc. You can then employ universal and powerful data traversal/validation/manipulation tools in Clojure to these data structures.
26 comments
[ 5.7 ms ] story [ 65.2 ms ] threadThe main difference between DOP and FP is that in DOP we use generic data structures to represent data (e.g. maps and lists)
DO as I understand it is about recognizing how data is actually laid out and interacted with by a processor, as opposed to meaningful abstract relationships to a programmer. It's about breaking down costly abstractions, rather than ignoring the cost of higher level abstractions.
DO exists primarily in opposition to OO, not FP. The classic example is the array of structs to struct of arrays (OO to DO transformation).
https://blog.klipse.tech/visualization/2021/02/16/data-relat...
As you know, naming is one of the two hard things in programming.
[1]: https://www.cognitect.com/blog/2016/6/28/the-new-normal-data... [2]: https://adtmag.com/articles/2004/08/05/data-integration-a-li...
> Data-oriented design => Increase performance via Data layout
> Data-driven programming => Increase clarity via Behaviour described by data
> Data-oriented programming => via Reduce complexity via Data representation
p.s. given that I strongly disagree with your definitions of DO and FP.
DOD/P: Data oriented design and programming is structuring code in light of form, size, access patterns of data. Efficient access and ops on domain specific data is the name of the game. Strictly speaking, this is an optimization approach and not a genuine general programming paradigm. In sum: organize your data layout to maximize efficient processing suited to your application. (DB analog: 1st normal form is DoD. 5th normal form is anti-DOD.)
FP: true to its mathematical origins, FP is mainly about transformation of data via a methematical treatment. Arguably, algorithms are far more central to FP than data. A significant manifestation of this fact is the existence of "lazy" and "strict" evaluation in FP runtimes which flies in the face of the primary concerns of Data Oriented Programming (which came from gaming). FP in no way addresses memory layout as a primary concern. FP is a conceptual general purpose paradigm.
I see you also posted two differently-titled links to your "Data Oriented Programming" book last month. That does make it feel a bit like you're submarining your book with an 'Ask HN'.
My apologies if I sound negative. On a more positive note: perhaps write a good blog post about this, and perhaps the core of what your book is about? I imagine that would be much more appreciated than just a low effort link to the book or "Ask HN".
I need this written on a huge poster behind my desk
The specific structure can be part, but the difference is exactly as is on the name.
Niklaus Wirth say:
Most paradigms pay a bigger attention to the "Algorithms" side. And data is a distant second class citizen."Functional Programming" is about functions. All discussions are centerer in the algorithms related to it.
"Object oriented" is about objects. All discussions are centerer in the algorithms related to it.
But this is distracting:
Fred BrooksThat is why a lot of people get drown in abstractions, instead of solve what the problem is.
---
Now, if we instead make data the driver of the decisions a lot of things can be simplified. A common example is when we ditch "abstracting-away" ORMs and just use SQL (that is data oriented), because hide/not use at full what a RDBMS is moronic.
----
But both are part of the same coin. So if data become truly important, WHICH algorithms fit it better?
This is where become easier to work on data with structural comparisons, immutability, etc. Is in fact a relational way of think, just with other names and probably a small part of it.
---
Now the answer is more like "yes" because focus in how represent data is actually big part of the deal, but that still can make some to get carry away by the algorithms of it, like get too focused in make use of persistent structures instead of exactly think on HOW to represent the data that allow the best way to manipulate it.
Also Clojure not emphasizing the power of types… but types emphasize programming with data awareness.
Things like http routing, schemas of data (malli / spec), having an in-memory "app-db" storing all state for a CloureScript web frontend, etc. You can then employ universal and powerful data traversal/validation/manipulation tools in Clojure to these data structures.
Also array Langs like kdb+?