I'm old-ish, too. And I have to concur with Bob 100%.

Everybody I work with is always jumping onto the latest shiny new thing: today it's LINQ, so DataSets and SqlDataReaders are automatically deprecated. Never mind that they, too, were once "the only way you should ever do data access, moving forward". What will it be tomorrow?

I work as a dev/DBA, and I have "developed" using LISP, Pascal, Excel's macro language(!), Lingo (for an old product called Director), Actionscript, VB.NET and C#. From my experiences (and I don't think anyone's mentioned this yet), I've found that one of the things that makes it "harder" to work with application development languages is the sheer size of the libraries that accompany those languages. The .NET library has thousands of classes and it's being added to every day. So, the developer's job includes staying up to date on the state of the libraries that lie beneath the language(s) he or she works with. With T-SQL, we don't see that kind of growth and it is more "up to you" how you will craft your solution -- provided that T-SQL is the best tool to leverage in creating that solution.

So, I think that though we work with technology it is not technology that ultimately gets the job done. It is the people employing the technology who get it done. There's an earlier poster in this thread who says he's a DBA, working with developers. That's great! And I hope his company maintains that structure, because it demonstrates the best way to operate by utilizing people as assets. Those developers know (or they should know) that they have a resource available to them as they code their apps -- a resource that lives and breathes and can be gone to for help when needed. That beats Google any day. Or at least it helps Google.

As for the paradigm, I've found the set-based mindset easier and more comfortable over the years. So for me, SQL (in all of its flavors) is an "easy enough" paradigm to work with.