Lambda's are so cool, I gotta wear shades

I have to admit, I got rather giddy when I heard that C# was going to support lambda expressions. Part of the .NET community didn't share my feelings and felt that C# was being overloaded with syntactic sugar. Some of them didn't even spell lambda correct. I'll forgive that one though :). I'll only make three points, since there is no point in making this blog entry several pages long.

1. Look at lambda calculus (yes, my favorite pass time before I thought that being a junior Oracle developer was way cooler than being a doctoral student): http://en.wikipedia.org/wiki/Lambda_calculus and tell me again that it's only syntactic sugar. Alonzo Church, a true math genius, developed it as part of an investigation into the foundation of mathematics. It is also capable of expressing any algorithm. Syntactic sugar? C# is more like syntactic sugar than that lambda's are like syntactic sugar.
2. Lambda's have an expression tree representation. That means you can build them dynamically. And they are also great as key selectors. For instance x=>x.MyProp selects the value of MyProp. However, you can also easily extract the fact that x has a property called MyProp. And at compile time, this is checked. That's nice, because it allows me to avoid the old "referring to properties by their name through a string" problem. If the property is renamed, you have to make sure you also change all the places where you referred to the property as a string. For instance, in the Entity Framework the include statement requires you to refer to a property path as a string. That's rather annoying because it becomes one of the few spots that the compiler doesn't help you track down problems when you change your model. By using the lambda expressions to generate a property path, the compiler will help you. One issue left is when you go through a collection in the include statement (for instance Prop1.Collection.Prop2), but composition helps you out there (although it might not be the most elegant solution). I'll blog more about my adventures with the Entity Framework, but lambda's have helped me create a 100% compile time checked business logic layer using the Entity Framework. That makes it easy to change things quickly (like a couple of hours for a major refactoring) without breaking things (0 issues caused by the refactoring out of the gate).
3. Recently got to explain the following code I wrote to some people:

protected static Func<T,V,W> Partial<V,W>(U eventArg, Func<T,U,V,W> aFunc) { return (target, context) => aFunc(target, eventArg, context); }

What it does is take a function that has three arguments of types T,U and V and a result type of W. Then it applies the argument of type U and it results in function with only two arguments (of types T and V) and a result of type W. Why would you want to perform a partial function application like this? Lets say aFunc is a general validation function that takes some configuration information (for instance what property to validate and what the maximum allowed value is for that property). The partial application passes the configuration information in and hides that from the outside world. The outside world now only sees a function with two arguments. Works kind of like a private field. The fun part is that the Partial method can actually also be written as a lambda expression. Note that the parameter types of target and contex are being inferred. Try that with an anonymous delegate. See http://blogs.msdn.com/ericlippert/archive/2009/06/25/mmm-curry.aspx for a rather lengthy blog entry on this.

A helpful bog can be found here http://blogs.msdn.com/ericlippert/archive/tags/Lambda+Expressions/default.aspx .