You should add Ask HN to the title, and still I think your question may be better posted at stackoverfow or similar places rather than this forum.

Done

No.

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.

Has this data-centric approach be embraced in programming languages other than Clojure?

How is Clojure data centric in the way people are talking about here? IMO Clojure values immutability in a way which is data agnostic, not data aware.

Also Clojure not emphasizing the power of types… but types emphasize programming with data awareness.

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.

Dependes in how you think about this, SQL is the most prominent.

Also array Langs like kdb+?

I don't think FP has anything to do with how data is represented, it's more related to how we operate on that data.

DOP and FP share common insights about separation between code and data and constraining ourselves to immutable data.

The main difference between DOP and FP is that in DOP we use generic data structures to represent data (e.g. maps and lists)

What do you feel are the differences in how data is represented between the two?

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)

How about trying to define both first? I am not sure what data-oriented means.

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.

My purpose here is not to promote the book but to learn from FP experts what they think about the relevance of DOP approach to FP languages.

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.

Please, don't confuse DoD and DoP

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".

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).

You are referring to Data-Oriented design, while I am referring to Data-Oriented programming

https://blog.klipse.tech/visualization/2021/02/16/data-relat...

Useful:

> 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

Perhaps pick a better name that isn't confusing. In industry what your definition refers to is called "generic programming" if I understand correctly.

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.

[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...

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

> You should probably be less into philosophy and categorizing and more into building shit.

I need this written on a huge poster behind my desk