Editorial Note: I originally wrote this post for the NDepend blog. Check out the original here, at their site. While you’re there, have a look around at some of the other posts and subscribe to the RSS feed if you’d like a weekly post about static analysis.
I can still remember my reaction to Linq when I was first exposed to it. And I mean my very first reaction. You’d think, as a connoisseur of the programming profession, it would have been, “wow, groundbreaking!” But, really, it was, “wait, what? Why?!” I couldn’t fathom why we’d want to merge SQL queries with application languages.
Up until that point, a little after .NET 3.5 shipped, I’d done most of my programming in PHP, C++ and Java (and, if I’m being totally honest, a good bit of VB6 and VBA that I could never seem to escape). I was new to C#, and, at that time, it didn’t seem much different than Java. And, in all of these languages, there was a nice, established pattern. Application languages were where you wrote loops and business logic and such, and parameterized SQL strings were where you defined how you’d query the database. I’d just gotten to the point where ORMs were second nature. And now, here was something weird.
But, I would quickly realize, here was something powerful.
The object oriented languages that I mentioned (and whatever PHP is) are imperative languages. This means that you’re giving the compiler/interpreter a step by step series of instructions on how to do something. “For an integer i, start at zero, increment by one, continue if less than 10, and for each integer…” SQL, on the other hand, is a declarative language. You describe what you want, and let something else (e.g. the RDBMS server) sort out the details. “I want all of the customer records where the customer’s city is ‘Chicago’ and the customer is less than 40 years old — you figure out how to do that and just give me the results.”
And now, all of a sudden, an object oriented language could be declarative. I didn’t have to write loop boilerplate anymore!