Clojurians Log v2

I just published an article about how to apply DOP in Java. So far it is not well received by java folks https://www.reddit.com/r/java/comments/ly8w5a/dataoriented_programming_in_java/

Such techniques are possible in Java, that doesn't make them idiomatic in Java.

Such techniques are possible in Common Lisp and Scheme, and they are closer to being idiomatic in Scheme, but Common Lisp folks will often mutate lists based on cons cells for performance all over the place.

It is easy to win an argument that these techniques are possible in programming language X, for just about any programming language X. Whether you can get practictioners in language X to agree it is a good idea is a completely separate question.

You can write in a an extremely mutable object style in Clojure - it is possible. The mechanisms exist, e.g. set! on Vars, atoms, creating classes with mutable fields using deftype, etc. All very possible and straightforward to do. Could you get a large fraction of Clojure programmers to agree that writing code in that style is a good idea? I doubt it very much.

I like the way you framed it @andy.fingerhut. So here is the question: Could we get Java practitioners to adopt (partially) DOP?

If yes, how? If no, why?

It is based upon the decisions of Java practitioners. If you are getting lots of objections to a public post about how to do it for Java, then you are hearing from the people whose reaction is "why bother doing that in Java? That isn't how typical Java programs are written, so it would be an uphill battle (against other Java developers on your team, probably, and also against java libraries that are most commonly in use that don't follow those practices)".

There might be a minority who read it who are intrigued by the idea, but suppose they wanted to embrace the ideas and use them to their fullest potential? What would you do if you were developing programs in Java for a living full time, and wanted to embrace immutable collections? You might try something like Bifurcan or Paguro, but unless you were content to in many cases continue working with mutable Java collections, because the project you work on hasn't convinced or required all devs to use immutable collections, then you are still having to deal with mutable collections all over the place, too.

You could use immutable collections in C, or assembly, if you really wanted to. Unless your goal was to implement that one library and call it from another language, would you want to write entire assembly or C applications using that technique, with a team of developers who haven't embraced that idea?

As @andy.fingerhut noted above, the practical issue with Java-DOP is probably the mindset (dominantly “imperative” approach, which is not amenable to DOP.) I guess a possible way is to help Java folks adopt DOP using something like https://totallylazy.com/ that is meant to make FP easier in Java. So, it acts as a bridge in the middle, helping people see and understand the FP+DOP model. IMHO without understanding FP it may be hard for most people to understand DOP.

There are JEPs in process that I think might be coming in next or near-ish future JVMs for more value-ish semantics for several JVM classes, e.g. a class like Integer will no longer promise to have separate instances returned from new, you can't lock on it, etc. https://openjdk.java.net/jeps/169

Given that is a backwards-incompatible change, I believe they are rolling out warnings in one JVM, and perhaps other intermediate stages before they actually release a JVM that implements those things.

Java Integer objects are already immutable, so they are not gaining immutability, but losing promises of object identity. I haven't dug deeply, but it appears at the same time the changes would enable creation of more immutable object types by Java devs.

Collections being immutable is a whole different mental ball game for most people, though. There is a non-0 performance cost, in addition to the "how things are typically done" cost.