> The reason “Why Functional Programming Matters” was necessary in the first place was that functional programming had been mischaracterised as a paradigm of negatives—no mutation, no side-effects—so everybody knew what you couldn’t do, but few people grasped what you could.
The issue with functional programming, and the reason for that referenced piece, aren't because people don't know what you can do with functional programming languages.
It's because people don't know why they should care.
Things like "immutability, referential transparency, mathematical purity" are pretty, and it's neat to see the machinery applied in practice, but in the end people pick their tools because they help them get their jobs done more effectively, and it's exceedingly difficult to explain to a working programmer why "referential transparency" is gonna meaningfully improve their lives.
This piece, then, starts from this basic misunderstanding and proceeds to make precisely the same mistake.
Yes, what the author demonstrates in this piece is pretty neat. But why should I care? What would motivate me to move off of the imperative languages I'm already familiar with?
You say that people know what they can do with FP. Then you say that it is “pretty” and it is “neat” to see the machinery in action. I.e. it’s just superficial stuff.
Seems your precise disagreement with the author is: the author thinks that FP is useful and you don’t. Because people who argue for FP don’t do it because it’s a neat and pretty exercise.
> Seems your precise disagreement with the author is: the author thinks that FP is useful and you don’t.
I'm afraid you've misunderstood my point. I had no intent to make a value judgement about FP whatsoever, one way or the other.
My criticism is about the messaging.
IMO this piece misses the mark because it starts off with a faulty premise, and it's the same mistake I've seen made by every other article about FP.
My comment was inspired by the fact that I got to the end of the piece thinking "that's pretty cool, but I still don't understand why I should care about this in practice", and then I looked back at the thesis and realized the author never intended to explain that because they misunderstood the motivation for writing "Why Functional Programming Matters" in the first place.
Honestly I'm not terribly interested in participating in that particular debate (I've been around long enough to know to avoid religious discussions), but I will say this:
Step 1: define FP.
Does that mean purity (meaning no side effects)?
Does that mean immutability?
Does that mean powerful and novel type systems?
Does that mean code as data?
Does that just mean a specific approach and practice of software construction and composition?
IMO a huge part of the battle when discussing FP is settling on the terms of debate.
I think some things that people throw under the FP umbrella are valuable and pragmatic and some aren't.
My point is FP isn't a monolith and the term is a bit of a Rorschach test.
I remember a time when Lisp was considered the quintessential FP language and was taught in schools as an example of the paradigm.
Today, Haskell adherents would scoff at the idea that Lisp is anything but a procedural language dressed up with some casual nods to the lambda calculus.
So your question is somewhat meaningless without qualification, and asking me to set the terms of debate is odd given you're the one who posed the question in the first place.
Let’s remember that you are the one who quoted the part about FP and how you took issue with it. But in a very strange way: the quote is wrong, not because people don’t know about the benefits of FP but because they don’t… know why they should “care”. But this is not a value judgement, you said (being apparently useless to the working programmer is not a value judgement). So you have some kind of opinion about FP. It felt natural to ask exactly what that opinion is, since it’s stated so indirectly (care). But now FP is a “Rorschach test” and anyone who wants to discuss it with you needs to tediously lay out exactly what kind of FP they mean by FP. Even though you are the one who prominently brought up FP in your comment (even though perhaps the point you were driving at was why one should care about conc. programming). And even though you had a handy reference in “Why FP Matters” that you referenced yourself.
FP is certainly not a Rorschach test compared to your obfuscated and indirect style of writing on this specific topic.
> (being apparently useless to the working programmer is not a value judgement)
Except I never said that.
You seem to be very confused about what I wrote and frankly seem to have an axe to grind. I suggest you read it again.
Mine was a point about articles advocating for FP, not about FP itself.
> So you have some kind of opinion about FP.
No, I don't, which is why I was reluctant to being baited into this discussion in the first place. Clearly I should've followed my instincts.
I have an opinion about the author's interpretation of the Why FP Matters essay, and I have an opinion about the structure and delivery of their message. I have an opinion about articles advocating for FP. I don't have a strong opinion about FP itself.
That's the difference between critiquing the content of an argument vs the structure of an argument.
Yes that's a subtle distinction.
> And even though you had a handy reference in “Why FP Matters” that you referenced yourself.
Did you actually read the article? Because I did.
The article cited that essay, not me. My criticism is in the author's interpretation of that essay.
> FP is certainly not a Rorschach test compared to your obfuscated and indirect style of writing on this specific topic.
And now it's getting personal. This will be my last response in this conversation. Carry on arguing without me if you like.
> The reason “Why Functional Programming Matters” was necessary in the first place was that functional programming had been mischaracterised as a paradigm of negatives—no mutation, no side-effects—so everybody knew what you couldn’t do, but few people grasped what you could.
The issue with functional programming, and the reason for that referenced piece, aren't because people don't know what you can do with functional programming languages.
It's because people don't know why they should care.
Things like "immutability, referential transparency, mathematical purity" are pretty, and it's neat to see the machinery applied in practice, but in the end people pick their tools because they help them get their jobs done more effectively, and it's exceedingly difficult to explain to a working programmer why "referential transparency" is gonna meaningfully improve their lives.
This piece, then, starts from this basic misunderstanding and proceeds to make precisely the same mistake.
Yes, what the author demonstrates in this piece is pretty neat. But why should I care? What would motivate me to move off of the imperative languages I'm already familiar with?