3 ms·

It never ceases to amaze me how transparently people project their insecurities. I read your post. It was far too long, and all over the place. My response was

It never ceases to amaze me how transparently people project their insecurities. I read your post. It was far too long, and all over the place. My response was focused only on the aspects I find relevant to the discussion at hand. I do not need (nor have any desire) to pick apart every point you attempt to make, however inaccurate or imprecise I find them to be, in order to compose my argument. >For your Program to be OOP there must exist methods that mutate state Provide me with a single resource that supports this claim (emphasis on "must"). I have found exactly zero corroborating sources that affirm the above, but many that (coincidentally enough all agree) mutability is an implementation detail in OOP. As far I have seen your logic is: 1. Objects _can_ mutate state 2. OOP uses objects 3. OOP _must_ mutate state Something is amiss... But digress. I have quoted, a number of times now, the single excerpt from your OP to which I sought to add some clarity. I suppose I can do it again: >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. The function would not be tied to state and that function can be executed in the context of anything. It's rather narrow in focus, and suggests that separating functions and state leads to more modularized/portable behavior. My response is rather simple in substance: Simply reorganizing `noun.verb` to `verb(noun)` doesn't make any difference in terms of modularization. In other words, the `verb` is tied to `noun` in either case. That is _not_ to say there is no difference at all. In terms of extension (the expression problem) it is well-known that basic OOP and basic FP are complimentary in this regard. Where OOP allows for open extension of data, FP allows for open extension of operation.

crimsonalucard 7y ago
>It never ceases to amaze me how transparently people project their insecurities. I read your post. It was far too long, and all over the place. It wasn't. Likely you just scanned it without any real analysis. The post is long because of charity to you. It was done with examples to help YOU understand. I have obviously failed to anticipate the complete nature of your mental aptitude. The logical conclusion is that you likely aren't intelligent enough to comprehend any of this, this is not my insecurity rather more you reassuring yourself that it isn't reflection of your intellectual abilities. Unfortunately, It is. Also, Nothing was off topic, each part of my response was a reply to each point in your response. >Provide me with a single resource that supports this claim (emphasis on "must"). I have found exactly zero corroborating sources that affirm the above, but many that (coincidentally enough all agree) mutability is an implementation detail in OOP. As far I have seen your logic is: >1. Objects _can_ mutate state >2. OOP uses objects >3. OOP _must_ mutate state >Something is amiss... But digress. I have stated this point a dozen times. Because we are COMPARING OOP with other forms. The attribute of MUTABILITY must be compared. Because THAT is the form that breaks the isomorphism between OOP and FP. Otherwise we are comparing the Exact Same thing. There's no point. That is the property that breaks the "semantic equivalence" So when comparing definitions you MUST incorporate the property of mutability. It MUST be part of the DEFINITION we compare For this reason otherwise we are comparing nothing. I used procedural programming as an isomorphic example of this above and the comparison of Human Males and Females. Read it again, it may kick some of those brain cells into gear. You believe that you are putting more "focus" but rather your incapability of understanding things is making you perceive things as off topic. This conversation won't go anywhere unless you address those topics because what you are doing right now is restating your opinion when I have already addressed why your opinions are wrong. So to move forward you must address why I am wrong about you being wrong. This is how discussions/debates go. That's an extra IQ point given to you for free. Also big thank you for stealing my idea. You're a real stand up guy.
- kingdomcome50 7y ago
  >Because we are COMPARING OOP with other forms I cannot stress this enough: I am _NOT_ comparing OOP with other forms (in a general sense). I have corrected you repeatedly on this (and pointed out how it is straw-man). My claim that `noun.verb` does not differ from `verb(noun)` in terms of modularity is _not_ that same as the (much broader) claim that OOP is isomorphic to FP. I have never made the latter claim, nor do I believe it to be true [1]. I understand that it does not behoove you to address my argument in good faith, but at some point we have to stop running in circles. Maybe you just misunderstood what I was attempting to say? (this is me giving you a chance to save face) [1] If I were pressed to describe the relationship between OOP and FP, I would say they are complimentary approaches to designing software (in reference to the expression problem). I _wouldn't_ go so far as to say they are incompatible with one another: https://stackoverflow.com/questions/3949618/are-fp-and-oo-orthogonal https://stackoverflow.com/questions/3949618/are-fp-and-oo-or... (as a matter of sheer coincidence many of the answers also discuss OOP and mutability)
  - crimsonalucard 7y ago
    >My claim that `noun.verb` does not differ from `verb(noun)` in terms of modularity is _not_ that same as the (much broader) claim that OOP is isomorphic to FP. I have never made the latter claim, nor do I believe it to be true [1]. Yes but the context of the entire thread is OOP. The semantic claim is made in that context. Also intuitively everyone who reads that will think noun.verb is OOP and verb(noun) is not. It's more like you moved the goal posts. This also contradicts your claim of FP being different from OOP despite semantic equivalence. If there was only a semantic equivalence between noun.verb and verb(noun) then this implies OOP and FP are isomorphic. There is no other way to call functions or methods in either case and therefore they are the same under this misguided logic. >Maybe you just misunderstood what I was attempting to say? (this is me giving you a chance to save face) Save face from what? The thousands of people watching this conversation? I don't even care... this is the internet. Nothing was misunderstood by me. You're the one that's misunderstanding. >If I were pressed to describe the relationship between OOP and FP, I would say they are complimentary approaches to designing software (in reference to the expression problem). I _wouldn't_ go so far as to say they are incompatible with one another: https://stackoverflow.com/questions/3949618/are-fp-and-oo-or.. https://stackoverflow.com/questions/3949618/are-fp-and-oo-or.... (as a matter of sheer coincidence many of the answers also discuss OOP and mutability) The expression problem is the same problem in FP and OOP according to your semantic equivalence logic. Simply rewriting noun.verb into verb(noun)and vice versa makes both data and operation problems exist in all forms of programming ONLY when values are immutable. Another way to put it is that FP/immutability solves the expression problem by allowing you to change between the two styles of organization. When OOP is immutable the two approaches are not orthogonal, they become parallel or identical. It is only when mutability is forced by only allowing member functions that mutate values rather then return results does the expression problem begin to change. This is when both design paradigms actually change and the dichotomy of the expression problem becomes apparent in the context of OOP and FP. Stack overflow is even less credible than a medium blog post. There's no reason to resort to what you perceive to be authority to dictate what OOP and FP is. I don't even believe there's an officially sourced definition. All you need to do is take what humans as a majority intuitively understand as OOP and translate that into english. Likely when you ask a typical layman to translate his own intuition he'll get it wrong like the teeming millions on the internet. Just use logic to translate the ludicrous consequences of various "proposed" definitions to see which are valid.

crimsonalucard 7y ago

>It never ceases to amaze me how transparently people project their insecurities. I read your post. It was far too long, and all over the place. It wasn't. Likely you just scanned it without any real analysis. The post is long because of charity to you. It was done with examples to help YOU understand. I have obviously failed to anticipate the complete nature of your mental aptitude. The logical conclusion is that you likely aren't intelligent enough to comprehend any of this, this is not my insecurity rather more you reassuring yourself that it isn't reflection of your intellectual abilities. Unfortunately, It is. Also, Nothing was off topic, each part of my response was a reply to each point in your response. >Provide me with a single resource that supports this claim (emphasis on "must"). I have found exactly zero corroborating sources that affirm the above, but many that (coincidentally enough all agree) mutability is an implementation detail in OOP. As far I have seen your logic is: >1. Objects _can_ mutate state >2. OOP uses objects >3. OOP _must_ mutate state >Something is amiss... But digress. I have stated this point a dozen times. Because we are COMPARING OOP with other forms. The attribute of MUTABILITY must be compared. Because THAT is the form that breaks the isomorphism between OOP and FP. Otherwise we are comparing the Exact Same thing. There's no point. That is the property that breaks the "semantic equivalence" So when comparing definitions you MUST incorporate the property of mutability. It MUST be part of the DEFINITION we compare For this reason otherwise we are comparing nothing. I used procedural programming as an isomorphic example of this above and the comparison of Human Males and Females. Read it again, it may kick some of those brain cells into gear. You believe that you are putting more "focus" but rather your incapability of understanding things is making you perceive things as off topic. This conversation won't go anywhere unless you address those topics because what you are doing right now is restating your opinion when I have already addressed why your opinions are wrong. So to move forward you must address why I am wrong about you being wrong. This is how discussions/debates go. That's an extra IQ point given to you for free. Also big thank you for stealing my idea. You're a real stand up guy.

kingdomcome50 7y ago
>Because we are COMPARING OOP with other forms I cannot stress this enough: I am _NOT_ comparing OOP with other forms (in a general sense). I have corrected you repeatedly on this (and pointed out how it is straw-man). My claim that `noun.verb` does not differ from `verb(noun)` in terms of modularity is _not_ that same as the (much broader) claim that OOP is isomorphic to FP. I have never made the latter claim, nor do I believe it to be true [1]. I understand that it does not behoove you to address my argument in good faith, but at some point we have to stop running in circles. Maybe you just misunderstood what I was attempting to say? (this is me giving you a chance to save face) [1] If I were pressed to describe the relationship between OOP and FP, I would say they are complimentary approaches to designing software (in reference to the expression problem). I _wouldn't_ go so far as to say they are incompatible with one another: https://stackoverflow.com/questions/3949618/are-fp-and-oo-orthogonal https://stackoverflow.com/questions/3949618/are-fp-and-oo-or... (as a matter of sheer coincidence many of the answers also discuss OOP and mutability)
- crimsonalucard 7y ago
  >My claim that `noun.verb` does not differ from `verb(noun)` in terms of modularity is _not_ that same as the (much broader) claim that OOP is isomorphic to FP. I have never made the latter claim, nor do I believe it to be true [1]. Yes but the context of the entire thread is OOP. The semantic claim is made in that context. Also intuitively everyone who reads that will think noun.verb is OOP and verb(noun) is not. It's more like you moved the goal posts. This also contradicts your claim of FP being different from OOP despite semantic equivalence. If there was only a semantic equivalence between noun.verb and verb(noun) then this implies OOP and FP are isomorphic. There is no other way to call functions or methods in either case and therefore they are the same under this misguided logic. >Maybe you just misunderstood what I was attempting to say? (this is me giving you a chance to save face) Save face from what? The thousands of people watching this conversation? I don't even care... this is the internet. Nothing was misunderstood by me. You're the one that's misunderstanding. >If I were pressed to describe the relationship between OOP and FP, I would say they are complimentary approaches to designing software (in reference to the expression problem). I _wouldn't_ go so far as to say they are incompatible with one another: https://stackoverflow.com/questions/3949618/are-fp-and-oo-or.. https://stackoverflow.com/questions/3949618/are-fp-and-oo-or.... (as a matter of sheer coincidence many of the answers also discuss OOP and mutability) The expression problem is the same problem in FP and OOP according to your semantic equivalence logic. Simply rewriting noun.verb into verb(noun)and vice versa makes both data and operation problems exist in all forms of programming ONLY when values are immutable. Another way to put it is that FP/immutability solves the expression problem by allowing you to change between the two styles of organization. When OOP is immutable the two approaches are not orthogonal, they become parallel or identical. It is only when mutability is forced by only allowing member functions that mutate values rather then return results does the expression problem begin to change. This is when both design paradigms actually change and the dichotomy of the expression problem becomes apparent in the context of OOP and FP. Stack overflow is even less credible than a medium blog post. There's no reason to resort to what you perceive to be authority to dictate what OOP and FP is. I don't even believe there's an officially sourced definition. All you need to do is take what humans as a majority intuitively understand as OOP and translate that into english. Likely when you ask a typical layman to translate his own intuition he'll get it wrong like the teeming millions on the internet. Just use logic to translate the ludicrous consequences of various "proposed" definitions to see which are valid.