>In OOP, unlike FP, immutability is an implementation detail, not a requirement. I'm trying to be gentle about this, but your insistence is becoming tiresome. Again, just do a search and inform yourself. I'm not going to patronize you by listing the numerous links/resources that clarify the above distinction.

I patronized you with wikipedia. Go ahead and send me some links to some blog posts. Just note that some medium blog posters "opinion" on OOP like your opinion doesn't mean anything without a proper logical reasoning. You will see tons of people who say garbage like "OOP" is "orthogonal" to "FP" which is equal to the amount of people who don't know what FP actually is.

>Maybe I'm misunderstanding you argument, but I understand "the problem[s]" above (your words) to be a matter of organization not implementation -- I see no reference to mutability.

I didn't mention it because it's a very subtle property that's very hard to see and very hard to explain. People understand how OOP is organized on the surface, they don't understand the subtleties of it. Only when we get into details does it come out: Mutability is the very property that dictates the organization of OOP. I get how it appears that I'm moving "goal posts" since I didn't bring it up explicitly in the beginning.

What happened was you noticed a subtle isomorphism between two paradigms but the details were even subtler then that. This is when I chose to bring up the topic of mutability because this is the core property that is intrinsically tied to the organization of OOP. In short, I dove into the details when you brought up a detail... Anyway, mutability It is the core property that breaks the isomorphism and dictates our vocabulary... it's why we have the term OOP, FP and Procedural Programming in the first place.

>I am simply clarifying that you can create the same problems with organization in FP as OOP. That is, you can write a function with the wrong signature just the same as you can put a method on the wrong object. Modelling a domain happens before any code is written (theoretically). There is nothing inherent in either paradigm that forces a developer to synthesize a useful abstraction of the functional requirements of their system any better than the other one.

You're talking about the application of programming styles to the real world which is amenable to opinion.

One paradigm is more flexible to change.

Much easier to change a function operating on the wrong type than it is to change a method intrinsically tied to scoped variables that change state.

The biggest key difference is that FP gives you flexibility to change the model once the inevitable design flaws become apparent.

You will note that in OOP there are no functions or data. Only data bundled with methods called Objects can exist. It's easy to see how these arbitrary walls cause numerous design issues. Also, again, it is the mutability of each object that is the actual instigator of this organizational scheme, I am not talking about the "semantic difference" you pointed out earlier.

>If anything I am _strengthening_ your argument.

I disagree. I believe OOP is actually worse than most other styles of programming for most cases. You are saying OOP is the same as all other forms.