At conferences such as TechEd, the audience have a new and rather frightening form of feedback. When they lose interest, they start emailing or twittering. When they get bored, they walk out. T-SQL sessions are not immune to this trend. When the T-SQL gets too esoteric, the faces of the audience became suffused in the soft glow of laptops as they arrange their social life on networking sites. When it gets really complicated, there is a scrabble for the exits. T-SQL is getting scarily arcane in places.

T-SQL is not a language to be admired from a distance for its grace, sophistication and integrity. It is a tool designed to allow "normal" developers and DBAs to build database business applications as smoothly and efficiently as possible.

The task of evolving the T-SQL language in an intelligent and structured way is, of course, a complex one and progress is often slowed by issues such as Standards adherence and backwards compatibility. However, a balance must be struck between the need to defend the integrity and structure of a language, and the need to give the developers the features required to tackle the problems they are facing, quickly and easily.

Despite their undoubted depth of their knowledge and frightening intelligence, those in charge of the T-SQL language at Microsoft often lack recent frontline experience. In this respect, they are less well-qualified to dictate the direction that T-SQL takes, what features it will and won't allow and how they will work, than the many programmers who use the language every day to try to build business applications.

Programmers, when confronted with an obstacle to progress, do not have time to stand back and appreciate the various reasons why the technique they wish to use isn't valid, or the feature they want is missing. They just need to get the job done. In the main, communities respond with remarkable good grace to the various barriers they find in their path. They send the occasional plea to Microsoft via Connect, ask for help on forums, or write the occasional grumpy blog post. Sometimes, however, tempers boil over, as they did last year in the case of the Entity Framework.

Votes of no-confidence aren't really the way forward, but I understand the frustrations that arise when a tool's obvious limitations make real world scenarios painful to solve; and I do not think that the "average developer" should feel that they are somehow "unqualified" to request the changes or enhancements they desperately need.

The people best qualified to pass verdict on T-SQL, or any other tool, are the people for whose use it was designed. The right to debate and argue with developers at Microsoft about how they've built products is not the sole the preserve of academics, trainers, MVPs, and other assorted members of Microsoft's "inner circle".

The views and opinions of frontline developers and DBAs are the most valid of all. We should express them freely on community forums such as SQLServerCentral, because the smart people of the SQL Server team at Microsoft already read what we write and are clever enough to realise that, when it comes to delivering real business applications, it is we who are the experts.

Cheers,

Tony.