LINQ is not the solution to everything | The Coffeehouse

TommyCarlier
I want my scalps!

On the web, I often see people using LINQ in situations where it's totally unnecessary, often not performing very well and/or less readable than the non-LINQ version. Give people a hammer, and everything starts looking like a nail. It's not a sin to sometimes use a loop or an if-statement, you know.

Ray7

Might be something to do with the functional programming frenzy we're all caught up in at the moment.

PaoloM
Hypermediocrity

Yes it is Smiley

Maddus Mattus
Do, or do not. There is no try. - Yoda

LINQ?

What are you babbeling about?

.Net 1.0 RULES!

TommyCarlier
I want my scalps!

I see a lot of code that uses LINQ to objects, where the query is immediately followed by a foreach-loop on it! You're not telling me that this code:

var q =
  from item in collection
  where item.Property == something
  select item

foreach(var item in q)
   item.DoSomething();

Is better than this code:

foreach(var item in collection)
  if (item.Property == something)
    item.DoSomething();

Maddus Mattus
Do, or do not. There is no try. - Yoda

In reply to TommyCarlier

#Sep 17th @ 11:19 PM

well,... that depends Smiley

I've learned over the vast years of my hugely succesfull career as a lackey software developer, that there is no one solution. There are thousands of solutions for the same problem. Especially in code.

So to state that this solution is wrong and that solution is right is a bit black and white. The preferred solution would be to write a single LINQ statement, but the other solution also works.

In the end the customer doesnt give a horse's azz how h0rny your LINQ statement is, he just wants his software to work!

TommyCarlier
I want my scalps!

In reply to Maddus Mattus

#Sep 17th @ 11:18 PM

.NET 1.0 was okay, but pales when compared to .NET 2.0. I'm not against progress, I use a lot of C# 3 features myself and I like it, but that doesn't mean I have to use every new feature. Extension methods, lambda expressions and var are a blessing and have made my code more readable. And LINQ surely has its uses, but you should not replace every loop or if-statement with a query.

ManipUni
Proving QQ for 5 years!

Linq solution to nothing - fixed.

Just UGLY syntax.

Dr Herbie
Horses for courses

In reply to ManipUni

#Sep 17th @ 11:35 PM

I find that answers on stackoverflow are particularly bad for this. Which is doubly annoying as we're still on .NET2.0 here ...

Herbie

joechung

In reply to TommyCarlier

#Sep 17th @ 11:19 PM

For simple queries, it may be overkill, but for complex queries, it's a godsend. Take grouping, joining, and sorting for example.

var q =

from item in collection

group item by item.Property into prop

select prop;

var q =

from item in collection

join other in otherCollection on item.Property equals other.Property

select new { item, other };

var q =

from item in collection

orderby item.Property, item.Name

select item;

The beauty of LINQ is that you can compose all these operations, plus projection and filtering, into simple queries, rather than blocks upon blocks of increasingly inscrutable code.

Also, LINQ is built so that it doesn't have to filter the query in your C# code but can formulate queries in SQL or another entirely different query language (e.g., CAML for LINQ to SharePoint queries) if an appropriate IQueryProvider implementation is available. LINQ to SQL queries are processed in SQL Server rather than on your box, potentially resulting in more efficient data processing.

Lest I appear overly enthusiastic, a couple warnings: be careful not to go overboard, just like with SQL, and using LINQ doesn't excuse you from becoming familiar, if not expert, with the target query language. Query optimization is still an exercise left to the reader.

TommyCarlier
I want my scalps!

In reply to joechung

#Sep 18th @ 1:08 AM

You're absolutely right. LINQ is great in a lot of scenarios. But it's silly to use it in every situation you can use it.

exoteric
I : Next<I>

In reply to TommyCarlier

#Sep 18th @ 1:17 AM

In the example you provide it does look silly. That being said, LINQ offers a functional style of programming that has code-readability benefits and sometimes performance benefits (also, PLINQ). I have found myself resorting to Enumerable.Range to turn a for into a foreach from time to time as well.

Right now, I like to use CPS as a control-flow mechanism. It too has this nice feel that once you do it, there is an itch to see how far you can take it (while remaining reasonably pragmatic).

Reactive LINQ will likely take over from there.

But true, C# is not an extremist language such as Haskell. It caters to a different audience.

Dodo
I'm your creativity creator™ :)

In reply to TommyCarlier

#Sep 17th @ 11:19 PM

Hm... well, if the compiler was smart enough, it wouldn't even matter. The first one would definitely compile a little bit slower, that's for sure. It would also execute slower, if the compiler doesn't optimize it (I doubt it does). A single one of those wouldn't make a noticable difference on a modern computer, though. Multiple of them might add up, but who knows how many you need for a one second lag. Smiley

If there are no performance implications, I would use the piece of code that is easier to understand and read, or the one that better fits on the screen, whichever is more important right then.

contextfree

In reply to TommyCarlier

#Sep 17th @ 11:19 PM

I might write your example as

foreach(var item in collection.Where(x => x.Property == something)) {
  item.DoSomething();
}

depending on whether I thought it was more naturally viewed as a "filtered collection" or as conditional execution.

Sven Groot
My name has 9 letters. Coincidence? I think not...

return from p in problems
       where p.Solution == "linq"
       select p;

wkempf

In reply to TommyCarlier

#Sep 17th @ 11:19 PM

foreach (var item in collection.Where(i => i.Property == something))
    item.DoSomething();

How's that? Still using LINQ, and I'd argue it's no worse/better than your imperative version.

Really, this is not overly important. You're ranting about a syntactic preference, really. Kinda like where you should put your opening brace.

wkempf

In reply to contextfree

#Sep 18th @ 11:11 AM

Should have read the whole thread. contextfree posted nearly the same thing I did. I just don't get the rant.

staceyw
Before C# there was darkness...

In reply to PaoloM

#Sep 17th @ 11:06 PM

"Yes it is"

You beat me to it. First thing that popped into my head Smiley

Minh
WOOH! WOOH!

Is it 42? Smiley

TommyCarlier
I want my scalps!

In reply to wkempf

#Sep 18th @ 1:06 PM

It's not about syntactic preference. It's about people who think like this:

Wow, LINQ is so cool! Let's see where we can use it? Hey, that if-statement doesn't look very LINQ-y, let's replace it with a call to the “Where” extension method, passing it a lambda-expression for the condition. Queries are so much cooler!

PaoloM
Hypermediocrity

In reply to TommyCarlier

#Sep 19th @ 7:28 AM

I'd like you to stop peeking into my brain, thankyouverymuch.

Smiley

TommyCarlier
I want my scalps!

In reply to PaoloM

#Sep 19th @ 9:43 AM

If you want me to stop peeking into your brain, you should wear your tin foil hat, 24/7. The only problem I have is that you think in Italian, and I don't know Italian. Yet. So you're pretty safe. For now.

Dodo
I'm your creativity creator™ :)

In reply to TommyCarlier

#Sep 19th @ 10:18 AM

Or remove that neural impulse actuator... Smiley

Oh, wait, I don't need one, maybe I'm not the only one with a brain with high electromagnetic sensitivity.

contextfree

In reply to TommyCarlier

#Sep 19th @ 7:28 AM

Maybe it's that if you've spent time coding in Haskell, you tend to think of it as

sequence_ (map action (filter pred xs))

vs.

sequence_ (map (\x -> if pred x then action x else return ()) xs)

and I think you'll agree that the former is much cleaner Tongue Out

TommyCarlier
I want my scalps!

In reply to contextfree

#Sep 19th @ 10:53 AM

I also sometimes write code in a functional style, but only when it's appropriate. An example: I've written extension methods for strings and collections of strings (IEnumerable<string>) to make it easier to manipulate strings like this:

string s =
  input
    .LazySplit(',', ';') // string -> IEnumerable<string>
    .Trim()              // IEnumerable<string> -> IEnumerable<string>
    .SkipEmpty()         // IEnumerable<string> -> IEnumerable<string>
    .Join(", ");         // IEnumerable<string> -> string