It looks interesting, but complex. Thanks.

Its not really that complex actually, its just a very different syntax than you're used to using in common programming languages (assuming you're using the SQL-like query syntax, rather than the extension method syntax.) You'll also have to get your head around the concept of defered/partial execution, which is one of the keys to using it efficiently. Most common stuff you can achieve through the query syntax, but do be aware that some features are only available through the extension method syntax. Also, where the option is available, use methods defined on the class, rather than linq methods, because they are almost certainly more efficient (eg on List, use the Count property, rather than Linq's Count() method.) This is analogous in C++ to using class methods on STL containers, rather than the general algorithms, when the option is available.

It doesn't go to increadible depth, but "Hooked on Linq" is a small website that has a good amount of beginner-friendly content. Just Google it.


Happy Linqing! Its a very powerful tool for a lot of things, especially when combined with Lambas and expression trees (which are part of the linq package also). At work I've written a parser which takes a bespoke query language, builds an expression tree that represents the query, and then passes that off to linq to get the results. Along the way, due to the use of Linq and the expression tree, type safety gets enforced. Before, when the querry language was translated directly to SQL, injection attacks were a real possibility, but the linq method alleviated a lot of that risk.

101 linq examples

Personally I'm not sold on linq. Some of the generic extensions are nice to have, and expression trees are really nice to have. The whole 'common syntax for arbitrary data sources' isn't really there practically, and the syntax is just off from sql enough to be really awkward when doing anything more complex than filtering. I'd personally prefer just Haskell list comprehension syntax for that. And I'll usually just do procedural code in the real world. Easier to read, easier to maintain, easier to debug.

(re: expression trees: I actually just used them in 4.0 to auto-discover properties and do a magical ajaxy databound sortable pagable grid with just a Func<IEnumerable<Dynamic>>. Not that it's practical but damned cool.)

Quote:Original post by Telastyn
101 linq examples

Personally I'm not sold on linq. Some of the generic extensions are nice to have, and expression trees are really nice to have. The whole 'common syntax for arbitrary data sources' isn't really there practically, and the syntax is just off from sql enough to be really awkward when doing anything more complex than filtering. I'd personally prefer just Haskell list comprehension syntax for that. And I'll usually just do procedural code in the real world. Easier to read, easier to maintain, easier to debug.

(re: expression trees: I actually just used them in 4.0 to auto-discover properties and do a magical ajaxy databound sortable pagable grid with just a Func<IEnumerable<Dynamic>>. Not that it's practical but damned cool.)

i guess then you haven't yet noticed how linq works really for everything.

by now my apps have nearly no loops anymore. linq just replaces all sort of filterings, searches, etc. code footprint reduced to about half it's size.

code gets down to stuff like

public void Update(TimeSpan dt){    (from o in World.Objects where o.IsActive select o).Each(o => o.Update(dt));}

(from brain, not 100% sure).

all in all, linq massively streamlines and reduces the amount of code, and linq is "the same everywhere" indeed. i just started with linq-to-xml, which is obviously a bit different, still works quite similar. linq to sql was the start for me, but linq to anything was the wow effect, the reason i fell in love with it.

it looks cryptic at first, but it's not that hard.

and the common extensions are awesome indeed.

one thing that took me a while was to understand the delayed execution. i "got it" right from the start. but sometimes, you don't realize what it really means until some strange bugs appear :)

Terse code is not better code.

Further, for anything beyond linq on collections (and half the time there) the performance is atrocious.

to each it's own. but once you "get" link, you notice how much manual coding is nothing more than query/apply everywhere.

and at this point, you see how much useless time you spent on making a loop with some complex if/else/then blabla in working right, which would have been done with a query much faster.

you talk about performance? i talk about "i optimize for performance WHEN PERFORMANCE IS A PROBLEM".

in short: you said you "don't understand the use of linq yet", and then i show you one, and you say "i can't see this use". which fits your original statement :)

i understand linq and can apply it thus to the situations where it is the most easy and most versatile (at the same time) way to solve an issue. interestingly, this is at VERY MUCH places.

performance? nobody cares about that.

Quote:Original post by davepermen
to each it's own. but once you "get" link, you notice how much manual coding is nothing more than query/apply everywhere.

No, I'm clearly aware how many problems can be simplified to map/reduce or query/apply.

Quote:
and at this point, you see how much useless time you spent on making a loop with some complex if/else/then blabla in working right, which would have been done with a query much faster.

Sorry,

foreach( GameObject entry in World.Objects ){    if( entry.IsActive ){        entry.Update(delta);    }}

is dead simple. Way more simple than linq syntax. Way easier to read. Way easier to debug. Way easier to refactor/maintain. And I know it's right.

Quote:
you talk about performance? i talk about "i optimize for performance WHEN PERFORMANCE IS A PROBLEM".

That's all well and good, but the performance problems are inherent to linq. The only way to refactor them out is to ditch linq-to-bleh. Switch to ADO or Entity Framework or XPATH or other technologies that provide the same sort of access. The sort of decision that needs to be made at design/technology time.

Quote:
in short: you said you "don't understand the use of linq yet", and then i show you one, and you say "i can't see this use". which fits your original statement :)

I did not say that. I said I was not sold on it. ie: I am not convinced that it is a useful, viable feature; something that will be a 'need to have' for later languages.

I don't think the brevity gained is an advantage usually. The performance and readability isn't too bad for your example, but as soon as you get into any more complex chaining or definitely if you get into any join behavior... you'd be better off using plain old procedural code.

Quote:
performance? nobody cares about that.

Normally I'd agree with you. Performance is the last thing to concern yourself with. But the common places linq is used are the places your program will already be slow: data access, filtering, iteration. And as I said before, it's not something you can just optimize later.

mine is a simple one liner, and flexible to be able to handle much more complex tasks in the 5 lines you had to write.

and believe me, once my linq query is 5 lines of filtering and searching, it gets to 20-40 lines of code in your loop, tons of if/else and you have to manually have all that code under control to be always in a valid workflow for all cases.

i don't.

linq reduces the amount of manual iterative processing of data, and thus, too, the amount of chances to make errors by it.

in this trivial example, chance of error is so low that it won't happen.

but once it gets just a bit bigger, it can get hard. and there linq helps in clarity, ease to read (for me much easier to read by now than your piece of code), and lower chance of errors (as the code explains the result, not the way to the result. that is done by the compiler, which, unlike humans, does not make logical errors).

oh, and btw, my code can simply be parallelised at will. can yours? with just one tiny statement?



about performance: well, linq isn't that bad. and you can precompute important in-loop ones if needed to get the speed up (but you knew that i guess).

since moving to linq, and seeing where i can apply it (about anywhere in the codes i write), i reduced the amount of code, am much faster at writing topic-specific fitting solving code, and have much less work at debugging.

so in short, it delivers all that you deny.

you just aren't that fluent at reading it. i am, for me it's natural. more natural by now than loops. (still scared by that thought :))

Quote:Original post by jpetrie
Iand just because you can use LINQ extension methods to refactor a simple loop into a single line doesn't mean that improves the quality of the code; sometimes it does, sometimes it doesn't. Like all tools it has to be applied carefully and in the correct situations.

it reduces the chance to make stupid errors.