(and I guess that would also prompt me to ask "What do you think the good parts of OO are?" -- and, full disclosure, I was on the ANSI C++ Standards Committee from '92 to '99, and got started with Java in '97, so with that background I'm often very interested when I hear folks talk on this topic)

I think the good part, as it relates to what spec is, is that structure is kept validated (in OO, only in terms of types and composite types, which is what most objects in a program are) at most points. This helps 50% of the programmer population keeping programs in check, although, recently, unit-tests have culturally evolved into another aid in that regard.

@U04V70XH6 obviously my thoughts aren't that interesting, I've not been on any committee.

The problem is that with Java, and several other OO languages, you have no way to separate type and structure — they are conflated. You can’t talk about data structures without giving them class/type names and your only form of “validation” really is the type system. It’s both “not enough” and “too much”. So I don’t find that to be a good part of OO — I find it to be a failing. The same with encapsulation: it makes it harder to treat data generically and so you end up with a stack of design patterns to workaround the restrictions of the OO type system — and I’ve just gradually found the downsides outweigh the benefits. Mind you, you’re right about the “50% of the programmer population”: Java is very effective at allowing large numbers of average developers to work together to build large, complex systems. Java makes developers fungible… But I don’t think developers should be fungible 🙂

I concur on all points made. Just not sure how encapsulation makes it hard to generically treat data

It might seem valid to encapsulate, especially when delivering a library (to make the codebase have a restricted API facade or making it explicit what are the internals of a module vs how to use it)

But as said, I probably need help seeing the negative implications. I am sincerely curious about them

If you encapsulate your data in a specific type, then you need a function on that specific type to manipulate it. If you want to use a generic function, you have to use the underlying implementation data, “breaking” encapsulation, and then put all the data back afterward. In other words, in Java, if you have an object that contains an array of other data, you can’t use generic array functions without exposing the array directly, i.e., unencapsulating it. Clojure’s approach is that the “API” is just data — immutable data — so if the implementation is a vector (array), then you can use any generic sequence function on it.