Marius Gheorghe

Building software : make it work, make it good, make it fast

Linq to objects is a misnomer

Linq to objects is a misnomer. Linq to IEnumerable(of T) would be better. The idea is that, when you're writing Linq code, it should be VERY VERY easy to "grok" against what "data source" the query it's going to run.
Here's a simple example :

from s in File.RealAllLines("blah.txt")

should be written as

string[] lines = File.ReadAllLines("blah.txt");
var f = from s in lines

In the second case it should be clear that you reading all the contents of that file in memory and the query is running "against" a string[].

LINQ query expressions differences

Much to my surprise, once i started digging, it seems that the difference between the C# and VB.NET implementation of query expressions are quite big. Case in point : C# doesn't support the "distinct" clause and VB.NET does.
Also the compiler is quite "strict" when you're using expressions :
var g = from w in words where w.Length > 5 .Distinct() select w; This seems a valid query (especially when you "map" logically query expressions to SQL) except it won't compile. It will crap out with a totally uninformative and wrong error message. On the other hand, this will compile and run just fine :
var g = from w in words .Distinct() where w.Length > 5 select w; The point i'm trying to make is that it seems to be "easier" to write code using query operators directly instead of query expressions. The code will be longer but when you read it you won't have to switch back and forth mentally from different query expression implementations :
var g = words.Distinct().Where((string w) => w.Length > 5);