code name

Till two years ago, I didn’t know that C# 2.0 had closures (reference to Joe Walnes’ blog). Now declarative programming is slowly coming into fashion.
Reference taken from classicist. The latter has a bunch of short bliki-articles, all worth reading.

Please note variables visibility scope:

public List<Employee> HighPaid(List<Employee> emps) {

int threshold = 150;
return emps.FindAll(delegate(Employee e) {
return e.Salary > threshold;
});

}

interesting quotation about arguments against closures in Java – about memory allocation. Found again by Martin Fowler’s reference, in Guy Steele’s archive:
One of the early design principles of Java was that heap allocation occurs if and only if a construct involving the "new" keyword is executed. Adding full-blown closures violated this design principle. (Dynamic class loading also violated the principle, but users seemed to be comfortable with that, perhaps because they believed that "once the computation got going" no more heap allocation would occur.)
Other features for Java release 1.5 will perform certain kinds of autoboxing, which also violates the design principle. This fact will make it easier to argue for restoring full-blown support for closures in the future.

upd: But .NET doesn’t have an unordered container (set), and these cool Find()/FindAll() don’t exist in IList. Too bad.

Oh yes, and Python always had closures.