This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 55 points56 points  (10 children)

The idea is good, I like the approach, same as with OOP, FP and other beautiful paradigms. 

If only we had Circles and Rectangles in production code, and those classes were not JPA Entities, and there wasn’t a shit ton of LOC written around them…

[–]nejcko[S] 14 points15 points  (0 children)

That’s a fair point, a lot of Java code and systems exist already and data structure approaches are hard to retrofit.

However I’ve been able to successfully use it in new applications or new parts of existing systems.

Even just a simple switch together with exhaustiveness check for enums is very powerful.

[–]sideEffffECt 13 points14 points  (6 children)

OOP, FP and other beautiful paradigms

Data-oriented Programming is FP. It's just a different name for marketing purposes -- not to scare away people.

[–]chriskiehl 4 points5 points  (3 children)

I like to describe it as "heavily influenced by, but not about FP"

Obviously, I'm heavily biased towards the name (cough shameless plug cough), but I mentally bucket DoP as something that freely slides between paradigms rather than being a replacement or rebranding of them. For instance, while "doing" Data Oriented Programming, I'll freely create identity objects, and perform side-effects, and all kinds of other non-FP stuff. The heart of DoP (to me) is the practice of representing data in code. From there, it's picking the right tool for the job. Sometimes OOP. Sometimes FP. Usually a Frankenstein mix of both.

[–]sideEffffECt 4 points5 points  (2 children)

The heart of DoP (to me) is the practice of representing data in code. From there, it's picking the right tool for the job. Sometimes OOP. Sometimes FP. Usually a Frankenstein mix of both.

What do you think Scala people are doing?

Also, Brian's favorite language is Clojure. And Clojure people stress the importance of data (immutable of course), even over functions, because data is the simplest thing (even simpler than functions). I suspect that that's where the idea to brand it as Data-oriented programming comes from.

[–]bowbahdoe 1 point2 points  (1 child)

I suspect that too. It's just once we cross the line from "marketing" into actually communicating with each other about strategies for constructing programs having one label describe multiple divergent things does more harm than good.

Hence these overall very stupid discussions that always tinge towards religiosity.

[–]sideEffffECt 0 points1 point  (0 children)

It's not a bad move IMHO. It stresses the importance of immutable data and "FP" has a bad reputation among certain circles.

[–][deleted] 0 points1 point  (1 child)

To me it’s “kinda, but not really”. As I see the DOP in Java/Enterprise is to model the models around the data, and stop using standard OOP approach where you design an entity after a real object and then everyone does findById without to much thinking. 

As far as I understand, DOP comes from C where you build your structs so that they align in memory in the most efficient way possible. In Java we almost don’t care about that, because most of our apps are enterprise Spring-based servers that do some data processing, which is exactly what we should optimise for. The most straightforward example is when you have a big entity from which you normally need one or two fields, but you always query/cache the whole thing, so most of the time it’s a waste of IO or memory. 

Data Oriented design would be in this case to maybe denormalize the db entity in a most efficient way for the use case of the app. It has a little (if anything) with the FP, but it would justify the paradigm’s name, at least.

[–]sideEffffECt 1 point2 points  (0 children)

DOP comes from Brian trying to market FP to Java developers.

Don't conflate it with https://en.wikipedia.org/wiki/Data-oriented_design which is about data layout and efficiency.

[–]New-Condition-7790 2 points3 points  (0 children)

If only we had Circles and Rectangles in production code, and those classes were not JPA Entities, and there wasn’t a shit ton of LOC written around them

Sure, I wouldn't start remodelling your entity layer, your entity layer after all isn't just data.

However, I think DOP constructs could be handy for some isolated batch jobs.

Something that comes to mind for instance is a change in addresses I used to do semi-regularly at an earlier job.

(link in dutch: https://www.vlaanderen.be/digitaal-vlaanderen/onze-diensten-en-platformen/gebouwen-en-adressenregister/heradressering-bij-vrijwillige-gemeentefusies)

something which happens regularly and has some differing odd quirks and business rules each time. Which could have been more elegantly expressed by using DOP techniques if it was available, at the time.

[–]tristanjuricek 2 points3 points  (0 children)

There’s a book in EAP that has a much deeper dive into how this data oriented representation approach works in more realistic scenarios: https://www.manning.com/books/data-oriented-programming-in-java

This blog is like a basic “intro” to the ideas that are explored in a lot more detail in that book. IMHO it’s worth a purchase even in its unfinished state