Pissed off about functional programming (2005)

102 点作者 yiransheng将近 11 年前

13 条评论

viraptor将近 11 年前

Maybe I'm missing something, but points 3 and 4 don't make much sense to me. Could someone tell me why I'm wrong here?In myth 3 he seems to mix words of description and the words describing logical equivalence. "even though equals('three',3) is true, length('three') does not equal length(3)" - while this is correct, it only seems to say anything about the myth because of the function name. Try this instead "even though foobar('three',3) is true, length('three') does not equal length(3)" - does this really prove anything? You could never substitute "three" with 3 at any point in the first place.Specifically he hid a "$lut{ $str }" in equals(). It's not that 3 can be substituted with "three" - it can be substituted with "$lut{"three"}".In myth 4 he seems to play a similar trick of talking about the variable names. Sure, perl allows you to create a new block with a new variable of the same name. I'm not sure what does that have to do with functional programming as a whole. It's just the language implementation that allowed you to play this trick - referring to a new thing by a name you used before.

moron4hire将近 11 年前

>> I just had an long and very frustrating conversation with a young programmer who recently discovered functional programming, and thinks it can solve every problem in the world.I'm struck by A) the arrogance of such a statement, and B) how completely unsurprised I am by it. The fact that the rest of the article is nitpicky stuff of no real consequence, with a heaping helping of strawmen and goal-post moving, only supports this. This is a person who fears being wrong and is defending their turf.For the proverbial "you", because this is an endemic problem in our industry:It's not necessary to defend turf, both if you are right and if you are wrong. Obviously, if you are wrong, it saves you time to have someone else figure it out for you and then you can adjust accordingly (you're going to adjust once proven wrong, right?).But if, in some weird happenstance that has yet to be demonstrated in history, you're right, you have expended no effort to defend your position. Sometimes, you have to let people learn their lessons the hard way. Let the youngsters run in their enthusiasm and trip and fall on their face sometimes. It's the only way to build a healthy fear of novelty-for-the-sake-of-novelty, and instill some critical thinking as a matter of course.It's not necessary to be "right" all the time. Just because there are people in the world who are "Doing it Right" versus "Doing it Wrong", doesn't mean you have an ordained duty to inform them.Because I'm really getting sick and tired of being asked "why didn't you use <whatever I like> for that <whatever you wrote>?"

judk将近 11 年前

I assume this post is here to show us that the stupid argumentation about FP vs OOP vs DWIM have been going in circles forever and we should just stop and get back to work.

评论 #8141769 未加载

评论 #8141498 未加载

tel将近 11 年前

While knowledgable sounding... I kind of feel like he was missing out on what pure FP can and does achieve. There were many statements to the effect of "don't pretend X is Y because while Y is obviously great, it's also true that any lang which does Y could not operate (here's an example in Perl)".I reject that last bit, that these things Y lead to a useless language though I do think the proof was far from the pudding 9 years ago.

评论 #8141349 未加载

discreteevent将近 11 年前

"Even a side-effecting function call in C has a well-defined "value" as a state transformer that maps states to pairs of states and values (the so-called "monad" in functional programmers' terminology). The reluctance of functional programmers to call such languages "referentially transparent" merely implies that they are reluctant to admit such complex mathematical/conceptual objects as "values". On the other hand, they seem perfectly willing to call a state transformer a "value" when it is put in their own favourite syntax and dressed up with a buzz word like "monad". I have to say that they are being entirely inconsistent, even if we grant it to them that their idea of "referential transparency" has some coherence."<a href="http://stackoverflow.com/a/11740176" rel="nofollow">http://stackoverflow.com/a/11740176</a>

评论 #8142382 未加载

评论 #8143222 未加载

评论 #8142839 未加载

评论 #8142862 未加载

efnx将近 11 年前

I think his argument held more weight in 2005. Even though Haskell at that point was 10 years old I dont think it was quite the poster child of FP it is today.It's my guess that he's talking about non-pure FPLs like Lisps and MLs, which today don't seem nearly as FP as Haskell, Idris, Agda, Coq - the langs that are now carrying the FP torch.

评论 #8141873 未加载

评论 #8142865 未加载

andrus将近 11 年前

Relevant discussion on LtU: <a href="http://lambda-the-ultimate.org/node/678" rel="nofollow">http://lambda-the-ultimate.org/node/678</a>

amithgeorge将近 11 年前

As a beginner with knowledge of only F# and Clojure, I feel a lot of his issues are solved with having immutable values.> It's theoretically possible that the 'f()' or 'x' might change between the lazy evaluation of step one and the lazy evaluation of step three million. Trying to prevent that is what we programmers call a 'hard' problem.and the examples he gives in Myth 3 & Myth 4 where he reassigns `x` to mean something else. Both of these can be avoided had x been immutable.I agree with the conclusion in Myth 2. I didn't understand the latter half of Myth 3, so can't comment on that.Am I missing something wrt my assumption of immutable values solving most of the issues?

评论 #8142361 未加载

ExpiredLink将近 11 年前

Here's another myth: "Functional programming solves the concurrency problem".<a href="http://www.infoq.com/presentations/java-performance" rel="nofollow">http://www.infoq.com/presentations/java-performance</a>Scroll to 41:05

评论 #8142649 未加载

sdegutis将近 11 年前

To be fair, I've done a fair bit of Clojure and Ruby in my short career, and while it's technically possible to write Ruby code in a Clojure-esque style, it's very ugly and Ruby does not make it very easy. When you write in Ruby, use classes or you will have a headache on your hands!

评论 #8143122 未加载

SeanLuke将近 11 年前

Wait, since when did functional programming imply immutability? I think fifty years of lisp would like to have a few words with this fellow.

评论 #8142353 未加载

评论 #8142166 未加载

评论 #8142131 未加载

评论 #8142164 未加载

kelvin0将近 11 年前

I don't quite get why the 'Substitutability' code snippet fails? Is it because the both vars 'point' to the same RAM address initialized with '3'? If that is the case, I would argue the language is somewhat broken, or at least it`s a major caveat ... Please explain?

评论 #8142640 未加载

评论 #8142268 未加载

wyager将近 11 年前

>It's theoretically possible that the 'f()' or 'x' might change between the lazy evaluation of step one and the lazy evaluation of step three million.You can't re-bind values in the lambda calculus, so no, they never will change. This is why languages like haskell are immutable.His complaint #3 also relies on the false assumption of a mutable language.Complaint #4 was solved by monads, quite a while ago.