I really enjoyed the humor in this article. It makes it accessible enough that I will probably send it to a few if my newbie-programmer friends.
After discovering functional programming myself I figure everyone who doesn't love it must not know what is is. It's the best thing since 640k of ram, after all. But there are people who have heard of it, maybe tried it, and just gone right back to their Java and forgetting that the strategy pattern even exists. After talking with some programmers at work I find that they think it isn't necessary and, more than that, isn't approachable.
I personally love the mathematic approach. It is more natural for me after my time in math and physics. Most people don't like math, and we need more articles explaining how FP simplifies programming they are already doing. I liked that this introduction was very approachable in that respect.
I really enjoyed the humor in this article. It makes it accessible enough that I will probably send it to a few if my newbie-programmer friends.
Thanks, that's what I was going for - glad it's funny to someone other than myself ;)
I had been reading through a backlog of old Steve Yegge articles at the time, some of which have very good jokes, and that inspired me to try to use it in this article. I agree that when done well, it can make the information that much more approachable.
The other thing I'd add into something like this is, by analogy, objection orientation is all about binding data to functions and calling it a "method", but what it's really about is what you then build out of that, like the classic Design Patterns. When you program in OO, you don't sit here thinking to yourself "OK, I'm calling a method, wooo! OK, I'm calling another method! Wooo!"
Similarly, this is just the baseline stuff, the really interesting stuff comes out of what you build from that, which varies depending on the precise flavor of functional you are talking about. What's really interesting is what you build out of this stuff; you hardly ever sit there and go "Wooo, I'm mapping! Wooo, I'm reducing! Wheeee!" In fact you can write a lot of Haskell without ever writing the (local equivalent of the) word "reduce" or "filter" because you're always actually using something using that under the hood. (map I do end up using directly with some frequency. And I'm not saying I never use fold or filter directly, but it is often actually under the hood somewhere while you use something yet more declarative.)
Hi HN. Glad you're liking this article. I didn't realize it was on the front page until a reader emailed me directly pointing out a correction.
This actually came out of a conversation I had with one of my best friends, a computational physicist. He writes massively parallel software in Fortran, which runs on supercomputer clusters.
He was curious about this whole functional programming thing; I wrote a very long email explaining/demonstrating some concepts, then later cleaned up and turned it into this article.
I wrote it maybe 3 years ago; if some parts are a little dated (references to python 2.4, etc.), that's why. Though it seems to have held up well enough overall!
Does Icon have list comprehensions? I did a small project using Icon in one of my classes and I don't recall it having them, and I can't quickly find evidence of them.
I really just ran out of time :) Had intended to go back and add that someday, but never did. In retrospect, I think it's fine the way it is - whoever reads that article will have a good foundation for actually using lambdas, which will be easy enough for them to learn about in other ways (if their language of choice even supports lambdas).
Lambdas aren't that interesting after all. I wouldn't call it 'lambda functions', but just 'lambda notation'. Having to name your functions is a inconvenience at most.
> (The above is a heuristic example. So you nice people with the pitchforks there, please forgive that I did not protect against SQL injections, etc. I promise that in real life I did. Thank you.)
The newbie who's just copying and pasting your code won't read that disclaimer. Or care. It's still irresponsible, even as a toy example.
People with knives may not know that they cut. People with hairdryers might not now you're not supposed to use them in the tub and people with microwaves might not know you shouldn't dry your cat in it.
Now, you argue that people who just lift code off of webpages, without even reading all of it, deserve something. What a stupid thing to criticize.
And the newbie who's just earnestly trying to learn the topic at hand won't be able to get through hundreds of lines of paranoiaplate with accompanying discussion of the libraries and best practices used in an article on a totally unrelated topic. Blame the blind copy-paste programmers for being idiots, not the helpful author for only teaching one lesson at a time. Tight focus is a good thing in writing.
I mean, even if he did all the extra work to avoid vulnerabilities, idiots could just ignore that just like they would the disclaimer and only copy-paste the relevant porton. At some point, we have to acknowledge the programmer's responsibility for his own program.
After discovering functional programming myself I figure everyone who doesn't love it must not know what is is. It's the best thing since 640k of ram, after all. But there are people who have heard of it, maybe tried it, and just gone right back to their Java and forgetting that the strategy pattern even exists. After talking with some programmers at work I find that they think it isn't necessary and, more than that, isn't approachable.
I personally love the mathematic approach. It is more natural for me after my time in math and physics. Most people don't like math, and we need more articles explaining how FP simplifies programming they are already doing. I liked that this introduction was very approachable in that respect.