...like everything else. I was browsing through a recent SQL Server Magazine with an editorial of sorts by Michael Otey, going through the benefits of 2008. He mentioned LINQ as a tool to enable C#, VB or C++ developers to use set-based operations against SQL Server. I thought there was already a tool to do that - ADO.NET. I mean no offense or object to Mr. Otey, its the wording that scares me, and it is wording that I hear often...
Now for me the jury is still out on LINQ (or PLINQ - I love that acronym). It could be a very useful tool for providing a consistent layer for developers to access databases, objects, etc. However, it is just a tool - LINQ in and of itself will *not* get developers who aren't familiar with/currently don't use set-based operations to do so. What about set-based logic? Will they write the set-based queries in an efficient way for the database platform in question? LINQ can only optimize so much as it sends down to the next layer (in our case, ADO.NET, then down to the SQL OLE DB driver, Oracle, DB2, etc). Inefficient code only optimizes at best to slightly less efficient code.
All of the development platforms in the world won't "enable" someone to write efficient code - that's a learning process (note I said "learning", not training - that's a rant for another day). The plain truth is writing code in a set-based language is fundamentally different than iterating through a result set. Until you understand the set-based logic, as well as what is effective vs. what is crippling (using "EXISTS" vs "IN" perhaps), one might as well flip a coin as to whether what is written results in an optimal situation.
I'm done - LINQ may turn out to be nice addition to the Visual Studio world, but it certainly isn't a panacea (and I don't think that Michael Otey intended on implying that it would be - this is me just being paranoid).
Thoughts?