Sorry for trolling, but sometimes I just have to.
“Look at my intentionally non-thread-safe, spaghetti imperative implementation. It sucks! So FP sucks.”
“Look at my intentionally non-thread-safe, spaghetti imperative implementation. It sucks! So FP sucks.”
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.
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.
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.
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".
No true scotsman fallacy.
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.
> I hope it stands to reason that it doesn't matter what people who've never used FP claim about FP.
That doesn't matter. An argument is not a strawman if it has been made by anyone, anywhere, anytime, for any reason. You can't just filter out the people you think don't count.
An argument is only a strawman if it is a false argument, e.g. one that has been invented by the person who is arguing against it.
If you want to have a discussion about the merits of FP, feel free to filter out whoever you like. But you said the argument mentioned in the article is a strawman, and it isn't.
It seems there's a phase that some FP programmers go through where they have a zealotry that requires convincing the masses of the glorious wonders of FP. For the most part, they seem to either outgrow the "FP is the One True Way" zealotry, or at least learn to keep it to themselves for the most part.
In fairness, I'd say that I've seen it on HN less in the last year or so than I did before that.
Can you provide an example of someone who claims "FP guarantees good code"?
At least implying that? Probably not at the moment, given how many different ways it can be stated, and given that I've forgotten what the search engine for HN is. (There is one, but I failed to bookmark it when it was called to my attention.)
But I tell you that here on HN, I personally have argued against views that in my view are at least similar to that. Similar enough that you'll think they are the same? I can't answer that, partly because of my own forgetfulness of the exact details, partly because I don't know what you'd consider similar enough to count.
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.“
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.
We should make an unemployable list and put these people on it.
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.