I've been thinking this week about the impact that LINQ will have on the development world. If LINQ succeeds, it will change the way we think about programming. The team's ambitions for LINQ are large. As the community PM for C#, my job is fairly obvious: I need to help us find a way to make LINQ succeed.
LINQ gives developers a tool built into their native language that allows them to query data. It is perhaps a bit shocking that this has never been done before. Most of the applications C# developers build are designed around databases. Why should our primary language for writing database applications not include a useful mechanism for querying data?
If LINQ succeeds, then it will be impossible for any major language to omit such a tool. For instance, any language that forces developers to embed SQL strings in their source code will be considered hopelessly old fashioned.
If LINQ succeeds, then it will represent a change in the way we build applications that is comparable to the change wrought by the introduction of object oriented programming. Like object oriented programming, however, LINQ requires a major conceptual change in the way developers think about their code.
As LINQ is rolled out over the next months, we will finally discover whether or not this brave new idea will succeed or fail. If it succeeds -- and it probably will -- it will change the way we think about programming. Nevertheless, we sit perched on the edge of a considerable drama, and it will be exciting to watch it unfold.
When working with LINQ it is hard not to be seduced by the complexity of its internal implementation. Really smart people who like to think about compilers find LINQ interesting because its implementation is both challenging and relatively unique. The functional programming ideas found in LINQ are not new, but the idea of embedding a functional programming language inside an a mainstream imperative language like C# is relatively unique. The techniques the developers of LINQ used to make this possible are both arcane and fascinating.
The problem, however, is that the people who use C# daily in their work are not interested in esoterica about expression trees, lambdas or extension methods. They have a job to do, and they want to get it done quickly so they can go home and play World of Warcraft.
Most developers are interested in complexity. But their craving is easily sated by the job they face. Most of them don't have either the time or the desire to learn about esoteric compiler details.
As I look ahead over the coming months, it seems to me that my job is fairly obvious. LINQ needs to be presented to developers in a way that makes its utility immediately obvious. The focus has to be on its usefulness, not on the artfulness of its implementation. There is room for the discussion of both issues, but the first task is to show why LINQ is useful, and how easy it is to use.