5 ms·

You're still not defining what a "paradigm" is, which is my main objection. You define "FP" to be (what I claim is) a way that's too narrow. Your splitting the

by zodiac 7y ago

You're still not defining what a "paradigm" is, which is my main objection. You define "FP" to be (what I claim is) a way that's too narrow. Your splitting the design space into different paradigms is (I claim) not substantiated. There is a large number of (what I claim are) different design choices such as immutability, first-class functions, monads, dynamic dispatch, etc. You're coming along and saying "some of these features are FP, some are OOP, others are procedural" without any reason why you divide them up this way.

crimsonalucard 7y ago
Please carefully read what I posted. The links specifically. The topic is incredibly deep but my opinion on the topic is concrete and clear meaning that I believe if you read and completely understand what I'm talking about and still completely disagree with me, then our disagreement will just be semantic in nature which is just a disagreement on how we defined a word or what to call something. If you follow the links, read and completely understand what I'm writing you will see I covered everything. Right now it appears you didn't read it. In the links I provided, I define "design," and I operate within the bounds of that definition so you are clear about what I'm talking about. Please read.
- zodiac 7y ago
  > If you follow the links, read and completely understand what I'm writing you will see I covered everything. Right now it appears you didn't read it. Which one of your links define the terms "FP" and "OOP"?
  - crimsonalucard 7y ago
    The second link. It's not strictly defined. You can piece together the definition from your intuition as a programmer and english speaker and also by what I write. If you have trouble doing this, let me know I can clarify.
    - zodiac 7y ago
      My whole point - the one I've been trying to make in every comment in this thread - is that if you want to talk about "FP" as a whole (or "OOP" as a whole), you have to explicitly define it. Relying on intuition or culture is not enough. Like, I use what I think of as FP features much more than I do what I think of as OOP features. In languages commonly thought of as multi-paradigm, say python, I have lots of higher-order functions, and lots of functions which are just compositions of others (I don't write point-free style though). I try hard to avoid implementation inheritance ("OOP inheritance") if possible. I know people who do the exact opposite thing in python. But if I write down the definition of "FP" for me and you write down your definition, I 99% guarantee you they'll be different in a substantive way. So I agree with many of the points you make in the links about how composition works in (what you think of as) FP vs OOP. But I view that as claims about individual design patterns or language features (and very big, fundamental design patterns / language features), not as things called "FP" and "OOP".
      - crimsonalucard 7y ago
        >My whole point - the one I've been trying to make in every comment in this thread - is that if you want to talk about "FP" as a whole (or "OOP" as a whole), you have to explicitly define it. Relying on intuition or culture is not enough. I am aware this is your point. I understand your point. I don't know about you, but I find a conversation of your definition of a term vs. my definition of a term to be uninteresting. Arguing about semantics doesn't matter in my opinion. >You define "FP" to be (what I claim is) a way that's too narrow. Your splitting the design space into different paradigms is (I claim) not substantiated. >So I agree with many of the points you make in the links about how composition works in (what you think of as) FP vs OOP. But I view that as claims about individual design patterns or language features (and very big, fundamental design patterns / language features), not as things called "FP" and "OOP". Your own statements show that you have already derived from my writing what you think I define as FP and OOP. You also implied something about what you believe I defined as "design" saying that I splitted it into "spaces" of different paradigms. So why is there a need for me to explicitly define a definition for you when you already derived it from my writing? Is this your whole point? That your definition of OOP, FP and design is different from my definition but you understand what I'm talking about? Or is there another point you're trying to make? Just to refocus: The topic of our thread is basically the rationale behind why I draw the line at function composition as the main point of FP. Given my definitions of OOP, FP and Design, do you understand why I have this rationale? And if you understand my rationale do you agree with it or disagree?

by zodiac 7y ago

crimsonalucard 7y ago

Please carefully read what I posted. The links specifically. The topic is incredibly deep but my opinion on the topic is concrete and clear meaning that I believe if you read and completely understand what I'm talking about and still completely disagree with me, then our disagreement will just be semantic in nature which is just a disagreement on how we defined a word or what to call something. If you follow the links, read and completely understand what I'm writing you will see I covered everything. Right now it appears you didn't read it. In the links I provided, I define "design," and I operate within the bounds of that definition so you are clear about what I'm talking about. Please read.

zodiac 7y ago
> If you follow the links, read and completely understand what I'm writing you will see I covered everything. Right now it appears you didn't read it. Which one of your links define the terms "FP" and "OOP"?
- crimsonalucard 7y ago
  The second link. It's not strictly defined. You can piece together the definition from your intuition as a programmer and english speaker and also by what I write. If you have trouble doing this, let me know I can clarify.
  - zodiac 7y ago
    My whole point - the one I've been trying to make in every comment in this thread - is that if you want to talk about "FP" as a whole (or "OOP" as a whole), you have to explicitly define it. Relying on intuition or culture is not enough. Like, I use what I think of as FP features much more than I do what I think of as OOP features. In languages commonly thought of as multi-paradigm, say python, I have lots of higher-order functions, and lots of functions which are just compositions of others (I don't write point-free style though). I try hard to avoid implementation inheritance ("OOP inheritance") if possible. I know people who do the exact opposite thing in python. But if I write down the definition of "FP" for me and you write down your definition, I 99% guarantee you they'll be different in a substantive way. So I agree with many of the points you make in the links about how composition works in (what you think of as) FP vs OOP. But I view that as claims about individual design patterns or language features (and very big, fundamental design patterns / language features), not as things called "FP" and "OOP".
    - crimsonalucard 7y ago
      >My whole point - the one I've been trying to make in every comment in this thread - is that if you want to talk about "FP" as a whole (or "OOP" as a whole), you have to explicitly define it. Relying on intuition or culture is not enough. I am aware this is your point. I understand your point. I don't know about you, but I find a conversation of your definition of a term vs. my definition of a term to be uninteresting. Arguing about semantics doesn't matter in my opinion. >You define "FP" to be (what I claim is) a way that's too narrow. Your splitting the design space into different paradigms is (I claim) not substantiated. >So I agree with many of the points you make in the links about how composition works in (what you think of as) FP vs OOP. But I view that as claims about individual design patterns or language features (and very big, fundamental design patterns / language features), not as things called "FP" and "OOP". Your own statements show that you have already derived from my writing what you think I define as FP and OOP. You also implied something about what you believe I defined as "design" saying that I splitted it into "spaces" of different paradigms. So why is there a need for me to explicitly define a definition for you when you already derived it from my writing? Is this your whole point? That your definition of OOP, FP and design is different from my definition but you understand what I'm talking about? Or is there another point you're trying to make? Just to refocus: The topic of our thread is basically the rationale behind why I draw the line at function composition as the main point of FP. Given my definitions of OOP, FP and Design, do you understand why I have this rationale? And if you understand my rationale do you agree with it or disagree?