Is Linq For Mortals?
Mike Taulty has posted about Linq syntax, at the end, he shows a simple way to do joins and then aggregation between two collections. The code looks like this:
var a = products.Join(
sales,
p => p.Id,
s => s.ProductId,
(p,s) => new { Country=s.Country, Sales=s.Sales, Product=p.Name })
.GroupBy( p => new { p.Country, p.Product })
.Select( gp => new { gp.Key, TotalSales = gp.Sum(s => s.Sales) });
I am sorry, but I cant read this. I can't even understand what this is meant to do. Now, I am the first to admit that my knowledge of Linq is weak at best, but still... Assume that I have a bug in such a code, how do I debug it?
That is a much bigger concern to me, I am not worried about learning the new stuff, I am worried about what I need to do when they break. I have some experiance in debugging applications via Reflector, and that is not nice. Especially if the compiler is doing funky magic and you are left reading the IL.
Comments
@ayende re luke
a linq query analyzer with F5 simplicity to make the cycle similarly quick, seems feasible though - doesn't it? (real question, I'm probably forgetting something)
Not easily, no.
You would need to import all the referenced assemblies, etc.
It is possible, just not trivial.
Most so because often enough what would happen is the query won't run in memory but translated to some other form (SQL, XPath), which may cause wildly different results
@Ayende,
Perhaps one could do some IL munging to get the results set after each extension method call? I assume you are familiar with how LINQ syntactic sugar gets converted to a string of method calls?
Yes, I know how it is translated, it is just that this is getting scary.
IL Munging is not for the faint of heart, and getting it wrong can be very confusing.
I wonder what the debugger guys are working on now.
The IL munging only needs to be done once if it is done well.
Comment preview