6 ms·

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. Ag

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. >The problem is associated with modularity problems grouping two primitives together into a single entity >If that method was never unionized with state, if we used smaller subdivisions in our code where state and functions are separate entities then this would be much less of a problem >all the problems of realizing how to divide or unionize services and state in microservices are exact same problems that existed when trying to figure out what methods belong with what object in OOP 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 don't have to be wrong about this. `noun.verb` doesn't have to be materially different than `verb(noun)` for the validity of your point to hold about the difficulties of designing and distributing systems being the major obstacle and that abstracting the server model into code being more pragmatic than abstracting the code into the server model. 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. If anything I am _strengthening_ your argument.

crimsonalucard 7y ago
>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.
- kingdomcome50 7y ago
  The Wikipedia page to which you keep referring does not support the argument that mutability is "core property" of OOP. The quote you've cited (far above at this point) is referring to a feature of objects, not OOP. OOP encompasses range of features. You can explore them on that very same page under the "Features" section. You will certainly notice that "Mutability" is not listed as a feature. OOP is an _approach_. Simply using objects does not mean you are practicing OOP any more than using functions means you are practicing FP. I urge to to a ctrl+F on "mutable" and read the top 2 (of 3) passages where it is referenced (the third is not relevant): > ... in most OOP languages, in particular in all those that allow mutable objects. > ... in OOP languages (with mutable objects) ... The clarifications in the above passages are unnecessary if mutability is considered a necessary feature for OOP. If that's not enough, how about you read the first sentence of https://en.wikipedia.org/wiki/Immutable_object https://en.wikipedia.org/wiki/Immutable_object: > In object-oriented and functional programming, an immutable object (unchangeable[1] object) is an object whose state cannot be modified after it is created. If immutable objects are incompatible with OOP, why is it included in the above? Are you suggesting that if I write a Java program and I use all of the features of OOP (inheritance, polymorphism, encapsulation, etc.) but don't use mutability, that my system is better understood as functional? Come on. What about an OOP system that doesn't mutate by design? Not every program requires changes of state. We need to put this to rest. I can pretend "this never happened". After all, this entire argument is not relevant to the point I was trying to make (the whole goalpost thing). > Much easier to change a function operating on the wrong type than it is to change a method intrinsically tied to scoped variables _This_ is to the point I was trying to make. The above is simply untrue. If I have a function referenced all over my code base, `validate(giraffe)`, and we change the signature to `validate(gorilla)`, it isn't any easier to refactor the system than if it were modeled in OOP. In both cases, the _caller_ needs to have a reference to a different piece of data in order to call our `validate` function. Which means the caller of the caller needs to have a different piece of data (so now the caller needs to change), etc. up the stack. In the end, the most flexible solution in either paradigm is to "inject" the appropriate data (`giraffe`/`gorilla`) via the "DI" mechanism that the paradigm supports. In OOP this is in the constructor. In FP we can use partial application. These two concepts _are_ isomorphic. I am _not_ saying that OOP is "the same as" all other forms. I am saying, in terms of the pitfalls regarding modelling a domain, all forms are the same. As I understand it, this is the argument your OP was making (you just left FP out of it). I agree that OOP is worse than FP. There are a few features of FP that make it superior in many respects (notably required immutability and an algebraic type system).

crimsonalucard 7y ago

>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.

kingdomcome50 7y ago
The Wikipedia page to which you keep referring does not support the argument that mutability is "core property" of OOP. The quote you've cited (far above at this point) is referring to a feature of objects, not OOP. OOP encompasses range of features. You can explore them on that very same page under the "Features" section. You will certainly notice that "Mutability" is not listed as a feature. OOP is an _approach_. Simply using objects does not mean you are practicing OOP any more than using functions means you are practicing FP. I urge to to a ctrl+F on "mutable" and read the top 2 (of 3) passages where it is referenced (the third is not relevant): > ... in most OOP languages, in particular in all those that allow mutable objects. > ... in OOP languages (with mutable objects) ... The clarifications in the above passages are unnecessary if mutability is considered a necessary feature for OOP. If that's not enough, how about you read the first sentence of https://en.wikipedia.org/wiki/Immutable_object https://en.wikipedia.org/wiki/Immutable_object: > In object-oriented and functional programming, an immutable object (unchangeable[1] object) is an object whose state cannot be modified after it is created. If immutable objects are incompatible with OOP, why is it included in the above? Are you suggesting that if I write a Java program and I use all of the features of OOP (inheritance, polymorphism, encapsulation, etc.) but don't use mutability, that my system is better understood as functional? Come on. What about an OOP system that doesn't mutate by design? Not every program requires changes of state. We need to put this to rest. I can pretend "this never happened". After all, this entire argument is not relevant to the point I was trying to make (the whole goalpost thing). > Much easier to change a function operating on the wrong type than it is to change a method intrinsically tied to scoped variables _This_ is to the point I was trying to make. The above is simply untrue. If I have a function referenced all over my code base, `validate(giraffe)`, and we change the signature to `validate(gorilla)`, it isn't any easier to refactor the system than if it were modeled in OOP. In both cases, the _caller_ needs to have a reference to a different piece of data in order to call our `validate` function. Which means the caller of the caller needs to have a different piece of data (so now the caller needs to change), etc. up the stack. In the end, the most flexible solution in either paradigm is to "inject" the appropriate data (`giraffe`/`gorilla`) via the "DI" mechanism that the paradigm supports. In OOP this is in the constructor. In FP we can use partial application. These two concepts _are_ isomorphic. I am _not_ saying that OOP is "the same as" all other forms. I am saying, in terms of the pitfalls regarding modelling a domain, all forms are the same. As I understand it, this is the argument your OP was making (you just left FP out of it). I agree that OOP is worse than FP. There are a few features of FP that make it superior in many respects (notably required immutability and an algebraic type system).