This is a very unpopular opinion among .NET advocates, but personally I think LINQ is the worst thing to ever happen to c#.
It leads to (in my opinion) grotesque, unreadable code that more often than not hides enormous performance problems. It offers so much expressiveness, seemingly so innocent of its cost, that it gets massively overused and abused.
As with all things in languages, one can argue "use it right", "don't work with bad programmers", etc, but I have found this to be a universal issue across a number of shops that I've been brought into: If the project uses LINQ to any degree, enormous performance problems almost always come along for the ride.
Often this simply doesn't matter, hardware or low utility masking the problem. But when it becomes a problem, and it is endemic across the solution, it requires major reworking.
Linq is an opportunity to write slow code very quickly. Of course when you have to spell out a 1-line Linq expression as a 50 line method, you'll notice that you wrote a triple nested loop and avoid it. But the point is this: the longer code is MUCH harder to comprehend than a concise Linq query, and the developer that didn't see that their Linq query was going to be slow wouldn't have reacted on that the expanded version also looked slow. The single line query can be more easily refactored as it can be comprehended.
So I say write slow code so you can find what's slow early on. The problem is likely to be in the architecture and data structures rather than in the processing code. If Linq gives an opportunity to deliver a working example quickly, and that example shows that for large N the perf is horrible, then Linq was extremely useful! Change some collection type, demoralize something, add some caching etc. and then slightly adjust the Linq query to suite. Large query methods are inertia to such changes so when they DO become necessary it's a larger effort.
Note that I mean Linq to objs now not Linq to Sql or some other provider.
Absolutely agree. I can't count the number of times I've seen some horrendous LINQ thing when a simple for loop would have sufficed, would have been easier to understand, and would have been far quicker.
It leads to (in my opinion) grotesque, unreadable code that more often than not hides enormous performance problems. It offers so much expressiveness, seemingly so innocent of its cost, that it gets massively overused and abused.
As with all things in languages, one can argue "use it right", "don't work with bad programmers", etc, but I have found this to be a universal issue across a number of shops that I've been brought into: If the project uses LINQ to any degree, enormous performance problems almost always come along for the ride.
Often this simply doesn't matter, hardware or low utility masking the problem. But when it becomes a problem, and it is endemic across the solution, it requires major reworking.