Submitted by “I was a huge fan of the Connections series, hosted by James Burke, when it aired on the Discovery Channel. Its basic premise: how seemingly unrelated discoveries influenced other discoveries, which ultimately led to some modern-day convenience. The moral, if you will, is that no advancement is made in isolation. Not surprisingly, the same is true for Language Integrated Query (LINQ). In simple terms, LINQ is a series of language extensions that supports data querying in a type-safe way; it will be released with the next version Visual Studio, code-named “Orcas.” The data to be queried can take the form of XML (LINQ to XML), databases (LINQ-enabled ADO.NET, which includes LINQ to SQL, LINQ to Dataset and LINQ to Entities), objects (LINQ to Objects), and so on.”
I was fortunate enough to see a presentation by Anders Hjelsberg on LINQ (but much similar to the one you can find on the net by him)
In many ways I like the ideas behind LINQ. Especially the way that you can use the same constructs to retrieve data from different types of datasources.
The negative side however is, that this is only about retrieving data from the datasource. It does not attempt to solve the problem with data persistence, and as a dataaccess technology I find it incomplete.
When working with data from a rdbms I much prefer to use LLBlGen. I realize that LINQ and LLBlGen have overlapping but different goals. But I would have loved to see LLBlGen (or a similar product) integrated in the .NET development stack instead.
Edited 2007-07-09 18:17
ADO.NET Entity framework (to be released after .NET 3.5) will attempt to solve that problem.
The ideas behind LINQ are not limited to SQL databases. They can also be used on objects. They are more like list comprehensions, but with a SQL like syntax:
http://en.wikipedia.org/wiki/List_comprehension#In_C.23
For a persistence framework you hopefully do not need any syntax extensions.
I love the functionality, but I think they should not have added additional syntax to the language. The syntax just using extension methods and lambda expressions might be a bit more verbose, but I would prefer C# to stay simple and not turn into a modern day C++.
There is also some discussion about this topic at lambda the ultimate:
http://lambda-the-ultimate.org/node/2333
public static const Comment* amenToThat() const;
[EDIT – fixed quoting]
Edited 2007-07-09 19:27
While I generally agree that they should not try to push everything in to the language, I really think that if anything should be added at all, it’s an extensible approach to queries and object persistence. LINQ tries to do that, and so far it seems to be a rather good solution. It’s important to remember that LINQ is just about the syntax and language constructs, and not about the actual persistence implementation. We’ll see LINQ applied to NHibernate (Ayende is working on that), and other OR-frameworks (LLBLGen etc.), so LINQ should not be seen as a competitor to all those products. It’s more of an opportunity.
I was lucky enough to see a presentation on XLinq by Štepán Bechynský at XML Prague 2007.
So if I understood correctly, Microsoft have added additional constructs and operations to their .NET languages. Unfortunately from what I could see this new syntax was a very strange mash up between SQL like syntax written in reverse and DOM.
Now I do a lot of work with XML, XPath, XQuery and XSLT amongst many other XML related technologies. I couldnt help feeling that this new XLinq approach was just wrong in every way.
DOM is old and SQL is not really designed for querying XML. The W3C have developed XPath and XQuery and these are open standards. Why oh why did Microsoft feel they had to develop their own approach?
If they wanted to add contructs to their .NET languages for XML querying, why not just add XPath/XQuery constructs? Some of the C# XLinq syntax examples shown in the presentation took up 10 or 20 lines of code that could be easily achieved with 3 or 4 lines of XQuery; the XQuery would be much easier to read as well.
Now I know Microsoft always like to go their own way, I dont nessecarily have a problem with that, after all it is my choice as to whether I use Microsoft products (and I do)… But with XLinq they really have missed the point!
Edited 2007-07-09 19:51
I think you’re missing the point – MS didn’t simply choose to go their own way for the sake of being different, they chose to make it compatible with everything else so that querying objects, dbs, and xml was all identical. Since all of those are different ways of storing data, you are bound to run into some issues when trying to grab data from all of them with a single syntax, but that doesn’t mean it can’t be useful. Granted, I don’t really see myself using XLinq either.
Edited 2007-07-09 20:25
“Some of the C# XLinq syntax examples shown in the presentation took up 10 or 20 lines of code that could be easily achieved with 3 or 4 lines of XQuery; the XQuery would be much easier to read as well.”
You get strong typing with XLinq, which means better compiler support for catching errors. That in itself is reason enough for most. I also personally think XQuery is a pain to read, but maybe that’s just me.
Microsoft was developing a strong XQuery API and ObjectSpaces (an object-relational framework) until it was made moot (and quaint) by changing the language itself.
I believe that the LINQ For SQL’s “100 samples” are based on some standard XQuery body of samples.
what is that supposed to mean? The only syntax C++ added to C were things you can’t easily do in C without tons of macros or platform-specific hacks: namespaces, classes, generics/templates, overloading, and exceptions. You really can’t strip any of those out without fundamentally reducing the language’s usefulness.
That said, the same really goes for LINQ, too. Namely, it’s *type safe*. The compiler parses the LINQ queries at compile time and guarantees that types match up. You really can’t do that without either compiler support or extensive runtime introspection. Runtime introspection would drastically slow down every LINQ query, and just moves the errors from easy-to-detect compile time to pain-in-the-ass-to-debug runtime.
I am a completely aware that this is strongly typed. In fact I am a big fan of strongly typed languages.
But there are many much better designed strongly typed languages than C++. The huge popularity of dynamically typed languages is IMHO a consequence of the unnecessary complexity and verbosity of popular strongly typed languages.
The type system of languages like ocaml, clean and haskell makes C++ look like a toy. And especially clean and ocaml can be just as fast as C++.
Another interesting language is Scala. It allows you to use all java libraries seamlessly since it runs on the JVM, yet it has all the features you would expect from a modern object-functional language. It even has support for creating little DSL like linq.