I've been "a database guy" for quite a while. Way back in 1989, I left the security and blandness of Boeing for a new project a Microrim (of R:Base fame), which was building a new database solution (by "solution", I mean the whole shebang - server, UI, connectors to other databases, UI abstraction to run both on (hold on) OS2 and Mac).
As part of that job, I wrote the Query By Example part of the database front end (what we called a "surface"). If you've ever used Access or SQL enterprise manager, you've used QBE - you just get a table to fill in, and the system generates the SQL query under the covers for you. It's an interesting problem - it's fairly easy to represent everything from a QBE table as SQL, but going the other way is more problematic - there are some queries that just don't represent themselves well, even before you get to degenerate cases and inner joins.
Along the way I learned a fair bit about database design, normalization, and how to think like a database engine. This carried on to my later jobs, where I often chose a database as the best way to store information, and therefore I wrote a fair bit of data access code. As I moved into the object-oriented world, I wrote a fair number of what I'll call "class adapters" - classes whose purpose is to adapt between the database view of the world (rows and columns, with separate statements to query, update, or delete information) to the object-oriented world (classes with fields and methods to perform operations).
These classes aren't hard to write, but they are a bit tedious. How many times can you write something like:
m_name = (string) currentRow[NAME_COLUMN].Value;
or deal with the fact that string values in insert statements are quoted, but integers are not, without getting tired of it?
When Ado.net came out, I played around with it (not being a developer at the time, I didn't really use it). It does some neat things - strongly typed datasets, for example, but after using it for a few projects, I decided that it was a pretty big stick for the kind of stuff that I was doing. I didn't need disconnected datasets, I rarely (if ever) have written an editable grid, and I didn't like having to regenerate datasets every time I modified my schema. I also had a hard time keep track of all the pieces - queries, adapters, connections, transmissions, valves, condensors, centrifugal clutches, ultrasonic cleaners, etc.
So, I switched back to the tried and true:
while (result has rows)
style of programming, but I wasn't fully happy with it. There was still - to use the terms Anders uses - a big "impedence mismatch" between the programming language world and the database world. There's a lot of improvement to be had, if a solution to the problem can be found.
A couple of years ago, the C# language design team started talking about whether there was something that could be done at a language level, and I got to participate in that discussion for around 9 months. The coolest part of the plans are that...
Well, I can't really tell you. Partly because I'm not the person to talk about the details, but mostly because I've been away from the language design team for nearly a year now, so I'm not sure where the discussions led.
If you can't make it to the PDC, I'll try to link to documents as they become available, or you could just wait for Luca to post them