LINQ to SQL: Me too on the "Huh?"
OK, so admittedly I've questioned the usefulness LINQ to SQL, but I'd never stand up and say that it's gotta go. What was really said at PDC? Sure, the entity framework sounds super (I say "sounds" because the write ups for it on MSDN are terrible, and the very few books on it haven't been released yet), but why would you stop supporting something that is so obviously gaining momentum and fandom?
My experience with it is that it's great for simple use and prototyping. The LINQ to SQL class designer is probably the only thing I've ever used to drag-and-drop in Visual Studio, ever. Would I use it in the average corporate setting? Not likely. Heck, I'm not even using it in many personal projects. But it has a lot of great use potential, especially for the one-off line-of-business nonsense that is at the core of so many smaller businesses.
As Chad says in his post, why would you throw this away with a bunch of other things constantly coming down the pipe with varying degrees of adoption? How could you in good conscience throw away a pretty OK solution (I realized it's not perfect), when you've persisted the most evil and wretched construct in the history of programming, the DataSet, for seven years! (Seriously, talk about epic bad drag-and-drop craptastic constructs!)
And yes, the bigger problem is the fear that you're going to ditch something for something else every couple of years, and that's the Microsoft way. People outside the .NET developer community already have that perception, so let's not make it a reality. That kind of move makes you gun shy about adopting anything new. And then we're stuck with DataSets again.
The remedies are: 1) Leave LINQ to SQL in the tool box and 2) Somebody write something that makes sense about the EF and I'll be happy to use it.