>OOP is programming oriented around objects. The core feature of OOP is objects

Objects DO NOT HAVE to be mutable. As I have _repeatedly_ stated, you are building a straw-man. That is, you are creating your _own_ definition of OOP (objects and to some degree FP) and using it to support your argument about modularity. Refer to the "Specialized Objects" section of: https://en.wikipedia.org/wiki/Object_(computer_science)

>Immutable object: an object set up with a fixed state at creation time and which does not change afterward.

Crystal clear. Even the single sentence in which you are basing this entire waste-of-time argument on:

>A feature of objects is an object's procedures that can access and often modify the data fields of the object with which they are associated

in no way supports your conclusion with any rational reading. A "feature" of objects is procedures that can "often" modify fields. It takes some serious gymnastics to read that as "mutability is a required property of OOP". I have yet to find a resource that supports your definition of OOP (and I'm looking!).

>if you use immutability your program is isomorphic to functional programming

Being isomorphic to a functional program doesn't mean the program isn't OOP. From the same page above:

>Object-oriented programming is an approach to designing modular reusable software systems

OOP is an approach. It is the _approach_ one takes when designing a system that determines whether or not that system should be understood as OOP. If the approach uses the "Features" of OOP (listed on the wiki), then the system is OOP.

Your entrenchment on this topic is astounding. Again, I don't have to be wrong about `noun.verb` vs `verb(noun)` for your conclusions about how we abstract software to stand. My intention wasn't to disagree with you, it was simply to point out that all paradigms suffer from modularity problems as they relate to functions acting on state.

>it is easier. We've talked about the deeper difference

No, but we have. And I've clearly demonstrated that same problem presents itself. That's how we got here. You needed to change the constraints of the problem (that objects _must_ mutate) in order to make a coherent argument (the straw-man). That got us to this separate argument about the definition of OOP (moved goal posts). Here is the moment above when you played your hand (and lost the argument):

>A stateless function versus a function that carries it's own mute-able state. There is MORE than a semantic difference. The semantic difference you're referring to is when the SELF value is immuteable. In that case the two ways of calling the function become more similar, but THAT is NOT OOP

Instead of doubling down and starting this dumper-fire of a discussion, you could have simply responded with something like:

"That's correct. Which makes it even more pragmatic that we strive to abstract the server model into code, because the problems with modularity/distribution cannot be avoided in _any_ programming paradigm. That is, the level of abstraction where we WRITE code is not the same, or appropriate level of abstraction used to modularize/distribute code. If, instead of explicitly hard-coding the boundaries of communication into a system, we could abstract the boundaries into compilation as a matter of configuration, it would allow for any arbitrary level of modularization/distrubution without the need to change the source code itself".

The above makes a great point (your point), and has actually served as inspiration for my latest side-project. So kudos to you for that.