4 ms·

It has to be pure functional programming to get the full benefits of compositionality. Most mainstream "functional programming" is not necessarily pure and side

It has to be pure functional programming to get the full benefits of compositionality. Most mainstream "functional programming" is not necessarily pure and side-effects are not controlled/tracked. Analogous to how "mostly secure" is not secure, "mostly functional" does not get the full benefits. Pure functional programming is complex, one has to compose effectful functions differently to pure functions. But the pieces do really fit like Lego bricks, especially when the same mathematical abstractions are used consistently. The Haskell community has been extremely effective at creating such consistency, by promoting various abstractions using category theory as a guide. The object-oriented community is not so different in this regard with their promotion of "patterns". I've been writing Haskell professionally for 8 years. The problems with Haskell are the tooling, language stability, the learning curve and the difficulty of reasoning about performance, especially space usage. But composition and re-use works.

hellofunk 6y ago
I'm sorry but this is a lot of shallow hyperbole. It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller. So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language. In the end, lego pieces are ultimately about the data itself, not how it is manipulated. The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language.
- willtim 6y ago
  > It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller. If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it. I do not understand your point. > So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language I guess you mean structured data types here? But you have missed my point completely about side-effects, it is side-effects (coupling via back-channels) that prevent composition, in general, in an OO language. OO languages also typically have an obsession with nominal types that can impede reuse. > The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language. You appear to be suggesting that languages/tools don't matter? Why not aspire towards languages that encourage safe composition and re-usable software? Your argument reduces down to "good motorcyclists don't need helmets".
  - hellofunk 6y ago
    All of your points make great sense in theory, but in practice it rarely works out so smoothly. > If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it. And this is exactly how any well constructed OO API works as well. You can have really good and really bad APIs in any language, it really is up to the skill of the developers. I firmly believe that, there’s no language or tool that suddenly makes you create better things. I have in my jobs interacted with high profile robust APIs in C++ as well as functional languages. They can be a joy to use when designed well, regardless of language.
    - crimsonalucard5 6y ago
      >I firmly believe that, there’s no language or tool that suddenly makes you create better things. This belief makes no logical sense. I can easily define a language for you or a tool that can prevent you from EVER making a good thing and I can easily define a tool that can ONLY allow you to make one good thing. For example a programming language that always compiles into a program that does nothing Or A program that always compiles into a performant news website. Ludicrous examples, I know, but important nonetheless. Why are they important? Because these tools illustrate the existence of extremes. If extremes exist then the entire domain must be a spectrum of some sort. Logically, Within this spectrum there are tools that can very much almost magically help you make great things and tools that do the exact opposite. By logic All the tools we have must currently live somewhere on this spectrum. It's just that the problem is so broad we can't prove exactly where on the spectrum each of these tools actually lives... hence debate. However the existence of extremes proves that a spectrum exists and all tools must exist somewhere on the spectrum and some tools must be better than others.
      - hellofunk 6y ago
        > Ludicrous examples Yes they are, and it's not really adding to the debate.

hellofunk 6y ago

I'm sorry but this is a lot of shallow hyperbole. It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller. So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language. In the end, lego pieces are ultimately about the data itself, not how it is manipulated. The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language.

willtim 6y ago
> It doesn't matter if your functions are pure if they return a unique data type for your API or library that is not understood easily by the caller. If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it. I do not understand your point. > So the solution is to make that data easily convertible or generic.. and guess what? That's no different than doing the same in an OO language I guess you mean structured data types here? But you have missed my point completely about side-effects, it is side-effects (coupling via back-channels) that prevent composition, in general, in an OO language. OO languages also typically have an obsession with nominal types that can impede reuse. > The key ingredient in making software reusable and portable is the talent and experience of the engineer, regardless of language. You appear to be suggesting that languages/tools don't matter? Why not aspire towards languages that encourage safe composition and re-usable software? Your argument reduces down to "good motorcyclists don't need helmets".
- hellofunk 6y ago
  All of your points make great sense in theory, but in practice it rarely works out so smoothly. > If it's an abstract data type, it doesn't have to be understood by the caller, it just has to be passed to another "lego brick" which understands the abstract interface. If it's a structured data-type, then there's no reason why it shouldn't be understood by the caller, the type should tell you how to consume it. And this is exactly how any well constructed OO API works as well. You can have really good and really bad APIs in any language, it really is up to the skill of the developers. I firmly believe that, there’s no language or tool that suddenly makes you create better things. I have in my jobs interacted with high profile robust APIs in C++ as well as functional languages. They can be a joy to use when designed well, regardless of language.
  - crimsonalucard5 6y ago
    >I firmly believe that, there’s no language or tool that suddenly makes you create better things. This belief makes no logical sense. I can easily define a language for you or a tool that can prevent you from EVER making a good thing and I can easily define a tool that can ONLY allow you to make one good thing. For example a programming language that always compiles into a program that does nothing Or A program that always compiles into a performant news website. Ludicrous examples, I know, but important nonetheless. Why are they important? Because these tools illustrate the existence of extremes. If extremes exist then the entire domain must be a spectrum of some sort. Logically, Within this spectrum there are tools that can very much almost magically help you make great things and tools that do the exact opposite. By logic All the tools we have must currently live somewhere on this spectrum. It's just that the problem is so broad we can't prove exactly where on the spectrum each of these tools actually lives... hence debate. However the existence of extremes proves that a spectrum exists and all tools must exist somewhere on the spectrum and some tools must be better than others.
    - hellofunk 6y ago
      > Ludicrous examples Yes they are, and it's not really adding to the debate.