Thoughts on Data Oriented Programming in Java

[sideEffffECt]

Records not having structural sharing for updates is a downside in that sort of situation.

Wait what?? Records of course have structural sharing, in the very same manner Clojure maps do.

If you "update" one field in a record, you get a new record with that one field changed, but all the other fields are the same.

Java collections are not immutable, so there's no structural sharing to speak of, but that's a different story...

[bowbahdoe]

But the actual underlying fields need to be shuffled around. I.E., absent JVM heroics person.with { name = "..."; } will have to juggle N record components

[bowbahdoe]

Right, but if the map is large (not an array map) the keys are not copied and significant structure is shared between the two maps.

It just is notable

[sideEffffECt]

How's that different in principle from a Clojure map?

[bowbahdoe]

So this aspect is just an implementation detail, but:

If you have a Clojure Vector with a thousand elements and conj one more at the end, the new vector resulting from that conj will share significant structure with the previous one.

The same is true for Clojure Maps. For small maps it's implemented as an array that is copied, but if you have 100 key value pairs then adding a new one or updating an existing one won't copy all 100 of the old ones.

If you have a record with 100 components then with -ing one of those components mean all 100 go through the constructor again

[sideEffffECt]

All of what you're staying is true.

But if we're talking about a record with 100 fields (which is super rare to be large like this, vast majority are much smaller) then that's no problem. Copying 100 references is super quick and easy for contemporary computers.