I enjoy LINQ, but the real power comes from when the implementation is more complex than just renaming your standard functional programming map, fold, filter, e

I enjoy LINQ, but the real power comes from when the implementation is more complex than just renaming your standard functional programming map, fold, filter, etc functions to more SQL-y aliases. With that power comes the responsibility to actually understand what it is that you are doing, and where the abstraction leaks. If you are not careful, and do not understand the ramifications of what you are writing, it is very possible to write some horrifically inefficient code, or code that looks correct, but will break at runtime. I have seen many a horror with Entity Framework or Linq-to-SQL when I dug in to fix badly performing code, and hooked up tracing to track the SQL code that is actually generated and executed. Multiple iteration of an IEnumerable is very easy to run into, although static analysis is getting good at flagging that with a warning. Trying to use an IEnumerable that hasn't been materialized from the expression tree into the actual data after the database connection or other resource has been disposed is another common gotcha. Understanding what operations can be translated by the expression tree engine is very important. In LINQ database ORMs, the way that foreign keys behave can vary wildly depending on how the query is written and on how the ORM happens to handle those accesses.