It could be because C and C++ make you realize the fundamentals of programming and how other languages work 'under their hoods'. And/or because most other languages actually have all of the fundamentals, but 'toned down'. For example, C# and Delegates (C's pointer to functions), Ref (pointers), and so on.
MeziLu
Actually, I would discourage the use of var and encourage creating a class up front. This forces you to design what you want up front, which not only makes designing easier, but more importantly, you can serialize the class (with its groups, lists, etc) to an xml file and review it to make sure you are getting what you want. Var, IMHO, is a terrible way to go, especially for long term maintenance should something unexpected pop up. Serializing a class is extremely useful, especially for groupings, joins, and select many, etc. The tree view like structure in a serialized xml file is incredible to look at for complicated solutions. Guess another thing I am saying is that using var promotes backwards design. Create the Linq and hope for the best vs know what you want and design Linq to get you there, using serialization to test. Further, having the class greatly improves readability, a concern some have expressed. It’s a lot easier to know what Linq is doing if you can see what it produces. Regarding speed: I use PLinq for Next Generation Sequencing of the human genome. Six billion data points. It is plenty fast. Same goes for my CODIS search engine. CODIS is what you see on crime lab TV shows: here is the DNA profile from a crime scene. Are there any matches? PLinq was a godsend for that complicated process and is literally a million fold faster than Sql. Example: a 47 minute Sql search was 18 seconds for PLinq.
MeziLu
One final quick comment: There are actually two different approaches to Linq: extension methods and lambda-like. I totally agree with you about the latter. I can’t follow or understand that to save my life and lever use that approach. I avoid the lambda-like approach like the plague. Extension methods are dreams come true, but that might be because I write a lot of extension methods myself.
MeziLu
Wow, I must be wired differently. Readability is one of the things I like most about Linq. I place each operation on its own line and it’s like this “outline” or flow diagram that I and my colleagues can instantly understand. Anyway, good chatting with you but I need to take care of some urgent things now
MeziLu
One other point about parallel processing: When I do that, I always actually check the speed by setting a stopwatch to make sure I am getting a faster speed. Some times it is actually slower, but for the kinds of things I do, it is most often a lot faster. Just a word of advice to not assume speed boosts. Overall, without parallel processing, I find that Linq is blisteringly fast.
MeziLu
Thank you for your comment. I meant it as part of the entire package, not as a singled out feature to make the point that you need to consider Linq in its entirety, not this feature or that feature.
MeziLu
I actually love Linq. I find just the opposite. After you learn it well, it is very powerful and very fast. I once wrote an in-house version of the FBI’s CODIS search engine that requires very complicated operations and millions of them because you are searching huge genetic identity (DNA) databases. Linq handles them very well. Plus, because you can split operations between cores\processors, it is very fast. Linq is my go to solution for lots of scientific software. I especially like it’s Join and GroupBy. I do a lot of Sql. The way I do it now is that I developed a very fast transfer From Sql to a list of classes and then do Linq operations on the list. Extremely fast and more powerful than using Sql operations. Certainly a lot easier than Sql. So, I have to respectfully disagree with the common bashing in these posts and recommend investigating how Linq works to its fullest and suggest that you will change your minds.
MeziLu