7 ms·

The only assertion I need to make (and have made repeatedly), is that `noun.verb` and `verb(noun)` are subject to the same constraints. In terms of mutability,

The only assertion I need to make (and have made repeatedly), is that `noun.verb` and `verb(noun)` are subject to the same constraints. In terms of mutability, we can say that both functions could mutate `noun` or both functions could not mutate `noun`. It is a straw-man to build an argument against a premise which arbitrarily asserts that `noun.verb` _behaves_ differently than `verb(noun)`. The behavior of the function(s) is not relevant to point you were trying to make or my point of clarification (of course two functions that behave differently are different!). Again: >The function would not be tied to state and that function can be executed in the context of anything The above is the claim which prompted this lengthy discussion. It has nothing to do with the definition of OOP or mutability. To rephrase your argument in my own words: Separating data and behavior (state and functions resp.), in the form of `verb(noun)`, is superior to combining data and behavior, in the form of `noun.verb`, because it means `verb` is subject to fewer constraints and, as a result, is more portable. The above is not accurate. There _are_ problems introduced by encapsulation. But one of them is not that functions are tied to state. This remains true for any function no matter how it is written (the semantics). I'm not sure why you continue to insist on moving the goalposts here, especially to an argument for which you are so obviously wrong. The definition of OOP makes no claims about mutability. Furthermore, many of the most popular OOP languages provide built-in support for defining objects as immutable (while at the same time implementing immutable objects in their own standard libraries. e.g. `string` in many languages). Even a cursory google search on the subject unambiguously yields this information. I'm not going to waste my time debating this when you are fully capable of researching and revising your position. Especially because this has nothing to do with the claims that provoked this discussion in the first place. My original comment was rather innocuous. It was intended as a point of clarification towards a claim you made as part of your broader opinions on the deficits that OOP impose on a system as it relates to functions, state, and modularity. You essentially say the same thing later in your post in your comparison between the OOP model and microservices: >The difference here is rather then unionizing action and state with Code it unionizes state and action with real cold hard metal. The actual machine that holds state and "does stuff" is the object. So 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... Just replace "microservices" with "FP" in that last sentence and you will have basically synthesized my argument: "all the problems of realizing how to divide or unionize services and state in FP are exact same problems that existed when trying to figure out what methods belong with what object in OOP" For what it's worth, I agree with your ultimate conclusions.

crimsonalucard 7y ago
>>The function would not be tied to state and that function can be executed in the context of anything >The above is the claim which prompted this lengthy discussion. It has nothing to do with the definition of OOP or mutability. To rephrase your argument in my own words: >Separating data and behavior (state and functions resp.), in the form of `verb(noun)`, is superior to combining data and behavior, in the form of `noun.verb`, because it means `verb` is subject to fewer constraints and, as a result, is more portable. >The above is not accurate. There _are_ problems introduced by encapsulation. But one of them is not that functions are tied to state. This remains true for any function no matter how it is written (the semantics). Have you ever thought about the difference between a list of "noun.methods" that encapsulate a "noun" vs. a list of "verb(noun)" that also encapsulate a noun? Under your semantic equivalence principle it's the same thing. IN your universe one can encapsulate a noun with procedural functions through type signatures AND it can be done with OOP as well. We are of course negating the usage of a noun as a global variable. Also what is the "noun" in "noun.verb"? Can it be a namespace? Is "noun.verb" the same as "namespace.verb"? Namespaces hold variables and functions and so do Objects... Are these two concepts isomorphic? If regular programming already has namespaces what's so special about Object Oriented programming? What's the point of calling a namespace an object? Well then you could say that OOP allows the user to "generate" or "instantiate" namespaces at runtime. That's neat except what is the point of generating a new namespace for what is essentially the same thing? Why do I need namespace1.verb and namespace2.verb when I can just have verb(namespace) or just get rid of OOP and have a single namespace.verb? Well you could argue that namespace1 and namespace2 have different states. That's why you need the ability to instantiate them. But then what's the point of instantiating different namespaces at runtime when you can just have verb(namespace1) or verb(namespace2)? What's the point of OOP if it's the same thing as everything else in existence? Was OOP invented for semantic confusion only? Well no, in OOP the namespace.verb() verb modifies the instantiated namespace. namespace1.verb is DIFFERENT from namespace2.verb because they are modifying different states. This is OOP. If VERB was stateless and did not touch the state of namespace2 or namespace1 then there would be no difference and you wouldn't be doing OOP. It is mutation that ties a method to state. The goal posts were never moved. When you talk about OOP you have to talk about it in the context of mutation because that's what Wikipedia lists as part of the definition and that is the only unique and logical difference between OOP and other forms of programming. Thus you must be mutating or reading internal state to be doing OOP. In the context of OOP and the sort example, noun.verb MUST modify noun otherwise we aren't talking about OOP. IN the context of procedural functions verb(noun), verb COULD modify noun OR it could NOT. In FP verb CANNOT modify noun ever. FP: verb(noun), verb cannot modify noun OOP: noun.verb, verb MUST modify noun Procedural programming: verb(noun), verb can modify noun or it may not. The implementation changes depending on the context and the context is 100% OOP. For any styles to be isomorphic (which is what you are implying) the properties must match exactly. I talked about OOP in my first comment, you were making a clarification about it in reference to another person who was also talking under the SAME oop context. The title of this entire thread has OOP in it. We are talking about OOP. You can bend procedural programming to be isomorphic to OOP. But this isn't a two way equivalence, you cannot always bend OOP to fit a procedural function. This statement from you (a perversion of a statement I made earlier) is ALSO categorically wrong: >"all the problems of realizing how to divide or unionize services and state in FP are exact same problems that existed when trying to figure out what methods belong with what object in OOP" In FP, everything has to be immutable. This the exact opposite of a required property for OOP. OOP uses mutability to tie methods with state. Also you should note the definition of encapsulation is literally my argument of unionizing state with methods plus the added property of information hiding or aka private members and methods (https://www.wikiwand.com/en/Encapsulation_(computer_programming) https://www.wikiwand.com/en/Encapsulation_(computer_programm...). That's it. Since you're basically saying that the unionization of state and methods ISN'T the problem... you must be referring to information hiding. The private keyword, according to you is the problem with OOP. All of the problems with OOP (encapsulation) according to you could be fixed if people stopped using the private keyword. Amazing. Take a look at python... no private keyword... didn't fix anything. >For what it's worth, I agree with your ultimate conclusions. If you think encapsulation is the cause of the "ultimate conclusion" you need to realize, namespaces and modules and libraries also encapsulate things with no problems. The source of OOP's problems is not in encapsulation. You or whoever introduced that idea to you is completely wrong. Literally you can write a metaprogramming script that removes all the private keywords from objects and according to your logic will fix the problem.

crimsonalucard 7y ago

>>The function would not be tied to state and that function can be executed in the context of anything >The above is the claim which prompted this lengthy discussion. It has nothing to do with the definition of OOP or mutability. To rephrase your argument in my own words: >Separating data and behavior (state and functions resp.), in the form of `verb(noun)`, is superior to combining data and behavior, in the form of `noun.verb`, because it means `verb` is subject to fewer constraints and, as a result, is more portable. >The above is not accurate. There _are_ problems introduced by encapsulation. But one of them is not that functions are tied to state. This remains true for any function no matter how it is written (the semantics). Have you ever thought about the difference between a list of "noun.methods" that encapsulate a "noun" vs. a list of "verb(noun)" that also encapsulate a noun? Under your semantic equivalence principle it's the same thing. IN your universe one can encapsulate a noun with procedural functions through type signatures AND it can be done with OOP as well. We are of course negating the usage of a noun as a global variable. Also what is the "noun" in "noun.verb"? Can it be a namespace? Is "noun.verb" the same as "namespace.verb"? Namespaces hold variables and functions and so do Objects... Are these two concepts isomorphic? If regular programming already has namespaces what's so special about Object Oriented programming? What's the point of calling a namespace an object? Well then you could say that OOP allows the user to "generate" or "instantiate" namespaces at runtime. That's neat except what is the point of generating a new namespace for what is essentially the same thing? Why do I need namespace1.verb and namespace2.verb when I can just have verb(namespace) or just get rid of OOP and have a single namespace.verb? Well you could argue that namespace1 and namespace2 have different states. That's why you need the ability to instantiate them. But then what's the point of instantiating different namespaces at runtime when you can just have verb(namespace1) or verb(namespace2)? What's the point of OOP if it's the same thing as everything else in existence? Was OOP invented for semantic confusion only? Well no, in OOP the namespace.verb() verb modifies the instantiated namespace. namespace1.verb is DIFFERENT from namespace2.verb because they are modifying different states. This is OOP. If VERB was stateless and did not touch the state of namespace2 or namespace1 then there would be no difference and you wouldn't be doing OOP. It is mutation that ties a method to state. The goal posts were never moved. When you talk about OOP you have to talk about it in the context of mutation because that's what Wikipedia lists as part of the definition and that is the only unique and logical difference between OOP and other forms of programming. Thus you must be mutating or reading internal state to be doing OOP. In the context of OOP and the sort example, noun.verb MUST modify noun otherwise we aren't talking about OOP. IN the context of procedural functions verb(noun), verb COULD modify noun OR it could NOT. In FP verb CANNOT modify noun ever. FP: verb(noun), verb cannot modify noun OOP: noun.verb, verb MUST modify noun Procedural programming: verb(noun), verb can modify noun or it may not. The implementation changes depending on the context and the context is 100% OOP. For any styles to be isomorphic (which is what you are implying) the properties must match exactly. I talked about OOP in my first comment, you were making a clarification about it in reference to another person who was also talking under the SAME oop context. The title of this entire thread has OOP in it. We are talking about OOP. You can bend procedural programming to be isomorphic to OOP. But this isn't a two way equivalence, you cannot always bend OOP to fit a procedural function. This statement from you (a perversion of a statement I made earlier) is ALSO categorically wrong: >"all the problems of realizing how to divide or unionize services and state in FP are exact same problems that existed when trying to figure out what methods belong with what object in OOP" In FP, everything has to be immutable. This the exact opposite of a required property for OOP. OOP uses mutability to tie methods with state. Also you should note the definition of encapsulation is literally my argument of unionizing state with methods plus the added property of information hiding or aka private members and methods (https://www.wikiwand.com/en/Encapsulation_(computer_programming) https://www.wikiwand.com/en/Encapsulation_(computer_programm...). That's it. Since you're basically saying that the unionization of state and methods ISN'T the problem... you must be referring to information hiding. The private keyword, according to you is the problem with OOP. All of the problems with OOP (encapsulation) according to you could be fixed if people stopped using the private keyword. Amazing. Take a look at python... no private keyword... didn't fix anything. >For what it's worth, I agree with your ultimate conclusions. If you think encapsulation is the cause of the "ultimate conclusion" you need to realize, namespaces and modules and libraries also encapsulate things with no problems. The source of OOP's problems is not in encapsulation. You or whoever introduced that idea to you is completely wrong. Literally you can write a metaprogramming script that removes all the private keywords from objects and according to your logic will fix the problem.