For the people who misunderstood me in my last posting: I really like Linq as a general purpose system to offer a single interface for accessing enumerable data structures.
My point in my previous posting wasn't to rant about Linq, as I truly like it, my point was that the video gave me the idea as if they believed they had invented something like O/R mapping, an OO overview of your relational model and a compile-time checked query system. I can do that today, so that's nothing unique. .
Though, at the moment, every O/R mapper vendor uses his own query system, his own system to map objects, his own system to track changes, his own system to interact with other systems, build in validation, workflow, do serialization/remoting etc. With Linq (that's not: DLinq, but Linq), this can be made more generic: the user can now work more transparent with the underlying engine, from whatever vendor.
So Linq solves an actual problem. Now, DLinq on the other hand is a different story. DLinq might seem it will make things easier, but it carries along some mistakes already known for years by the O/R mapper vendors. I therefore see DLinq as an example implementation, how the Linq system works in practise, how you can extend it into a given direction.
Personally, I'm not that worried about DLinq, I just find it a missed chance for MS to create something great. I mean, instead of solving other problems in the OO world, like cross-appdomain object awareness so server-farm wide object caches can be created so you really can have safe object caching outside the database, it comes with an already surpassed O/R mapper lookalike (DLinq, not Linq). I also wonder why MS comes with DLinq at all, because are they now suddenly convinced everyone should drop the Dataset and move on to an O/R mapping world? As Anders said in the video, it's a future version of ADO.NET, but what about the hardcore table/raw sql focussing crowd? I.o.w.: current ADO.NET building blocks have to stay, you can't drop these out, as you'll then abandone that crowd of people, currently using stored procs and datasets/readers.
Don't think lightly about this: DLinq from MS is a huge paradigm-shift. From service oriented, based on messages and anonymous datasets to domain oriented, with typed domain objects. We'll see how it evolves. I only hope Linq isn't compromised to make DLinq work better, but kept as generic as it is now, so 3rd party vendors can actually use it as our next-gen query language, which is a big benefit for our customers/users.