Where did that come from? I didn’t spot anything wrong in his comment, and I’m pretty knowledgeable myself (I’m no authority, but I believe my grasp of FP is quite comprehensive).
(Edit: Retracted: I now see it did came from somewhere: several comments, including the top one)
Functional programming isn’t an idiomatic approach to container manipulation, it’s a paradigm that avoids mutable state and data. Write a GUI in Haskell using pure functions to see how different the functional approach is and what it is at its core. Or just compare a typical textbook on imperative algorithms with one on functional algorithms. Container manipulation with functions is just an idiom.
And sure you can write functional code in C++, for example (which by the way has map, filter, fold, and so on), but you can also write OO code in C. But few people do, and for a reason: the language makes it near impossible or, at the very least, undesirable for humans. That’s close enough for the distinction being located in the language.
Functional programming isn’t an idiomatic approach to container manipulation, it’s a paradigm that avoids mutable state and data.
I’m not sure you and jimrandomh actually disagree on that point. I mean, avoiding mutable state is bound to change your approach to container manipulation. You described the root cause, he described the surface differences.
Also,
And sure you can write functional code in C++, for example (which by the way has map, filter, fold, and so on), but you can also write OO code in C. But few people do, and for a reason: […]
jimrandomh knows that:
(The main exceptions are non-garbage-collected languages, which can’t use the functional style because it interacts badly with object ownership, and Java, which lacks lambda expressions as a symptom of much bigger problems).
I personally tried functional style in C++, and did feel the pain ( is unusable before C++11). There are ways however to limit the damage. And languages such as Python and Javascript do not discourage the functional style so much. Their libraries do.
Now sure, languages do favour a style over the other, like Ocaml vs Lua. It does let us classify them meaningfully. On the other hand, it is quite easy to go against the default. I’m pretty sure both you and jimrandomh agree with that as well.
From the look of it, you just talked past each other, while there was no real disagreement to begin with…
In light of the following comment by jim, I think we do disagree:
Please be careful about exposing programmers to ideology; it frequently turns into politics kills their minds. This piece in particular is a well-known mindkiller, and I have personally witnessed great minds acting very stupid because of it. The functional/imperative distinction is not a real one, and even if it were, it’s less important to provability than languages’ complexity, the quality of their type systems and the amount of stupid lurking in their dark corners.
And while I would normally interpret jim’s nearest comment in this thread charitably (i.e., mostly in agreement with me), it’s more reasonable to interpret in light of quoted comment.
I think he probably doesn’t or didn’t understand the functional paradigm. If he did, I think he would know about its usefulness in concurrent or parallel programming, and consequently know that it is not just a mind-killing ideology like US political parties, but a paradigm with real advantages and real disadvantages over other paradigms. I don’t think he would have written his first comment if he really knew that. I think he’s probably confusing the functional idiomatic approach/style/dialect/whatever with the functional paradigm. I mean he says “The majority of the difference between functional style and imperative style is in how you deal with collections.” And remember this thread was created in reference to a comment about a textbook on functional programming (not functional “style”—maybe he’s backpedaling or charitably he means fp).
(also c++ is a non-garbage-collected language. And more importantly I don’t mean to shit on jim. I’m more worried about how many people thought it was a comment worth being at the top of the comment section in a thread about course recommendations for FAI researchers. I would have been fine ignoring it otherwise)
The functional/imperative distinction is not a real one
Oops.
I think he’s probably confusing the functional idiomatic approach/style/dialect/whatever with the functional paradigm. I mean he says “The majority of the difference between functional style and imperative style is in how you deal with collections.”
If I got it, you are saying that he perceived the surface features (dealing with collections), but not their deeper cause (avoid mutable state). Sounds about right. Re-oops, I guess.
I don’t mean to shit on jim.
Now it occurred to me that I may have forced you to. Sorry.
Where did that come from? I didn’t spot anything wrong in his comment, and I’m pretty knowledgeable myself (I’m no authority, but I believe my grasp of FP is quite comprehensive).
(Edit: Retracted: I now see it did came from somewhere: several comments, including the top one)
Functional programming isn’t an idiomatic approach to container manipulation, it’s a paradigm that avoids mutable state and data. Write a GUI in Haskell using pure functions to see how different the functional approach is and what it is at its core. Or just compare a typical textbook on imperative algorithms with one on functional algorithms. Container manipulation with functions is just an idiom.
And sure you can write functional code in C++, for example (which by the way has map, filter, fold, and so on), but you can also write OO code in C. But few people do, and for a reason: the language makes it near impossible or, at the very least, undesirable for humans. That’s close enough for the distinction being located in the language.
I’m not sure you and jimrandomh actually disagree on that point. I mean, avoiding mutable state is bound to change your approach to container manipulation. You described the root cause, he described the surface differences.
Also,
jimrandomh knows that:
I personally tried functional style in C++, and did feel the pain ( is unusable before C++11). There are ways however to limit the damage. And languages such as Python and Javascript do not discourage the functional style so much. Their libraries do.
Now sure, languages do favour a style over the other, like Ocaml vs Lua. It does let us classify them meaningfully. On the other hand, it is quite easy to go against the default. I’m pretty sure both you and jimrandomh agree with that as well.
From the look of it, you just talked past each other, while there was no real disagreement to begin with…
In light of the following comment by jim, I think we do disagree:
And while I would normally interpret jim’s nearest comment in this thread charitably (i.e., mostly in agreement with me), it’s more reasonable to interpret in light of quoted comment.
I think he probably doesn’t or didn’t understand the functional paradigm. If he did, I think he would know about its usefulness in concurrent or parallel programming, and consequently know that it is not just a mind-killing ideology like US political parties, but a paradigm with real advantages and real disadvantages over other paradigms. I don’t think he would have written his first comment if he really knew that. I think he’s probably confusing the functional idiomatic approach/style/dialect/whatever with the functional paradigm. I mean he says “The majority of the difference between functional style and imperative style is in how you deal with collections.” And remember this thread was created in reference to a comment about a textbook on functional programming (not functional “style”—maybe he’s backpedaling or charitably he means fp).
(also c++ is a non-garbage-collected language. And more importantly I don’t mean to shit on jim. I’m more worried about how many people thought it was a comment worth being at the top of the comment section in a thread about course recommendations for FAI researchers. I would have been fine ignoring it otherwise)
Let’s see:
Oops.
If I got it, you are saying that he perceived the surface features (dealing with collections), but not their deeper cause (avoid mutable state). Sounds about right. Re-oops, I guess.
Now it occurred to me that I may have forced you to. Sorry.