This post originated from an RSS feed registered with .NET Buzz
by Paul Vick.
Original Post: Is it Select/From or From/Select?
Feed Title: Panopticon Central
Feed URL: /error.aspx?aspxerrorpath=/rss.aspx
Feed Description: a blog on Visual Basic, .NET and other stuff
Over in the LINQ MSDN forums, the question came up: which is better, Select/From (as VB does it) or From/Select (as C# does it)? To quote from the thread, here’s the C# side of it, straight from Anders:
There are a multitude of reasons why select comes at the end and not the beginning of a query in C# 3.0. The more important ones are:
(1) Statement completion (Cyrus' blog has a good explanation).
(2) Order of execution. The C# query syntax lists operations in the order they are executed.
(3) Scope of "from" variables. SQL is strange in that scope flows both upward and downward. In C#, scope extends from the point of introduction to the end of the query, which seems much more intuitive.
(4) Large select expressions. In SQL, because results are rectangular rowsets, select clauses tend to be fairly simple. However, when querying objects and XML it is quite common to have large select expressions that construct entire object graphs, possibly with multiple nested queries. Trying to understand a large select expression written in terms of variables that haven't been introduced yet (and may not even be visible on the screen) is quite confusing.
(5) Even if we picked SQL's ordering, the similarity would be skin deep. There are lots of other differences. For example, C#'s built-in operators and quite different from those of SQL. I actually think the different ordering is a benefit because it makes it quite clear that this is not SQL.
Note that XQuery's FLWR ("flower") expressions have the same ordering as C#'s query expressions--I suspect for some of the same reasons.
Anders
and here’s the VB side of it, straight from me:
Speaking from the VB team perspective...
As is already obvious from this thread, Select/From ordering is going to be another one of those religious issues like case insensitivity that people are going to be arguing about for the next twenty years and beyond. As with case sensitivity, both sides can marshal perfectly reasonable arguments as to why their choice is the One True Way(tm) and why the other side is Consorting With the Devil(tm). I say this knowing that nothing I say now can influence that outcome and that this discussion (in the larger sense) must always end in tears, recriminations and Godwin's law. But it's worth saying nonetheless.
With that out of the way, I think this thread has already covered many of the relevant points relating to why VB chose to say Select/From instead of From/Select:
* For many, many programmers and for many, many VB programmers, specifically, SQL is a very familiar language. Leveraging a huge existing base of knowledge (and programmed muscle memory) makes the LINQ support more understandable and usable straight out of the gate.
* The SQL ordering of clauses is a time-tested convention that has been in continuous use for decades.
* VB emphasizes English readability. As noted in the beginning of the thread, the SQL ordering is more English readable than the obverse.
Anders raises some objections to the SQL ordering, but on the balance, we believe that the benefits outweigh the limitations. Specifically, I'd say:
* Statement completion is a significant question. We have a bunch of ideas as to how we could finesse this in the IDE, but we haven't reached a point of being really able to try them out. This may be a real sticking point, time is just going to tell.
* I don't agree with Anders's points about the difficulty of understanding SQL's clause ordering. Although some variants of SQL have invented phenomenally complex and bizarre sets of rules about how binding works, the basic rules about binding seem to have been graspable by millions of SQL programmers over the years without too much pain and suffering. As long as the rules remain relatively simple and straightforward, there don't appear (to me, at least) to be major hurdles in implementing a very understandable Select statement where From is in the middle of the statement. Reasonable people can disagree on this point, however.
* Ultimately, we don't believe that people will be confused as to whether this syntax is SQL because it will become almost immediately obvious that it isn't once a programmer works with it for more than a few minutes. It's a problem that will sort itself out on its own relatively quickly.
I would close by saying that the VB team, overall, values practicality over dogmatism. From a pure syntatic perspective, clause ordering is not fixed in stone - one could support both a Select/From order and a From/Select order without much difficulty. Indeed, we'd like to look at how clauses such as Where and Order By can be used on their own without requiring a Select or, perhaps, even a From. So while we will continue to support Select/From, other possibilities may be investigated if it becomes obvious that they make the language more usable in some strong way.
That's about it. We now return you to your regularly scheduled religious debate...
Paul VB Team
And that’s where it stands at the moment… I’m sure I’ll get a few comments on that, though.
Previous Topic
