Monthly Archives: September 2011

There’s no accounting for taste

LINQ, a data querying feature in the .NET framework, was an absolute godsend when it arrived with .NET 3.5 a few years ago. Gone were the endless helper methods designed to manipulate or pick out bits of data from collections. In their place, an intuitive querying syntax – supported either via chaining extension methods, or by using new language constructs which provided SQL-like queries in code.

There’s been a lot of confusion about LINQ since its launch. You could argue that Microsoft didn’t help its cause by closely associating LINQ and LINQ-to-SQL. But it has been some years now, and it is quite concerning that when mentioning LINQ, most developers seem only to be aware of the database querying side of things (the confusion now lives on with LINQ-to-Entities). If only they knew the extraordinary flexibility that arbitrary query trees gave them! The provider model, coupled with deferred execution, is a truly wonderful thing.

It’s also a shame that query syntax is the way that most people seem to choose to write a LINQ query. Redmond says that query syntax is the preferred option, and they should know best, right?

In general, we recommend query syntax because it is usually simpler and more readable; however there is no semantic difference between method syntax and query syntax

But they immediately shoot themselves in the foot with the very next sentence (emphasis is mine):

…some queries, such as those that retrieve the number of elements that match a specified condition, or that retrieve the element that has the maximum value in a source sequence, can only be expressed as method calls.

So they’ve implemented some admittedly pretty syntactic sugar, but not managed to extend it to cover some common and useful parts of the new API? Frustrating!

Given the current, justified popularity, not to mention the inherent readability of, fluent interfaces, I think coding standards should prefer method syntax on these grounds alone. The only impediment I felt, when pushing myself into method syntax exclusively, was that set joining operations are less intuitive in method syntax than query syntax, for those who first learnt set joining from SQL. But I think this isn’t a good enough justification.

Method syntax for me.


Everyone starts somewhere. I started with Mallard BASIC, a very simple variant of the language. In fact, the variant was so simple that it didn’t even include a language primitive for clearing the screen (almost universally CLS in other dialects). I had to resort to bizarre escape codes. There’s probably a good CP/M reason for this, but the upshot was that typing in listings from BASIC magazines was almost always a fruitless endeavour as the subtle incompatibilities defeated my young brain.

Pressing the fast-forward button, I then began tinkering with QBASIC, and even Visual Basic for DOS which came complete with an ASCII forms designer (think a visual designer for an Ncurses UI). Those are not days to look back on with pride necessarily, but the simplicity of the tools really kept me interested in programming. It was easy to do colourful and fun things, and I didn’t have to worry about anything “difficult”. I would look longingly at various beautiful specimens from the demoscene, but I dismissed them as something well beyond my ability.200px-Impossible_staircase

A brief flirtation with Tcl, and then some dithering around with Java preceded my eventual emergence as a .NET developer who has begun to deal with the “difficult” things. But even as this emergence boosted my confidence, it also became apparent that the childish fantasy of one day reaching the apogee of competence was an illusion. Developers are living their careers on a set of Penrose Steps. The climb is never-ending, as we constantly seek to increase our understanding of the tools we use, all the while trying to sup from the fire hose of new ones, both good and bad.

This isn’t a bad thing. Good developers live for the challenge, and that is what they get. The technical world is racing ahead, and staying in the race is rewarding on so many levels. It can be daunting, but once you take into account the fact that it’s a journey you’re on, rather than a destination to be reached, it begins to make sense. Some developers make a choice, actively or passively, to settle on a particular stair and eke out a standardized and uninnovative living. That is of course their prerogative, but it is an alienating and depressing idea to me!

I shall try to use this blog to illustrate some attributes that define a climber and not a settler, and perhaps provide a little motivation for those who feel they are inadvertently stagnating.

Tabula rasa

And so it begins. After too many years to count, I have finally got on board with an actual blogging platform. It seems strange to me that having been an early adopter of all sorts of things over the years, I’ve never seen fit to have a blog. But there you are.