3 ms·

I agree that the heart of the matter is abstraction and composition. I agree that function composition is an important part of FP. I agree that FP languages sho

by zodiac 7y ago

I agree that the heart of the matter is abstraction and composition. I agree that function composition is an important part of FP. I agree that FP languages should allow point-free composition However I think the claim "functional programming is about function composition", together with the claim that "other things commonly associated such as immutability are not defining features of functional programming", is a stronger claim that seems unsubstantiated. There are many design choices analogous to immutability vs mutability that people argue are defining features of or are not defining features of FP. A Lisper might argue that closures over first-class mutable data can be part of the FP paradigm, or even that an FP language must allow that, while a Haskeller might argue that no, this must be modelled on top of immutable data. I see merit in common arguments presented for both viewpoints. A Haskeller might argue that monadic composition and syntactic support for it is a defining feature of FP, because simulating it with only "plain" function composition is deficient in some way. A criticism of this might be that monad transformers don't compose well. They might argue functions that functions should not be strict by default, because non-strict functions compose better than functions which are not. There's a great Quora answer that talks about this (https://www.quora.com/After-Haskell-there-is-no-language-which-uses-lazy-evaluation-by-default-So-is-lazy-by-default-a-mistake https://www.quora.com/After-Haskell-there-is-no-language-whi...) and I remember a blog post framing this more explicitly in terms of composition that I can't find right now. I'm just sketching arguments that I've heard/thought about, but all these arguments deal with composition, abstraction and functions. I don't like the framing of "does a procedure or an object compose better" because not all design choices fall into one of those, in fact I think very few do in a useful way. Is multiple dynamic dispatch (e.g. Julia) a way to compose functions or objects?

crimsonalucard 7y ago
>I don't like the framing of "does a procedure or an object compose better" because not all design choices fall into one of those I never went into why FP is better. I only said I believe it is better and that composition lies at the heart of this differentiation. So you are offering an opinion on something that I haven't expanded upon yet. Allow me to explain why I believe composition in FP is a "better design" than other paradigms. First let's get on the same page about the true nature of design. What is it? I talk about it here: https://news.ycombinator.com/item?id=21953290 https://news.ycombinator.com/item?id=21953290 Once we're on the same page on what is design in general you can read about why I believe FP is better in general. I posted on quora, a definition of "good design" in the context programming and program organization. Then I go into why FP under this definition is "better." https://www.quora.com/Is-senior-full-stack-engineer-Ilya-Suzdalnitski-right-that-theres-no-objective-evidence-that-object-oriented-programming-OOP-is-better-than-plain-procedural-programming-And-is-OOP-in-fact-a-trillion-dollar-disaster/answer/Bernard-Yip-2?__filter__=all&__nsrc__=1&__sncid__=4038270328&__snid3__=6613124125 https://www.quora.com/Is-senior-full-stack-engineer-Ilya-Suz... The answer is not straightforward and I get into the caveats in the comments on that quora post. I believe the definitions for design that I am describing are universal and concretely illustrate what we all talk about when we talk about "design." If you have a different definition of design than the problem is just semantic in nature. At the very least I think we can agree that in terms of this definition of "good design" FP is the better than OOP and imperative.
- 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.
        7y ago

by zodiac 7y ago

crimsonalucard 7y ago

>I don't like the framing of "does a procedure or an object compose better" because not all design choices fall into one of those I never went into why FP is better. I only said I believe it is better and that composition lies at the heart of this differentiation. So you are offering an opinion on something that I haven't expanded upon yet. Allow me to explain why I believe composition in FP is a "better design" than other paradigms. First let's get on the same page about the true nature of design. What is it? I talk about it here: https://news.ycombinator.com/item?id=21953290 https://news.ycombinator.com/item?id=21953290 Once we're on the same page on what is design in general you can read about why I believe FP is better in general. I posted on quora, a definition of "good design" in the context programming and program organization. Then I go into why FP under this definition is "better." https://www.quora.com/Is-senior-full-stack-engineer-Ilya-Suzdalnitski-right-that-theres-no-objective-evidence-that-object-oriented-programming-OOP-is-better-than-plain-procedural-programming-And-is-OOP-in-fact-a-trillion-dollar-disaster/answer/Bernard-Yip-2?__filter__=all&__nsrc__=1&__sncid__=4038270328&__snid3__=6613124125 https://www.quora.com/Is-senior-full-stack-engineer-Ilya-Suz... The answer is not straightforward and I get into the caveats in the comments on that quora post. I believe the definitions for design that I am describing are universal and concretely illustrate what we all talk about when we talk about "design." If you have a different definition of design than the problem is just semantic in nature. At the very least I think we can agree that in terms of this definition of "good design" FP is the better than OOP and imperative.

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