Does the usage of LINQ and Lambda Expressions lead to less readable code? [closed]

Question

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;

or

var existing = from s in ActiveRecordLinq.AsQueryable<ScannedEntity>()
where s.FileName == f.FullName && s.DocumentType != "Unknown"
select 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 verify

To me this is clean and easy (at least easier than the alternatives) to read, what are your opinions on it?

Answer 1

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.

Answer 2

Co-Worker: Lets be honest here. Linq syntax sucks. It's confusing and non-intuitive.

You can't argue with that criticism. For your coworker, it sucks. We failed to design a syntax that, for them, was clear and intuitive. That's our failing, and you can pass on my apologies to your coworker. I am happy to take suggestions on how to make it better; what specifically does your coworker find confusing or unintuitive?

However, you can't please everyone. My personal opinion, and the opinion of most of the people I've talked to on the subject, is that the query comprehension syntax is much more clear than the equivalent imperative syntax. Clearly not everyone agrees, but fortunately we do not require consensus of all the millions of our customers when we do language design.

On the subject of what is "intuitive" though, I am reminded of the story of the English linguist who studied many different languages and finally concluded that English was the best of all languages because in English, the words come in the same order that you think them. Unlike French, where they're constantly saying things like "the dog white eats the meat red". How hard it must be for French people to think the words in the correct order and then have to say them in the French order! French is so unintuitive! It's amazing that the French manage to speak it. And German? where they think "the dog eats the meat" but then have to say "the dog the meat eats" !?! So unintuitive.

Often what is "intuitive" is merely a matter of familiarity. It took me months of working with LINQ before I stopped beginning my queries with the "select" clause. Now it is second nature, and the SQL order seems bizarre.

Which it is! The scoping rules are all messed up in SQL. Something you might want to point out to your coworker is that LINQ was carefully designed so that (1) introduction of variables and scopes happens left-to-right (*), and (2) the order that the query appears on the page is the order in which it is executed. That is, when you say

from c in customers where c.City == "London" select c.Name

the c appears in scope at the left, and stays in scope through the right. And the order in which things happen are: first "customers" is evaluated. Then the "where" is evaluated to filter the sequence. Then the filtered sequence is projected by the "select".

SQL doesn't have this property. If you say

SELECT Name FROM Customers WHERE City = 'London'

then "Name" is brought into scope by something to its right, not to its left, and the query is executed in a completely messed up order; the middle clause is evaluated first, then the last clause, and then the first clause. That now seems crazy and unintuitive to me, having worked solely with LINQ for so long now.

---

(*) Scoping rules are a bit weird in LINQ with join clauses. But other than that, scopes nest nicely.

Answer 3

Like anything else in the programming world, you gotta get used to the syntax, and then it is (potentially) easier to read.

Like anything else in the programming world, there is the potential for spaghetti code or other abuses.

Like anything else in the programming world, you can either do it this way or another way.

Like anything else in the programming world, your mileage may vary.

Answer 4

I saw a comment/remark where it stated something - in relation to LINQ/lambda - along the lines of: "Write code readable to humans, rather than readable to your computer".

I think that this statement has a lot of merit, however, consider the developer (such as myself) who has been through the full gamut of development languages from Assembly, through procedural, through OO, through managed, through leveraging high throughput task parallel solutions.

I have prided myself on making my code as readable and as reusable as possible and adopting many of the GOF design pattern principles in order to deliver production quality systems and services across a wide number of disparate business sectors.

The first time I encountered the lambda expression I thought: "What the hell is that!?!" It was immediately counter-intuitive to my familiar (and therefore comfortable) explicit declarative syntax. The younger < 5yrs in the job guys however lapped it up like it was manna from heaven!

That is because for years thinking like a computer (in the syntactic sense) translated very easily into direct coding syntax (irrespective of the language). When you have had that computational mindset for circa 20+yrs (30+ in my case) you have to appreciate that the initial syntactic shock of the lambda expression can easily translate into fear and mistrust.

Maybe the co-worker in the OP had come from a similar background as myself (i.e. been around the block a few times) and it was counter-intuitive to them at that time? My question is: what did you do about it? Did you try to re-educate your peer into understanding the benefits of the inline syntax, or did you pillory/ostracise them for not "being with the program"? The former would probably have seen your co-worker come round to your line of thinking, the latter would probably make them mistrust the LINQ/lambda syntax even more and thus exacerbating the negative opinion.

For myself I had to re-educate my own way of thinking (as Eric infers above, it's not an insignificant mind-shift, and I had to program in Miranda in the '80s so I've had my share of functional programming experience) but once I had gone through that pain the benefits were obvious but - more importantly - where its usage was over used (i.e. used for the sake of using it), over complex and repetitive (considering the DRY principle in that instance).

As someone who not only still writes a lot of code but who also has to technically review a lot of code it was imperative that I understood these principles so that I could review items impartially, advise where usage of a lambda expression may be more efficient/readable, and also to get developers to consider the readability of highly complex inline lambda expressions (where a method call would - in those cases - make the code more readable, maintainable and extensible).

So when someone says that they "Don't get lambda?" or LINQ syntax, rather than brand them a luddite try to help them understand the underlying principles. They may after all have an "old school" background such as myself.

Answer 5

Lambda Expressions leads to less readable code if queries are too long. However it's much better than too many nested loops.

It's better with a mixture of the two.

Write it in Lambda if it's faster (you need it to be fast) or easier to read.

Answer 6

I think it depends in most cases (except when doing something very bizarre) on if you mean "readable" as someone getting the idea of what is going on or if they can easily find all the tiny little details.

I think link helps with the former, but often (especially when debugging) hurts the latter.

IMHO when I am looking at code I am unfamiliar with the former is hugely more important than the latter, so I find it much more readable.

Answer 7

I agree with you that Linq syntax is not significantly different from T-SQL. I think your coworker might really be objecting to relational stuff getting mixed in which his nice and shiny OO code. On the other hand, functional programming takes a bit of getting used to, and a willingness to get used to it.

Answer 8

I find LINQ syntax intuitive and easy to read, especially since they put the FROM at the start where it belongs instead of in the middle like in SQL. But IMO lambdas are confusing and make the code harder to read.

Answer 9

It depends. Obviously, T-SQL uniquely provides some DB-relational solutions. Obviously LINQ uniquely provides some OO solutions.

However; "more confusing than T-SQL?" - is discussed/asked in the initial question. This clearly implies some features that none of the existing answers address, instead accusing the (obviously SQL-acquainted) criticizer of being stuck in the past.

So although I appreciate LINQ for certain qualities, and don't greatly disagree with the existing answers here, I feel the counterpoint deserves representation:

Years after becoming familiar with LINQ, performing certain types of group operations, outer joins and non-equijoins, working with composite keys, and other operations in LINQ still make me cringe. (Especially when targeting a relational back-end with performance-sensitive questions.)

from c in categories
join p in products on c equals p.Category into ps
from p in ps.DefaultIfEmpty()

If you think that's intuitive, more power to you. ;)

Answer 10

There is probably a reason why Linq sucks, just do try to make real world examples, instead of these textbook examples.

try to show this function in linqlamdathings and you will see, that all the beauty is gone, while the classic way remains readable. Not to mention deferred execution problems and setting breakpoints.

The truth is LinqLambdaThings are very useful in few cases and they are not thought to replace all the nifty object orientation that you guys never understood

    public IList<Customer> GetVipCustomers(IList<Customer> source, int maxCount)
    {
        var results = new SortedList<string,Customer>();

        foreach (Customer c in source)
        {
            if (maxCount == results.Count)
                break;

            if (c.IsVip && c.FirstName== "Aaron" || c.SecondName== "Aaron")
                results.Add(c.LastName, c);
        }

        return results.Values;
    }