If You Eat Your Vegetables, You'll Grow Up Big And Strong!

I got my latest issue of Dr. Dobb's Journal, and it had two articles that mentioned a technology called LINQ (which stands for "language integrated query") that is new to Visual Studio 2008.

After reading about it, LINQ strikes me as another way to simplify programming. By abstracting the data access syntax required to get at data in disparate sources (such as relational databases and XML files) programmers gain some advantages: programmers have one language to learn to access data instead of several, and the data access code can be compiled and checked unlike the string-literal techniques used with ODBC or JDBC and Xpath or Xquery.

To some, that is a blessing, and to others, it's not such a blessing. I'm in the latter group. With good use of n-tier architecture principles, design patterns, and their implementations such as data access objects, adapters, and stored procedures, developers can write compiled code that is not brittle at the joints, and is easy to maintain. Also, learning more programming languages makes a programmer more valuable, versatile, and if necessary more marketable.

But as a computer scientist, I am not sure we need another way to divorce developers from good technology-agnostic principles and marry them to a specific implementation (in this case, .NET, Visual Studio, and LINQ). There already aren't a lot of .NET developers I know who are well-versed in good programming theory and principles. They're very good at Nike coding (a.k.a. "Just Do It") but when performance or scalability become important they just don't have the exposure to the foundational concepts, like patterns and n-tier, to consider the impacts of their choices on their systems. Or should I say, the impacts of the choices that were made for them by the Microsoft system libraries and .NET framework?

So, is using LINQ like getting dessert before eating your vegetables? I think so.