Lambda Expressions (C# Programming Guide)

I've been developing for almost twenty years from now. $0This is not the first time I see such contradictory opinions about some (relatively) new concept and/or technology.$0 $0I said "relatively", which is clear to those who visited research.microsoft.com, haskel.org, for those who met Knuth, Church and Turing.$0 $0$0 $0 $0Eternal questions include, as usual, on the first sight contradictory concepts; security vs productivity, readability vs effectiveness, and so on, and so on.$0 $0$0 $0 $0It is quite human to defy changes and progress, though.$0 $0$0 $0 $0However, with LINQ, you have a choice of not using it. Simply, don't.$0 $0$0 $0 $0The best programming language and/or concept is the one you are most productive with.$0 $0Stick with it, share your results, and give your best to human kind.$0 $0$0 $0 $0Kind regards.$0 $0$0 $0

Every line of code I write is meant to be read by a human other than me.
I am not employed to write clever code. I am employed to write transparent, maintainable code for those that follow when I am gone.
Ultimately clever code is a false economy, and Lambdas sit right in that falsehood.

I'm a student, learning c# and I'm in awe of the power achievable with code that is amazingly stylish and brief.  Consider the example below.  This is something I did for an exercise.  The exercise was only supposed to be for us to use indexers to return a list of cars based on certain criteria.  My first, naive, attempt repeated the loop, test, return list code in each indexer property.  I recognised this repetitive pattern and my 2nd, slightly less naive attempt had the predicate and LINQ with the doSearch but with explicitly declared private static functions to provide the comparator for each indexer.  Those functions had to take a params [] object argument due to the indexers all having different numbers and  types of arguments.

Finally, as you can hopefully see, the final implementation is simple, quite easy to quickly understand and with the ability of lambdas to capture local variables, in this case, the arguments to the indexers, all the delegate needed as an argument was the car we are testing.  Doing something like this with a purely iterative approach is much much uglier IMHO.

public class Show_Room : LinkedList<Car>
    {
        private delegate bool Predicate(Car a);

        public List<Car> this[string make]
        {
            get
            {
                return doSearch(car => car.Make.ToLower() == make.ToLower());
            }
        }

        public List<Car> this[double price]
        {
            get
            {
                return doSearch(car => car.Price == price);
            }
        }

        public List<Car> this[DateTime year, string model]
        {
            get
            {
                return doSearch(car => car.Date_Made.Year == year.Year && car.Model.ToLower() == model.ToLower());
            }
        }

        public List<Car> this[double price, int qty]
        {
            get
            {
                return doSearch(car => car.Price == price && car.In_Stock == qty);
            }
        }

        private List<Car> doSearch(Predicate pred)
        {
            var results = from c in this
                           where pred(c)
                           orderby c.Price
                           select c;

            if (results.Count() == 0)
                throw new CarNotFoundException();

            return results.ToList();
        }
    }

Lambda expressions capture extra this pointer, if lambda use local variable and static variable or method, and delegate created from instance method in the same method as lambda expression.

using System;
internal static class Test{
    private static void Main(){
        try{
            Console.WriteLine("{0,10}: Start point",GC.GetTotalMemory(true));
            LambdaTest1 test1=new LambdaTest1();
            Console.WriteLine("{0,10}: LambdaTest1 created",GC.GetTotalMemory(true));
            Func<int> func1=test1.GetFunc();
            Console.WriteLine("{0,10}: LambdaTest1 GetFunc called",GC.GetTotalMemory(true));
            GC.KeepAlive(test1);
            test1=null;
            Console.WriteLine("{0,10}: LambdaTest1 removed, memory freed",GC.GetTotalMemory(true));
            GC.KeepAlive(func1);
            func1=null;
            Console.WriteLine("{0,10}: LambdaTest1 func removed",GC.GetTotalMemory(true));
            LambdaTest2 test2=new LambdaTest2();
            Console.WriteLine("{0,10}: LambdaTest2 created",GC.GetTotalMemory(true));
            Func<int> func2=test2.GetFunc();
            Console.WriteLine("{0,10}: LambdaTest2 GetFunc called",GC.GetTotalMemory(true));
            GC.KeepAlive(test2);
            test2=null;
            Console.WriteLine("{0,10}: LambdaTest2 removed, memory not freed",GC.GetTotalMemory(true));
            GC.KeepAlive(func2);
            func2=null;
            Console.WriteLine("{0,10}: LambdaTest2 func removed, memory freed",GC.GetTotalMemory(true));
        }catch(Exception e){
            Console.WriteLine(e);
        }
        Console.ReadKey(true);
    }
    private class LambdaTest1{
        private static int staticI=1;
        private byte[] data=new byte[100000000];
        private void Instance(){}
        internal Func<int> GetFunc(){
            int localI=2;
            //Action action=Instance;
            return ()=>localI+staticI;
        }
    }
    private class LambdaTest2{
        private static int staticI=1;
        private byte[] data=new byte[100000000];
        private void Instance(){}
        internal Func<int> GetFunc(){
            int localI=2;
            Action action=Instance;
            return ()=>localI+staticI;
        }
    }
}

Bottom line, the Lambda concept* is highly useful and well worth learning.  Arguing which language feature is better than another is like arguing which branch of math is best...  If you are trying to add up shopping list items you don't need Differential Calculus.  However, I would challenge any developer that thinks he/she doesn't need a particular feature to learn to use the feature fully first and then determine if it's applicable to the solution at hand.

Why Lambda?

Lambda Expressions can solve problems in varying ways.  One very limited example is this... You can utilize them to define logical parts and reuse them later.  If done well this can make the code that uses the defined expressions more readable...

Pretend this is contained in a library written by Lambda aware folks and provided to the front end team.

Func<string,string> safe = t => {
   if( String.IsNullOrWhitespace(t) ){
      return String.Empty;
   }else{
     return t;
  }
};

...and in our front side

Person person = new Person {
  FirstName = safe( recordSet["FirstName"]),
  LastName = safe( recordSet["LastName"]),
  ...
};

...instead of what I see commonly:

Person person = new Person();
person.FirstName = String.IsNullOrWhiteSpace(recordSet["FirstName"]) ? String.Empty : recordSet["FirstName"];
person.LastName = String.IsNullOrWhiteSpace(recordSet["FirstName"]) ? String.Empty : recordSet["FirstName"];

This is, admittedly, a bit of a silly example but it's a quick demonstration of how small, but repetitive logic could be cleaned up using a couple simple Lambda expression.  One side affect here is that if I every wanted to change the global default for an application I could in a single line instead of multiple places in the code.

*Lambda Expressions come from Lambda Calculus and were not invented by Microsoft just to confuse and fuddle developers who never learned more than simple imperative programming.

I feel, we have to pick one of the 2. Smarter Code Vs Maintainable Code.

with lambda expressions, code can become compact, that inturn can make things eazier. For example I remember I once did a very complicated Grouping using Aggregate<> and lambda expressions, and the code was only 1 line to maintain. This single line could eazily beocme a project in itself, giving more than 300 lines of C# code to maintain. Its always right tool for right work that we have to pick carefully.

KS

I don't use lambda expressions a lot in my code, but I have found them useful in very specific (and rare) cases.

Let's say that you have a varible ListOfWidgets defined as List<Widget> and you want to find a Widget with a specific WidgetId.  This is how I would use it.

public Widget GetWidget(int widgetId)
{
    return ListOfWidgets.Find(rec => rec.WidgetId == widgetId);
}

This is very simple and should be relatively easy to understand.  It was hard to get used to the syntax, but for simple cases like these the one line of code rather than a for loop with an if condition actually is quicker to write and it is still easy to understand (for me at least).

C# compiler generate code what capture extra local variables:

using System;
using System.Collections.Generic;
using System.Linq;
internal static class Test{
    private static Random random=new Random();
    private static void Main(){
        try{
            Func<IEnumerable<byte>>[] array=new Func<IEnumerable<byte>>[1024];
            for(int i=0;i<1024;++i){
                Func<IEnumerable<byte>> ab,bc,ca;
                F(out ab,out bc,out ca);
                array[i]=ab;
            }
            Console.WriteLine(GC.GetTotalMemory(true));
            GC.KeepAlive(array);
        }catch(Exception e){
            Console.WriteLine(e);
        }
        Console.ReadKey();
    }
    private static void F(out Func<IEnumerable<byte>> ab,out Func<IEnumerable<byte>> bc,out Func<IEnumerable<byte>> ca){
        byte[] a=new byte[1024];
        random.NextBytes(a);
        byte[] b=new byte[1024];
        random.NextBytes(b);
        byte[] c=new byte[1024*1024];
        random.NextBytes(c);
        ab=()=>a.Concat(b);
        bc=()=>b.Concat(c);
        ca=()=>c.Concat(a);
    }
}

C# compiler rewrite code like this:

using System;
using System.Collections.Generic;
using System.Linq;
internal static class Test{
    private static Random random=new Random();
    private static void Main(){
        try{
            Func<IEnumerable<byte>>[] array=new Func<IEnumerable<byte>>[1024];
            for(int i=0;i<1024;++i){
                Func<IEnumerable<byte>> ab,bc,ca;
                F(out ab,out bc,out ca);
                array[i]=ab;
            }
            Console.WriteLine(GC.GetTotalMemory(true));
            GC.KeepAlive(array);
        }catch(Exception e){
            Console.WriteLine(e);
        }
        Console.ReadKey();
    }
    private static void F(out Func<IEnumerable<byte>> ab,out Func<IEnumerable<byte>> bc,out Func<IEnumerable<byte>> ca){
        AnonymousClass1 anonymousClass1=new AnonymousClass1();
        anonymousClass1.a=new byte[1024];
        random.NextBytes(anonymousClass1.a);
        anonymousClass1.b=new byte[1024];
        random.NextBytes(anonymousClass1.b);
        anonymousClass1.c=new byte[1024*1024];
        random.NextBytes(anonymousClass1.c);
        ab=anonymousClass1.LambdaExpression1;
        bc=anonymousClass1.LambdaExpression2;
        ca=anonymousClass1.LambdaExpression3;
    }
    private sealed class AnonymousClass1{
        public byte[] a;
        public byte[] b;
        public byte[] c;
        public IEnumerable<byte> LambdaExpression1(){
            return a.Concat(b);
        }
        public IEnumerable<byte> LambdaExpression2(){
            return b.Concat(c);
        }
        public IEnumerable<byte> LambdaExpression3(){
            return c.Concat(a);
        }
    }
}

As you can see, "c" local variable was captured and preserved as part of AnonymousClass1 object, despite the fact that all delegates what use it are not preserved.
I am suggest to rewrite code like this:

using System;
using System.Collections.Generic;
using System.Linq;
namespace System{
    public class CapturableLocalVariable<T>{
        public T Value;
    }
}
internal static class Test{
    private static Random random=new Random();
    private static void Main(){
        try{
            Func<IEnumerable<byte>>[] array=new Func<IEnumerable<byte>>[1024];
            for(int i=0;i<1024;++i){
                Func<IEnumerable<byte>> ab,bc,ca;
                F(out ab,out bc,out ca);
                array[i]=ab;
            }
            Console.WriteLine(GC.GetTotalMemory(true));
            GC.KeepAlive(array);
        }catch(Exception e){
            Console.WriteLine(e);
        }
        Console.ReadKey();
    }
    private static void F(out Func<IEnumerable<byte>> ab,out Func<IEnumerable<byte>> bc,out Func<IEnumerable<byte>> ca){
        CapturableLocalVariable<byte[]> a=new CapturableLocalVariable<byte[]>();
        a.Value=new byte[1024];
        random.NextBytes(a.Value);
        CapturableLocalVariable<byte[]> b=new CapturableLocalVariable<byte[]>();
        b.Value=new byte[1024];
        random.NextBytes(b.Value);
        CapturableLocalVariable<byte[]> c=new CapturableLocalVariable<byte[]>();
        c.Value=new byte[1024];
        random.NextBytes(c.Value);
        ab=Tuple.Create(a,b).LambdaExpression1;
        bc=Tuple.Create(b,c).LambdaExpression2;
        ca=Tuple.Create(c,a).LambdaExpression3;
    }
    private static IEnumerable<byte> LambdaExpression1(this Tuple<CapturableLocalVariable<byte[]>,CapturableLocalVariable<byte[]>> context){
        return context.Item1.Value.Concat(context.Item2.Value);
    }
    private static IEnumerable<byte> LambdaExpression2(this Tuple<CapturableLocalVariable<byte[]>,CapturableLocalVariable<byte[]>> context){
        return context.Item1.Value.Concat(context.Item2.Value);
    }
    private static IEnumerable<byte> LambdaExpression3(this Tuple<CapturableLocalVariable<byte[]>,CapturableLocalVariable<byte[]>> context){
        return context.Item1.Value.Concat(context.Item2.Value);
    }
}

Now "c" local variable captured but not preserved (collected by garbage collector), as all delegate what use it not preserved in "Test.Main".

Lambda's are cool. Try something like this (untested):   $0List.RemoveAll(word => word != word.ToLower()); $0 VS  $0foreach (var item in List) if (item != item.ToLower()) List.Remove(item);$0 This quite clearly removes any word from the list where the word contains a capital letter.  *(Where List is replaced with suitable populated List<string>).

Tthe Lambda expression syntax is awkward. Though it is powerful, it is not easily understood by programmers other than the one who wrote it. It takes some time to get comfortable with the syntax.

By using lambda expression we make code more attractive as well as line of code is simple. So for developer point of view it is good to use lambda expression. Its a great feature introduce in .net. You will get a beginners article at this link
http://www.mindstick.com/Blog/181/Lambda%20Expression%20in%20c
This might be use ful.

OK Folks. As you might already know, it take two to tango. One of them is you, the other is Lambda.

Each one of us must individually decide whether to use it or not.

And I for one do not understand how a single line lambda expression is considered more readable than a simple while or for loop. May be in a couple of years both would mean the same to me but for now, I would stick on to the good 'ol 3 line forloop.

Very powerful, but very obscure.  Read through the above link for recursive lambda expressions.  Really?  REALLY??

By far, the greatest costs associated with software are in development and maintenance.  Do you really want that recursive lambda expression(s) for generating a simple factorial to be inserted in place of:

intfactorial(intn)
{
    if(n<=1)
        return1;
    else
        return  n*factorial(n-1);
}

Just because you can do something doesn't mean you should.  It reminds me of the old APL contest to see who could write the most obscure code for a specified function.  In the end, this will be wiped into "frameworks" or forgotten altogether.

To be fair to the nay-sayers, this kind of programming is not a good fit for application level code. So, if that is all you do, go ahead and ignore it.
This belongs in framework and reusable component development, the kind of stuff that is rarely touched once it is created and tested.

And yes. If your standard for understandability is conditionals and loops only, please ignore this kind of stuff. Better still, stick to VB Script. ;)

Those Lambda haters: Do you love regular expressions?

I don't know what's with all that hate in the thread. Just don't use them if you don't want to. We can hardly call them new, it's (partially) just sintax sugar for writing delegates. Same old delegates that are here since the very begining,  verbose, ugly and all that.

One example that I can think of is that they are very useful for Execute Around pattern that Kent Beck described back in '97. That alone would be enough ,but there is much more to it than just that.

Lambda expressions are a concept borrowed from functional programming. It's just another way of doing things but one aimed as making the code more concise and adding the benefit that you're describing what you want, rather than how. (This is where comparisons to SQL shed some light although it's a limited metaphor.)

E.g. given a list of strings that might contain duplicates when case sensitivity is ignored, find all duplicate values. A procedural approach isn't complicated but would mean writing the iteration code and building up the list of results. The lambda approach defines an expression to return these by specifying just the logical test, not the iteration.

This might be a trivial example but the benefit grows as the problem gets more intricate. If unconvinced then do check out Jon Skeet's C# In Depth (which is well worth the effort anyway).

Lambdas are, in my opinion, vital to making decent programs that handle much data, like lists. They need sorting, you might need to pick some members and move them to another list, etc. Plus, you really don't have to use them if you don't have to.

I personally find them a very good addition to the .NET languages.

... a solution to a problem that didn't exist.  A way to obfuscate tried and true, well-understood, efficient ways of writing code to access data.  Another layer of complexity we didn't need.  Microsoft rolls out something like this every 5 years or so, and has been doing so for the 25 years I've been a programmer.  Lamdas are like the Zune... when they came along, there was already a better way of doing things (the iPod).  Microsoft announced the death of the Zune today, and one can only hope the same announcement comes soon for Lambdas, LINQ, and everything associated with it. 

To the poster who wrote that as professionals, we need to learn new technology and adapt:  I agree.  But we also need the experience and wisdom to avoid jumping on every bandwagon that rolls through town.  Especially those with loose wheels and no sign of a competent driver.

What is all the hate about? If you are using LINQ to Objects than you have really no choice to use Lambda Expressions. MY ONLY PROBLEM WITH IT is that it is not much documentation on using it with LINQ.

Just asking....how does lambda expression give you greater code re-usability? I mean if I had a named function in a library I can use it over and over again. But a lambda expression can only be used where its defined as its inline (am I wrong?). So, if its a one time use expression, why even bother to make it a  Lambda? Why not spell out the expression logic within the body? $0$0 $0 $0So instead of saying (x) => x*x and then calling it separately, why not just have x*x directly as part of the code? $0 $0$0 $0 $0Sorry....I am new to .NET so I might be misstating.$0

The only bad part about language extenstions like these is that if a person encounters code that uses them and they are not up-to-speed on the extension, it can be difficult to understand the program flow.  The same can be said about any syntax.  If someone chooses to only use "if / else if / else", and not read up on "switch / case" statements, then they would not know how to interpret the code using a switch if it were encounterred in code that they did not write.  The functionality of a switch can be achieved using an if / else if / else statement, so why use it?  Possibly for the sake of readability or to reduce the amount of effort.  The same can be said of Lambda expressions.

I understand why many people find Lambdas confusing.  However, once you get the hang of them they are not at all difficult. 

They are very hand, too.  They let you create delegates with fewer lines of code, for one thing.  Fewer lines of code means fewer opportunities for mistakes and greater productivity.  They are also key to the LINQ technology, which, again, lets you do more with less effort.  In LINQ and elsewhere, Lambda expressions are a standard way to express almost any kind of query, without having to invent your own classes to do so.

If you want everything to be "simple" then go back to programming in C.   And forget about the .NET Framework because it's waaaay harder to master than C's good old standard libraries.  Throw out Windows and Web programming and go back to DOS, where you could always control what was going to happen next.

But if your goal is to be a true professional, then you must master the tools of your trade ... and stay up-to-date.  Doctors must keep up with the latest medical advances, auto mechanics must study up on the latest innovations from Detroit and Japan, and we programmers must put in the time to master the language innovations that will increase our productivity.  If you don't do it, there are plenty of people around the world who would love to take your place.

Besides, if you don't get pleasure out things like Lambdas, why are you even in this profession?  To me, they are elegant and fun.