I'm having a discussion with a co-worker on Linq, I'll copy here:Co-Worker: Lets be honest here. Linq  syntax sucks. It's confusing and  non-intuitive. Me: oh come on, more  confusing than T-SQL? Co-Worker: uh,  yes. Me: it has the same basic  parts, select, where, and from Co-Worker: Linq, to me, is a  bastardization of relational + OO.  Co-Worker: Don't get me wrong - it's  incredibly powerful, but they  repurposed SQL to use agains object  collections.I'm of the opinion that using Linq + Lamda's is very powerful (he agrees), and also makes code easier to read (he disagrees on that point):pickFiles = from f in pickFolder.GetFiles(*.txt)where ValidAuditFileName.IsMatch(f.Name)select f;orvar existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>()where s.FileName == f.FullName && s.DocumentType != Unknownselect s;or (VB code here)   Dim notVerified = From image In images.AsParallel     Group Join verifyFile In verifyFolder.GetFiles(*.vfy).AsParallel.Where(      Function(v) v.Length > 0      ).AsParallel   On image.Name.Replace(image.Extension, .vfy) Equals verifyFile.Name     Into verifyList = Group    From verify In verifyList.DefaultIfEmpty    Where verify Is Nothing    Select verifyTo me this is clean and easy (at least easier than the alternatives) to read, what are your opinions on it?
Does the usage of LINQ and Lambda Expressions lead to less readable code?
coding style;linq;lambda
I can't find the right post anymore, but Eric Lippert (and possibly several other softies) have opined on several occasions about how Linq is declarative, which, for several classes of problems, is far more intuitive than imperative syntax.Linq enables you to write code that expresses the intent, not the mechanism.You tell me which is easier to read.  This:IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source){    List<Customer> results = new List<Customer>();    foreach (Customer c in source)    {        if (c.FirstName == Aaron)        {            results.Add(c);        }    }    results.Sort(new LastNameComparer());    return results;}class LastNameComparer : IComparer<Customer>{    public int Compare(Customer a, Customer b)    {        return x.LastName.CompareTo(b.LastName);    }}Or this?IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source){    return from c in source           where c.FirstName == Aaron           orderby c.LastName           select c;}Or even this?IEnumerable<Customer> GetVipCustomers(IEnumerable<Customer> source){    return source.Where(c => c.FirstName == Aaron).OrderBy(c => c.LastName);}The first example is just a bunch of pointless boilerplate in order to obtain the simplest of results.  Anybody who thinks that it is more readable than the Linq versions needs to have his head examined.  Not only that, but the first one wastes memory.  You can't even write it using yield return because of the sorting.Your coworker can say what he wants; personally, I think Linq has improved my code readability immeasurably.There's nothing relational about Linq either.  It may have some superficial similarities to SQL but it does not attempt in any shape or form to implement relational calculus.  It's just a bunch of extensions that make it easier to query and project sequences.  Query does not mean relational, and there are in fact several non-relational databases that use SQL-like syntax.  Linq is purely object-oriented, it just happens to work with relational databases through frameworks such as Linq to SQL because of some expression tree voodoo and clever design from the C# team, making anonymous functions implicitly convertible to expression trees.