4 ms·

> Functional programming is about function composition. If you haven't picked up on this notion, than you haven't fully understood FP. Maybe that's exactly why

by hopia 7y ago

> Functional programming is about function composition. If you haven't picked up on this notion, than you haven't fully understood FP. Maybe that's exactly why the likes of Elixir feel so much less functional than some other FP langs. You don't usually compose functions, merely use function application (|>).

gmfawcett 7y ago
I think you've touched on an important point here, namely that functional programming is a feeling. We know it when we see it! But it's hard to get any two people -- even two domain experts -- to agree upon a common definition. To me, functional programming is the feeling that you can successfully reason about a local fragment of code, because you know what the code (and its callers, and callees) can and cannot do with the data being passed around. It's functional in the mathematical sense -- i.e., the output is a pure function of the input, no matter how convoluted the definition -- and knowing this helps us to reason more clearly, mainly because we don't have to worry about unseen effects at a distance. So, functional programming is a feeling of confidence achieved by making data transformations as local and as pure as possible.
- crimsonalucard 7y ago
  Try to not just stick to feelings. Feelings often indicate a lack of understanding. The ultimate goal is to coalesce that feeling into total understanding. The definition of FP is fuzzy and it feels like a "feeling." However, as humans we can formally define the word with an exact definition that fits the "feeling." We've already done it with mathematics and it improved our understanding by a huge margin.
  - gmfawcett 7y ago
    I agree in general that fuzziness isn't desirable. :) But the lack of a proper and widely accepted definition of FP is a perennial issue, and I don't see a resolution in sight. It's not a lack of clear understanding in my opinion, but rather a lack of consensus, and I'm not confident that FP will ever coalesce into a singular definition. What I see in practice is that we have various tribes, using various FP languages, who each define FP in terms of the languages they use (e.g., an FP lang must have certain type-system features, or be non-strict, or etc.). To put it crudely, FP is the thing that we do in our language, and which we perceive others as not doing. I've used the term "tribe" intentionally, as I do think that tribal thinking has had a role to play in the muddying of the term. Given this, I think it's reasonable to demote FP to the level of "feeling", at least in general conversation. Discussions within a certain language community, or in the context of a book or article, are a different matter of course since a formal, contextual definition can be given there.
    - crimsonalucard 7y ago
      >Given this, I think it's reasonable to demote FP to the level of "feeling", at least in general conversation. Discussions within a certain language community, or in the context of a book or article, are a different matter of course since a formal, contextual definition can be given there. This was largely what people thought of mathematics before euclid formalized geometry. An exact definition exists for FP as it did for geometry and like geometry we will instantly recognize the definition of FP when someone finally decides to translate our intuition into formalization.
- Zalastax 7y ago
  Totally agree. I think that locality is what separates true functional programming from languages where some of functional programming features have been added on top. Immutability and types that track effects are means of achieving locality.
- MaxBarraclough 7y ago
  > functional programming is the feeling that you can successfully reason about a local fragment of code, because you know what the code (and its callers, and callees) can and cannot do with the data being passed around That doesn't strike me as a very good definition. It's possible for an imperative language to be explicit about its data-flows. The SPARK language does this. It's certainly not a functional language. https://docs.adacore.com/spark2014-docs/html/ug/en/source/how_to_write_subprogram_contracts.html#generation-of-dependency-contracts https://docs.adacore.com/spark2014-docs/html/ug/en/source/ho...
  - gmfawcett 7y ago
    I'm not claiming that it's a good definition, and I won't try to defend it. It may also not be my definition of FP tomorrow. :) But my very point was that FP has a multitude of subjective definitions, at least in general conversation, so differences of opinion are always to be expected. It's interesting that, while Ada is imperative, SPARK contract annotations aren't. I won't take up the challenge, but I think someone could argue that SPARK-minus-Ada may indeed be functional (although SPARK-minus-Ada is no longer a programming language).
    - MaxBarraclough 7y ago
      'SPARK-minus-Ada' would be 'constraint programming' [0]. I agree with Wikipedia's taxonomy: constraint programming isn't functional programming. In functional programming, we can't just describe the problem, we still have to implement an algorithm. Not so with constraint programming. That's a bright line between the two. I don't agree that functional programming is uniquely difficult to define. Again, I agree with Wikipedia, which offers a definition that seems fine: [Functional programming] treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. [1] It's true that we can disagree on whether immutability, or function composition, should be considered the true crux of functional programming. This isn't unique to FP though. In the object-oriented world, some consider inheritance to be the heart of OOP, and some consider dynamic-dispatch to be what really counts. [3] > SPARK-minus-Ada is no longer a programming language I think I agree, but I think we're in a minority (we seem to disagree with Wikipedia here). If you're working at a level of abstraction so high that you no longer think about algorithms, you aren't really 'programming'. 'Constraint programming'... isn't. The 'programmer' isn't really programming, they're writing a formal problem-description. Formal specification languages like B-Method [4] aren't considered programming languages, for the same reason. [0] https://en.wikipedia.org/wiki/Constraint_programming https://en.wikipedia.org/wiki/Constraint_programming [1] https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming [3] https://news.ycombinator.com/item?id=21849366 https://news.ycombinator.com/item?id=21849366 [4] https://en.wikipedia.org/wiki/B-Method https://en.wikipedia.org/wiki/B-Method
crimsonalucard 7y ago
The |> operator isn't too far off from composition (.) in Haskell. b = (F.G.H)(y) (note F.G.H is a composition of 3 functions into 1, it can be thought of as a single function that is called with parameter y) is not too far off from: b = y |> F |> G |> H It's just the positioning of the "y" that changes. The isomorphism between applicative and point free styles are so close that it basically doesn't matter which style to use. You can easily convert from one style to the other. I advocate the point free style more for educational purposes. To help you see that the composition of functions is fundamental to FP.

by hopia 7y ago

gmfawcett 7y ago

I think you've touched on an important point here, namely that functional programming is a feeling. We know it when we see it! But it's hard to get any two people -- even two domain experts -- to agree upon a common definition. To me, functional programming is the feeling that you can successfully reason about a local fragment of code, because you know what the code (and its callers, and callees) can and cannot do with the data being passed around. It's functional in the mathematical sense -- i.e., the output is a pure function of the input, no matter how convoluted the definition -- and knowing this helps us to reason more clearly, mainly because we don't have to worry about unseen effects at a distance. So, functional programming is a feeling of confidence achieved by making data transformations as local and as pure as possible.

crimsonalucard 7y ago
Try to not just stick to feelings. Feelings often indicate a lack of understanding. The ultimate goal is to coalesce that feeling into total understanding. The definition of FP is fuzzy and it feels like a "feeling." However, as humans we can formally define the word with an exact definition that fits the "feeling." We've already done it with mathematics and it improved our understanding by a huge margin.
- gmfawcett 7y ago
  I agree in general that fuzziness isn't desirable. :) But the lack of a proper and widely accepted definition of FP is a perennial issue, and I don't see a resolution in sight. It's not a lack of clear understanding in my opinion, but rather a lack of consensus, and I'm not confident that FP will ever coalesce into a singular definition. What I see in practice is that we have various tribes, using various FP languages, who each define FP in terms of the languages they use (e.g., an FP lang must have certain type-system features, or be non-strict, or etc.). To put it crudely, FP is the thing that we do in our language, and which we perceive others as not doing. I've used the term "tribe" intentionally, as I do think that tribal thinking has had a role to play in the muddying of the term. Given this, I think it's reasonable to demote FP to the level of "feeling", at least in general conversation. Discussions within a certain language community, or in the context of a book or article, are a different matter of course since a formal, contextual definition can be given there.
  - crimsonalucard 7y ago
    >Given this, I think it's reasonable to demote FP to the level of "feeling", at least in general conversation. Discussions within a certain language community, or in the context of a book or article, are a different matter of course since a formal, contextual definition can be given there. This was largely what people thought of mathematics before euclid formalized geometry. An exact definition exists for FP as it did for geometry and like geometry we will instantly recognize the definition of FP when someone finally decides to translate our intuition into formalization.
Zalastax 7y ago
Totally agree. I think that locality is what separates true functional programming from languages where some of functional programming features have been added on top. Immutability and types that track effects are means of achieving locality.
MaxBarraclough 7y ago
> functional programming is the feeling that you can successfully reason about a local fragment of code, because you know what the code (and its callers, and callees) can and cannot do with the data being passed around That doesn't strike me as a very good definition. It's possible for an imperative language to be explicit about its data-flows. The SPARK language does this. It's certainly not a functional language. https://docs.adacore.com/spark2014-docs/html/ug/en/source/how_to_write_subprogram_contracts.html#generation-of-dependency-contracts https://docs.adacore.com/spark2014-docs/html/ug/en/source/ho...
- gmfawcett 7y ago
  I'm not claiming that it's a good definition, and I won't try to defend it. It may also not be my definition of FP tomorrow. :) But my very point was that FP has a multitude of subjective definitions, at least in general conversation, so differences of opinion are always to be expected. It's interesting that, while Ada is imperative, SPARK contract annotations aren't. I won't take up the challenge, but I think someone could argue that SPARK-minus-Ada may indeed be functional (although SPARK-minus-Ada is no longer a programming language).
  - MaxBarraclough 7y ago
    'SPARK-minus-Ada' would be 'constraint programming' [0]. I agree with Wikipedia's taxonomy: constraint programming isn't functional programming. In functional programming, we can't just describe the problem, we still have to implement an algorithm. Not so with constraint programming. That's a bright line between the two. I don't agree that functional programming is uniquely difficult to define. Again, I agree with Wikipedia, which offers a definition that seems fine: [Functional programming] treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. [1] It's true that we can disagree on whether immutability, or function composition, should be considered the true crux of functional programming. This isn't unique to FP though. In the object-oriented world, some consider inheritance to be the heart of OOP, and some consider dynamic-dispatch to be what really counts. [3] > SPARK-minus-Ada is no longer a programming language I think I agree, but I think we're in a minority (we seem to disagree with Wikipedia here). If you're working at a level of abstraction so high that you no longer think about algorithms, you aren't really 'programming'. 'Constraint programming'... isn't. The 'programmer' isn't really programming, they're writing a formal problem-description. Formal specification languages like B-Method [4] aren't considered programming languages, for the same reason. [0] https://en.wikipedia.org/wiki/Constraint_programming https://en.wikipedia.org/wiki/Constraint_programming [1] https://en.wikipedia.org/wiki/Functional_programming https://en.wikipedia.org/wiki/Functional_programming [3] https://news.ycombinator.com/item?id=21849366 https://news.ycombinator.com/item?id=21849366 [4] https://en.wikipedia.org/wiki/B-Method https://en.wikipedia.org/wiki/B-Method

crimsonalucard 7y ago

The |> operator isn't too far off from composition (.) in Haskell. b = (F.G.H)(y) (note F.G.H is a composition of 3 functions into 1, it can be thought of as a single function that is called with parameter y) is not too far off from: b = y |> F |> G |> H It's just the positioning of the "y" that changes. The isomorphism between applicative and point free styles are so close that it basically doesn't matter which style to use. You can easily convert from one style to the other. I advocate the point free style more for educational purposes. To help you see that the composition of functions is fundamental to FP.