4 ms·

I urge you to attempt to condense your replies into more coherent prose. I'm not entirely sure what my takeaways from the above should be. You seem to have mov

I urge you to attempt to condense your replies into more coherent prose. I'm not entirely sure what my takeaways from the above should be. You seem to have moved the goalposts again from "OOP requires mutability" (which I think you have given up) to "OOP is different from FP": >THE CORE DIFFERENTIATOR IS MUTABILITY Aside from the fact that the above is not true (the core differnetiator is all of those "features" listed in the OOP wiki), I have explained a couple of times now that I did engage in this to argue about the differences between OOP and FP. There are numerous differences, and they have very little to do with my (or your) original claims -- other than the fact that you keep trying to move the goalposts to this topic as a means to say that because OOP is different than FP, `noun.verb` must also be different than `verb(noun)` in terms of modularity/dependencies. You are broadening my claim substantially (straw-man). Again, this is the claim you made: >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. to which myself and two other commentors sought to clarify. The `function` above cannot be executed in the context of anything. It _must_ be executed from a context that has a reference to `state` (because `state` is an argument to `function`). Notably, this is the _same_ context required to invoke the `method`. Similarly, the context of the `function` and the context of the `method` are the same -- they both have access to the same variables (dependencies). So yes, `noun.verb` vs `verb(noun)` is just semantics; both the surrounding and internal contexts are the same. Choosing one approach to express the behavior over the other makes no difference in terms of modularity/dependencies.

crimsonalucard 7y ago
>I urge you to attempt to condense your replies into more coherent prose My prose is coherent. I urge you to gain the intelligence to comprehend it. The only real option is to take english classes. This is not an insult, I see no alternative to help you comprehend english better other than taking a class. Seriously. It's not me, it's you. > I'm not entirely sure what my takeaways from the above should be. It's your comprehension that needs work. Re-read it if you can't understand or ask for clarification before you respond. If you have good english then honestly the only other logical explanation is your intelligence. Again not an insult, just observations. >"OOP requires mutability" It does THIS NEVER CHANGED. But many methods can be stateless. For your Program to be OOP there must exist methods that mutate state. It IS REQUIRED. If not then you're not doing OOP. Get it? >Aside from the fact that the above is not true (the core differnetiator is all of those "features" listed in the OOP wiki), I have explained a couple of times now that I did engage in this to argue about the differences between OOP and FP. There are numerous differences, and they have very little to do with my (or your) original claims -- other than the fact that you keep trying to move the goalposts to this topic as a means to say that because OOP is different than FP, `noun.verb` must also be different than `verb(noun)` in terms of modularity/dependencies. You are broadening my claim substantially (straw-man). Why don't you read my entire claim and respond to each snippet as I have done for you. Rather than take one of my claims ignore all the evidence I provided and go off on your own wild tangent and calling it a straw man. If you want to make my claim a strawman you need to respond to EACH of my points of evidence. I honestly don't even think you read my post. You just did a quick scan and used coherency as an excuse to avoid reading. I responded to your "kudos" as well, which was completely ignored. >to which myself and two other commentors sought to clarify. The `function` above cannot be executed in the context of anything. It _must_ be executed from a context that has a reference to `state` (because `state` is an argument to `function`). Notably, this is the _same_ context required to invoke the `method`. Similarly, the context of the `function` and the context of the `method` are the same -- they both have access to the same variables (dependencies). So yes, `noun.verb` vs `verb(noun)` is just semantics; both the surrounding and internal contexts are the same. Choosing one approach to express the behavior over the other makes no difference in terms of modularity/dependencies. Man, we're going in circles. This is crystal clear and you are WRONG. Read all previous post CAREFULLY. Respond to each point if you disagree. The logic is inescapable if you have the ability to follow it. If not this conversation is over.
- kingdomcome50 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. 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.

crimsonalucard 7y ago

>I urge you to attempt to condense your replies into more coherent prose My prose is coherent. I urge you to gain the intelligence to comprehend it. The only real option is to take english classes. This is not an insult, I see no alternative to help you comprehend english better other than taking a class. Seriously. It's not me, it's you. > I'm not entirely sure what my takeaways from the above should be. It's your comprehension that needs work. Re-read it if you can't understand or ask for clarification before you respond. If you have good english then honestly the only other logical explanation is your intelligence. Again not an insult, just observations. >"OOP requires mutability" It does THIS NEVER CHANGED. But many methods can be stateless. For your Program to be OOP there must exist methods that mutate state. It IS REQUIRED. If not then you're not doing OOP. Get it? >Aside from the fact that the above is not true (the core differnetiator is all of those "features" listed in the OOP wiki), I have explained a couple of times now that I did engage in this to argue about the differences between OOP and FP. There are numerous differences, and they have very little to do with my (or your) original claims -- other than the fact that you keep trying to move the goalposts to this topic as a means to say that because OOP is different than FP, `noun.verb` must also be different than `verb(noun)` in terms of modularity/dependencies. You are broadening my claim substantially (straw-man). Why don't you read my entire claim and respond to each snippet as I have done for you. Rather than take one of my claims ignore all the evidence I provided and go off on your own wild tangent and calling it a straw man. If you want to make my claim a strawman you need to respond to EACH of my points of evidence. I honestly don't even think you read my post. You just did a quick scan and used coherency as an excuse to avoid reading. I responded to your "kudos" as well, which was completely ignored. >to which myself and two other commentors sought to clarify. The `function` above cannot be executed in the context of anything. It _must_ be executed from a context that has a reference to `state` (because `state` is an argument to `function`). Notably, this is the _same_ context required to invoke the `method`. Similarly, the context of the `function` and the context of the `method` are the same -- they both have access to the same variables (dependencies). So yes, `noun.verb` vs `verb(noun)` is just semantics; both the surrounding and internal contexts are the same. Choosing one approach to express the behavior over the other makes no difference in terms of modularity/dependencies. Man, we're going in circles. This is crystal clear and you are WRONG. Read all previous post CAREFULLY. Respond to each point if you disagree. The logic is inescapable if you have the ability to follow it. If not this conversation is over.

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