5 ms·

Sorry for trolling, but sometimes I just have to. “Look at my intentionally non-thread-safe, spaghetti imperative implementation. It sucks! So FP sucks.”

by lelf 10y ago

twblalock 10y ago
You're missing the point. The author used that example to demonstrate that just using FP languages is not enough to ensure good code, because it is possible to write bad code in FP languages. Therefore, FP programming languages are not going to guarantee you good code by themselves. They will only get you good code if you use them to write good code. By the way, the author never said "FP sucks," and that's a very uncharitable and unreasonable interpretation of the argument. From the article: > My view is that although FP makes it easier to write good code, just because something’s functional, or even “purely functional”, doesn’t necessarily mean it’s any good. Stated differently, as software engineers trying to improve our craft, we shouldn’t latch onto or defend something just because it’s “functional” or “purely functional”. Although it’s possible to write good code using techniques from functional programming, it’s also possible to write bad code. FP doesn’t protect us. We need a different measure for “good code” than just “functional”. You may think that "FP guarantees good code" is a strawman argument, but it isn't. A quick search of this site will turn up people who make that very argument. It's useful to have a realistic corrective to the pseudo-religious fervor of some FP proponents, and this article provides that.
- the_af 10y ago
  But isn't that arguing against a strawman? Nobody is arguing that FP code is automatically good by virtue of being written in an FP-oriented language. For example, you can write a beautiful algorithm that solves the wrong problem. No language will help you with that. Or you can write a program in language X that ignores every convention or practice -- you can write code that makes an extraordinary effort at subverting the type system, for example -- but that's more of an argument against your understanding of X. I do agree with the author that FP, good as it is, is not enough. That's not an argument against FP, it's an argument in favor of devising even better tools, practices and the theoretical underpinnings for building correct software.
  - twblalock 10y ago
    > Nobody is arguing that FP code is automatically good by virtue of being written in an FP-oriented language. People do say that, so it's not a strawman. > I do agree with the author that FP, good as it is, is not enough. That's not an argument against FP, it's an argument in favor of devising even better tools, practices and the theoretical underpinnings for building correct software. The article was not an argument against FP. Why do you think it is? It is simply an argument against a certain justification for using FP, namely that it guarantees good code.
    - the_af 10y ago
      > People do say that, so it's not a strawman. Who says this? No-one who is a serious practitioner of FP (as opposed to someone who just reads about it in blogs) will tell you that FP automatically guarantees good code. You'll hear that FP goes a long way at reducing some common sources of errors, which is a pretty big deal, but automatically correct code? No-one will claim that. > The article was not an argument against FP. I didn't say the article was. Besides the clickbait title, and some dubious assertions (and a poor example with QuickSort), I do agree with the overall assertion that "FP is good, but not enough".
      - twblalock 10y ago
        > Who says this? No-one who is a serious practitioner of FP (as opposed to someone who just reads about it in blogs) will tell you that FP automatically guarantees good code. No true scotsman fallacy.
        the_af 10y ago
        The problem with the No True Scotsman fallacy is that it's impossible to apply to the internet, where there is always someone out there who will claim anything about anything. Therefore, in order to have a rational discussion about this, we must apply some sort of filter. I propose this filter: no-one who is an actual practitioner of FP (someone who uses it to build software, not someone who just talks about it in the internet) will not make the claim you mentioned, i.e. "FP guarantees good code" (I'm quoting you verbatim). I hope it stands to reason that it doesn't matter what people who've never used FP claim about FP.
- lelf 10y ago
  > You're missing the point. I don't think I am. That code deliberately uses Haskell’s low-level features. It’s like saying, “hey, high-level languages don‘t even save you from segfaults! Just look at my purposely crafted low-level code in a high-level (but not dead, so it has low-level interface) language that access memory at 0.“
  - twblalock 10y ago
    You are still missing the point. The author argues that using FP does not guarantee good code. All that is necessary to prove that is to demonstrate bad FP code, which he has done. Only a single example is required to disprove a universal assertion. > It’s like saying, “hey, high-level languages don‘t even save you from segfaults! Just look at my purposely crafted low-level code in a high-level (but not dead, so it has low-level interface) language that access memory at 0.“ If someone argued that high level languages save you from segfaults, your statement would be a valid argument against that, just as the article has provided a valid argument against a particular belief about FP.
- JustSomeNobody 10y ago
  > A quick search of this site will turn up people who make that very argument We should make an unemployable list and put these people on it.
AnimalMuppet 10y ago
If that had been his point, your reply would have been relevant. Instead, it's just trolling. His point was that writing in an FP language doesn't mean that you're not writing trash. An FP language (or even an FP orientation/mindset) isn't enough. It may be helpful, but it's not enough. Haskell won't save you, and neither will using higher-order functions.

Sorry for trolling, but sometimes I just have to. “Look at my intentionally non-thread-safe, spaghetti imperative implementation. It sucks! So FP sucks.”

by lelf 10y ago

Sorry for trolling, but sometimes I just have to. “Look at my intentionally non-thread-safe, spaghetti imperative implementation. It sucks! So FP sucks.”

twblalock 10y ago

You're missing the point. The author used that example to demonstrate that just using FP languages is not enough to ensure good code, because it is possible to write bad code in FP languages. Therefore, FP programming languages are not going to guarantee you good code by themselves. They will only get you good code if you use them to write good code. By the way, the author never said "FP sucks," and that's a very uncharitable and unreasonable interpretation of the argument. From the article: > My view is that although FP makes it easier to write good code, just because something’s functional, or even “purely functional”, doesn’t necessarily mean it’s any good. Stated differently, as software engineers trying to improve our craft, we shouldn’t latch onto or defend something just because it’s “functional” or “purely functional”. Although it’s possible to write good code using techniques from functional programming, it’s also possible to write bad code. FP doesn’t protect us. We need a different measure for “good code” than just “functional”. You may think that "FP guarantees good code" is a strawman argument, but it isn't. A quick search of this site will turn up people who make that very argument. It's useful to have a realistic corrective to the pseudo-religious fervor of some FP proponents, and this article provides that.

the_af 10y ago
But isn't that arguing against a strawman? Nobody is arguing that FP code is automatically good by virtue of being written in an FP-oriented language. For example, you can write a beautiful algorithm that solves the wrong problem. No language will help you with that. Or you can write a program in language X that ignores every convention or practice -- you can write code that makes an extraordinary effort at subverting the type system, for example -- but that's more of an argument against your understanding of X. I do agree with the author that FP, good as it is, is not enough. That's not an argument against FP, it's an argument in favor of devising even better tools, practices and the theoretical underpinnings for building correct software.
- twblalock 10y ago
  > Nobody is arguing that FP code is automatically good by virtue of being written in an FP-oriented language. People do say that, so it's not a strawman. > I do agree with the author that FP, good as it is, is not enough. That's not an argument against FP, it's an argument in favor of devising even better tools, practices and the theoretical underpinnings for building correct software. The article was not an argument against FP. Why do you think it is? It is simply an argument against a certain justification for using FP, namely that it guarantees good code.
  - the_af 10y ago
    > People do say that, so it's not a strawman. Who says this? No-one who is a serious practitioner of FP (as opposed to someone who just reads about it in blogs) will tell you that FP automatically guarantees good code. You'll hear that FP goes a long way at reducing some common sources of errors, which is a pretty big deal, but automatically correct code? No-one will claim that. > The article was not an argument against FP. I didn't say the article was. Besides the clickbait title, and some dubious assertions (and a poor example with QuickSort), I do agree with the overall assertion that "FP is good, but not enough".
    - twblalock 10y ago
      > Who says this? No-one who is a serious practitioner of FP (as opposed to someone who just reads about it in blogs) will tell you that FP automatically guarantees good code. No true scotsman fallacy.
      - the_af 10y ago
        The problem with the No True Scotsman fallacy is that it's impossible to apply to the internet, where there is always someone out there who will claim anything about anything. Therefore, in order to have a rational discussion about this, we must apply some sort of filter. I propose this filter: no-one who is an actual practitioner of FP (someone who uses it to build software, not someone who just talks about it in the internet) will not make the claim you mentioned, i.e. "FP guarantees good code" (I'm quoting you verbatim). I hope it stands to reason that it doesn't matter what people who've never used FP claim about FP.
lelf 10y ago
> You're missing the point. I don't think I am. That code deliberately uses Haskell’s low-level features. It’s like saying, “hey, high-level languages don‘t even save you from segfaults! Just look at my purposely crafted low-level code in a high-level (but not dead, so it has low-level interface) language that access memory at 0.“
- twblalock 10y ago
  You are still missing the point. The author argues that using FP does not guarantee good code. All that is necessary to prove that is to demonstrate bad FP code, which he has done. Only a single example is required to disprove a universal assertion. > It’s like saying, “hey, high-level languages don‘t even save you from segfaults! Just look at my purposely crafted low-level code in a high-level (but not dead, so it has low-level interface) language that access memory at 0.“ If someone argued that high level languages save you from segfaults, your statement would be a valid argument against that, just as the article has provided a valid argument against a particular belief about FP.
JustSomeNobody 10y ago
> A quick search of this site will turn up people who make that very argument We should make an unemployable list and put these people on it.

AnimalMuppet 10y ago

If that had been his point, your reply would have been relevant. Instead, it's just trolling. His point was that writing in an FP language doesn't mean that you're not writing trash. An FP language (or even an FP orientation/mindset) isn't enough. It may be helpful, but it's not enough. Haskell won't save you, and neither will using higher-order functions.