According to C#’s architect Anders Hejlsberg, there's an "impedance mismatch" between most programming languages and the database.
What this means is that programming is all about procedural processing and how business (and other logic) works, while database access (at least in the relational database world) is all about declarations of what data you want (roughly, "SELECT A FROM B WHERE X=Y"), regardless of how you'll get it and what table it’s in. So, you issue simple declarative queries against a database; and when you get the data back into your program, in memory, you process it entirely differently. Wouldn't it be nice if there was a simple declarative language built into, say, C# or Visual Basic (Microsoft seems to think that these are the typical developer's primary programming languages, although no doubt some would disagree)?
This is what LINQ (Language INtegrated Query) will deliver, on the .NET platform. It's set of general-purpose declarative query operators that allow traversal, filter, and projection operations to be applied to any IEnumerable
The LINQ query language uses "lambda expressions", an idea originating in functional programming languages such as LISP - a lambda expression defines an unnamed function (and lambda expressions will also be a feature of the next C++ standard). In LINQ, lambdas are passed as arguments to its operators (such as Where, OrderBy, and Select) - you can also use named methods or anonymous methods similarly - and are fragments of code much like delegates, which act as filters.
LINQ also defines a distinguished type, Expression
Another idea LINQ borrows, this time from dynamic languages, is the idea of "extension methods". These allow third parties to add new methods to the public contract of a type without stopping individual type authors from providing specialised method implementations.
One key feature of LINQ is its implicit support for SQL (DLinq) and XML (XLinq) integration, and this will assist full-blown object relational mapping products, as these can now take advantage of inbuilt language support. However, one possible issue is that it doesn't (as far as I can see) have the solid foundation in set theory that a query language based on a pukka relational algebra has (see Chris Date, “Database in Depth”, O’Reilly, ISBN 0-596-10012-4, for what this means). It may be possible for a programmer to confuse the quality of data sourced from a relational database (where integrity is enforced by the RDBMS – Relational DataBase Management System - itself and can largely be relied on) and data sourced from, say, an XML data store (where it isn't and can't be). In practice, since most RDBMSs (and the SQL language itself) compromise hugely with the purist relational model and therefore can't really claim the benefits from following it, this may not matter – LINQ is no worse than everything else (and relational algebra may be too hard for many people anyway). However, some people (myself included) think the loss of the formal rigor associated with the relational theory is to be regretted – although LINQ, in itself, doesn’t force any RDBMS to abandon relational theory, of course.
In terms of the evolution of programming languages, LINQ represents a fusion of a typical OO language (C#) with ideas taken from modern dynamic languages such as Ruby and functional languages such as Lisp. It’s a thoroughly interesting idea and its availability probably will make C# a technical advance on Java, for a time at least. However, whether it actually delivers better (more powerful, more reliable and more maintainable) applications - which is presumably what it's all about at bottom for the companies employing .NET developers - depends on how C# and VB programmers take to such concepts as lambda expressions, expression trees and declarative programming.
The Microsoft website offers a fuller and more technical description of LINQ, by Anders Hejlsberg and Don Box of Microsoft, can be found at LINQ is supported in C# 3.0 and VB 9.0