For example, why do you do this in LINQ
var products = from p in Products
select p.Name;
when they could have done this:
var products = select p.Name from Products p;
Does the second offer some limitations in linq? Maybe the above examples are too simple to actually see why linq is written in one order and sql is written in another.
Because in order to have Intellisense in Visual Studio working with LINQ, it needs to know the tables first so that the editor can offer the programmer the list of columns to choose from. If you do it the SQL way and first you choose the columns, the editor can't really help you as it doesn't know which tables to look at.
Because LINQ is not SQL. LINQ consists of a number of chained extension methods on IEnumerable<T> (when you are using the System.Linq namespace). The SQL like syntax is just a compiler trick to enable some syntactic sugar on chains of such query methods so it appears you can use queries looking a bit like SQL inside .NET languages. LINQ basically has nothing to do with SQL per se...
It is often cited that the reason is Intellisense. Because if you start writing
select p.
the compiler can't say what properties to show you.
but if you start with
from person p select p.
it knows to look up properties on the person object.
HTH alex
Intellisense is often cited as a reason, but I think a better explanation is that Select logically happens at the end of the query writing process. First you set up your data sources, then you filter and group, then once you have everything in place you specify what you want to get out.
While others have correctly stated that providing intellisense was part of the reason that influenced Ander's decision, something else that needs to be considered is that LINQ is not just intended to be used with SQL. As it's a much more encompassing technology, LINQ was never intended to be constrained to just work the way that SQL does.
Extending what peSHIr said.
LINQ is based on the mathematical principles of lambda calculus.
You need to study/understand how LINQ query operators map to actual methods.
Leaving aside IntelliSense, query expression expansion etc (which are all valid reason), I actually believe the LINQ way makes a lot more sense.
You start with a data source. You apply filters, ordering etc. You finish with a projection. In other words, the query is written in the logical order of operations.
To put it a different way: why on earth did the SQL designers choose to order SQL queries that way?
Actually, LINQ's syntax is more closely based on XQuery than it is on SQL, and XQuery does it that way, too.
The main reasons have already been given: in C#, VB.NET and indeed most programming languages, scope flows from top to bottom and left to right, just the way we normally read. The way SQL is written, scope jumps around: an identifier gets already used in the SELECT part of the query, but it only gets introduced later, in the FROM part of the query. That's why the designers of XQuery decided to flip it around and LINQ just follows.
It also matches the mental model better: you have list of data sources (FROM), then you filter out the data you're interested in (WHERE), then you sort this data (ORDERBY) and lastly you either project it into a different representation (SELECT) or partition the results (GROUP BY). After that, you can inject the results into the next query (INTO).