I am. I know python quite well, but I did not understand functional programming before I read this article. Oh sure, I'd looked it up on wikipedia, and read a few blog posts, and perused a Haskell tutorial, but none of that made it click. Too many new concepts at once. Using python as the instructive language is great simply because many people know python, and for those who don't, the syntax is easy to follow.

This article was perfect for me. The "guide rope" paragraph instantly clarified and put into context all the other disjoint pieces of information that I had picked up.

I can now see how to apply these concepts in almost any language. Right away, I can see how to refactor my side-effect-riddled C++ to make it more suitable for unit tests.

I came across this piece after following a previous story on HN, and was very tempted to post it at the time, because it really helped me.

It really is an excellent introduction to FP, but:

> I know python quite well, but I did not understand functional programming before I read this article

Sounds like someone who would have benefitted from practical uses of FP in python, such as comprehensions.

...It's a really neat article, but I think it would have been considerably improved with asides for "And here's an even cleaner way to write this, if you're using python"

I do know list comprehensions, and I use them all the time (not trying to be defensive here, just providing context). I understand that they are just a different syntax for mapping -- applying a function to members of a list to produce a new list. However, while list comprehensions are clean and pythonic syntax, I think the "map" syntax more clearly illustrates the concept that the author is trying to teach.

Your suggestion for asides is certainly valid, and I agree would make it more useful for budding pythonistas. I just think that her focus was to introduce functional concepts, and python was simply an easy language to make the concepts concrete. I think that it's stretching the scope of the article, and therefore watering down its message, to put any additional focus on specific features of the python language.

I guess this is an example of my earlier point: I knew about map and reduce, and understood their power. However, it had not clicked for me before reading this article that they feature so prominently in functional programming because they work with functions that have no side effects.

I thought leaving out list comprehensions was an excellent idea - it is a construct that few programmers from other languages would understand, and would have caused parts of the article to turn into a python tutorial. As it is, the python is close enough to universal pseudo-code.

If I was going to claim it was perverse I would say it is a little perverse to teach FP concepts in a language that doesn't support tail call optimisation. Eventually someone who tries to apply this rigorously is going to get an unpleasant surprise in Python. But since it is more about explaining principles than language details I would give it a pass on that anyway.

> But practically, who's the audience for that?

Anybody that would benefit from re-using some of the lessons from functional programming such as side-effect free programming, splitting pure and stateful code and so on (though some of the examples could do this better than they do now it is a step in the right direction).

Python, PHP, Java, Ruby and C programmers could learn quite a bit from this.

It's a well-written and nice article, but just kinda weird in spots, saying that the code is more self-evident and readable, whereas I think it's sometimes making a language do something it only does with considerable strain.

Insofar as python is essentially pseudocode, I can get the appeal of writing non-pythonic python, but ... it strains it a bit to do this for such extensive use of lambda, the most awkward bit of syntax in python, one that almost always has more readable alternatives.

Any time I see a use for lambda (typically only with the functional builtins), I just write a function instead. Two extra lines are worth it for the readability alone. You can also reuse a function, which makes more sense to me than potentially writing the same lambda multiple times.

I do like that the author used Python, even if it was only for the purpose of pseudocode. Python is, after all, "executable pseudocode". It's also the only language I really know in-depth.

Interestingly, at least at the places I've worked at recently, that functional "style" or kernel of truth is being picked up by more and more PHP programmers. It's great, makes it far easier to test code.

I can see the value in not using Python's comprehensions because although they provide an easy way to write map and filter, there's no clean, consistent way of expressing fold (or reduce or whatever you want to call it) - at least, not without altering state, which flies in the face of what this tutorial is trying to teach. Since those are the big three, I can see the value of writing everything with lambdas in the tutorial just to keep things consistent.

That said, I agree that it would have been helpful to at least give a mention to list/generator comprehensions.

This would show that with proper language support FP could be much more pleasant. Who would want to try and apply ideas from this worderful article to, say, her everyday C++ coding? After seeing something like squares=[x*x for x in range(10)] she would write exactly WHAT in C++?

JS would probably have been a better language for a few reasons:

- braces denote function bodies, even if you don't code it's pretty obvious.

- no strange difference between lambda and def, a function is a function

Because the purpose is to demonstrate the use of functions. * comprehensions are syntactic sugar above them and would hide their true nature.