Not really relevant in this context, as naming things isn't that big a deal. Lambdas are only needed for one-liners and they serve that purpose fine.

"As far as I know, Python, Ruby, and PHP all suffer from the fact that all functions are not first class."

Definitely false for Python, Ruby actually has multiple kinds of first-class functions (for better or for worse, I am assured that in practice it's not a problem), recently false for PHP (http://en.wikipedia.org/wiki/PHP#5.3_and_newer ), and to save time, also false for Perl, Lua, ${all functional languages} (pretty much by definition, there), and false for C# as of 3.0.

If you want to play "oh but the support is quirky", Javascript has its own quirks on the closure front:

    var i;
    var funcs = [];
    for (i = 0; i < 5; i++) {
        funcs.push(function () { alert(i) });
    }
    funcs[3]();

Mind you, that's only a quirk and I wouldn't crucify the language for it, it's arguably correct and sensible once you understand it. The again, Python's scoping is arguably correct and sensible once you understand it, too, but people don't cut it much slack for that.

(The answer is 5 by the way. Compare with Perl, which can actually close on a variable created inside a scope in the function, instead of having just one function-level scope like Javascript. Compare with Python, which does what Javascript does.)

We of course need to define what first-class is ... if it's the ability to have higher-order functions, than 2.0 fits. C# 3.0 only adds a light-weight syntax for anonymous delegates plus the really kick-ass ability to get a syntax tree of that method instead of the method's reference (on which Linq is based) ... and I really wish other languages add this capability (it was possible in Ruby 1.8.x, but it's not anymore in Ruby 2.0).

Python kicks ass in regard to first-class functions ... and it leverages that ability with decorators. People using other languages go through great pain to have AOP capabilities (for example), but in Python it only takes like 10 minutes to add a couple of utilities to do whatever you want.

The only frustration I have with it is the lack of multi-line anonymous blocks, but Python is so flexible you can add that using "with" block hacks, like described here ... http://billmill.org/multi_line_lambdas.html

Also, once you understand dynamic-scoping ... it's really not that big of a deal to deal with the situation described above. It's just different.

I like the lexical-scoping in Perl as it prevents all kinds of errors ... but in Python I have real exception-handling, and a kick-ass debugger console just by adding "import ipdb; ipdb.set_trace()" anywhere I want.

The first way, which I prefer, is to make the binding of i to its value inside the loop body, this way you get a nice fresh binding on each loop iteration, so if you iterate the loop 5 time you get 5 bindings.

The other way, which I loathe but is still an arguably "correct" way to do it, is to make one binding of i outside of the loop and then modify it on each loop iteration, so no matter how many iterations of the loop you have, there's only one binding.

As far as I'm concerned, the first implementation is obviously the better one because the instances where this benefits you come often while the instances where the second implementation benefits you is very rare and unidiomatic. I think the second implementation is used for better performance but that's a mistake.

I had this problem of perceptions when I switched from Common Lisp's Loop to Iterate. Loop, for all its many big shortcomings, had the decency of making a fresh binding on each new iteration, though IIRC the standard specifies that bindings can be established outside or inside the loop context. When I want to make a closure based on the value of an iterated variable with Iterate I have to do an explicit binding...

I'm not sure what makes this a "quirk" since this is exactly what closures should do: they maintain a reference to the variable from the enclosing scope. This is also the behavior of a fairly classical example of closures in scheme.