Understanding the LINQ Question

A few readers have written to ask me about the question I keep discussing when talking about LINQ. I use the idea of a question in both LINQ for Dummies and Start Here! Learn Microsoft Visual C# 2010 Programming to describe the concept behind LINQ. In fact, if you have problems understanding this concept, you’re not alone. Many people have trouble understanding just how it is that declarative languages such as LINQ and SQL perform their job. The idea that you can describe what you want and let the computer decide how to do it is foreign to many people because most people rely on procedures to understand many issues. LINQ and SQL don’t offer procedures. At the root of the problem is the word “how.” We want to know how things work and how to do things.

Imagine for a moment that someone tells you to go to 123 Anywhere Street and pick up a widget for them from the grocery store. They don’t tell you how to get to 123 Anywhere Street or anything else about the request—they simply assume that you’ll figure it out on your own. Most people would eventually get a map, work out a route, and get to 123 Anywhere Street. Once there, they’d go to the grocery store and ask for a widget from the owner. This sequence of events is akin to what is happening with both LINQ and SQL. You tell the computer to get the widget from the grocery store at 123 Anywhere Street. The “how” is unimportant and you truly don’t care how the computer accomplishes the task.

So, where does the question part of this discussion come into play? Developers want data to manipulate within their applications, not widgets. When a developer requests data from the computer using a language such a LINQ, the developer does so in the form of a question or a query. In fact, declarative languages often use the word query as part of their nomenclature: Language INtegrated Query (LINQ) and Structured Query Language (SQL). These languages specialize in asking questions and telling the computer to use any means necessary to answer them. The developer doesn’t care how the language does its work—all the developer cares about is the data.

Declarative languages free the developer from having to think about how to perform tasks. A developer can spend more time thinking about data manipulations and less time thinking about the mechanics of language. This means that the developer can become a lot more productive and write applications significantly faster. The use of declarative languages also makes application development easier. A less skilled developer can write a more complex application.

Don’t get the idea that LINQ is a wimpy language that limits what you can do in the interest of simplicity. In fact, LINQ users can create extremely complex scenarios that would require considerable time to figure out without LINQ. For example, I wrote an article about using LINQ Extensions some type past. You’ll want to review this article if you need to see one of the more technical ways to use LINQ (and even this article doesn’t discuss the topic in depth). While you’re at it, check my other articles on using LINQ Expression Trees and using LINQ with Resource Description Framework (RDF) files.

The bottom line is that LINQ is about queries, or questions. You ask the computer to supply data based on some criteria. The computer decides how best to obtain the data for you, so you can concentrate on issues that the computer can’t decide, such as data manipulation and presentation. If you have additional questions about why someone would use LINQ or why I explain LINQ as answering questions, please let me know at John@JohnMuellerBooks.com.


Author: John

John Mueller is a freelance author and technical editor. He has writing in his blood, having produced 99 books and over 600 articles to date. The topics range from networking to artificial intelligence and from database management to heads-down programming. Some of his current books include a Web security book, discussions of how to manage big data using data science, a Windows command -line reference, and a book that shows how to build your own custom PC. His technical editing skills have helped over more than 67 authors refine the content of their manuscripts. John has provided technical editing services to both Data Based Advisor and Coast Compute magazines. He has also contributed articles to magazines such as Software Quality Connection, DevSource, InformIT, SQL Server Professional, Visual C++ Developer, Hard Core Visual Basic, asp.netPRO, Software Test and Performance, and Visual Basic Developer. Be sure to read John’s blog at http://blog.johnmuellerbooks.com/. When John isn’t working at the computer, you can find him outside in the garden, cutting wood, or generally enjoying nature. John also likes making wine and knitting. When not occupied with anything else, he makes glycerin soap and candles, which comes in handy for gift baskets. You can reach John on the Internet at John@JohnMuellerBooks.com. John is also setting up a website at http://www.johnmuellerbooks.com/. Feel free to take a look and make suggestions on how he can improve it.