5 ms·

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

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.
      - crimsonalucard5 6y ago
        Unfortunately for you, it does add to the debate. I just proved to you a spectrum exists and some tools are better than others. I find your attitude offensive btw. Please tone it down and respond with something substantial other than "You're wrong." If you feel it doesn't add to the debate tell me why you think so and I'll tell you why you're wrong. edit: stop flagging my posts for no reason. I'm literally just having a conversation with you, not insulting you or offending you. Don't use the HN tools to lash out emotionally. Please respond with reason and logic and I will do the same. Your last flag on my other response, btw was denied.

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.
    - crimsonalucard5 6y ago
      Unfortunately for you, it does add to the debate. I just proved to you a spectrum exists and some tools are better than others. I find your attitude offensive btw. Please tone it down and respond with something substantial other than "You're wrong." If you feel it doesn't add to the debate tell me why you think so and I'll tell you why you're wrong. edit: stop flagging my posts for no reason. I'm literally just having a conversation with you, not insulting you or offending you. Don't use the HN tools to lash out emotionally. Please respond with reason and logic and I will do the same. Your last flag on my other response, btw was denied.