Why the reverse German-like syntax?

Why the reverse German-like syntax?

• Troels Gram

  Having played around with C-omega, the intellisense wasn't as useful as it should have been.  Reversing the order makes much more sense to me, but then I also spent a decade or so using HP RPL ;)
  
  What case I say, I personally agree with Cyrus's arguments, and here's another:  If you're to put SQL itself into the language, then whose version of SQL   Nobody actually implements the standard.  Each has their own One True Way.  Having Linq as a neutral form, potentially remoteable into the server(http://blogs.msdn.com/cyrusn/archive/2005/09/16/469953.aspx#470735 .. lunchtime fever dreams seem to be contagious), means you don't have to deal with these variations.
  
  
  

• SniperXss

  That article helps explain the why, but shows more examples that make it look even more complicated to use and determine the correct thing to type to do what you want.  The syntax is getting ugly, and I hate ugly.
  
  Maybe it's just my unfamiliarity with it, but any time I see language constructs that begin to look overly complex, I see constructs that only a handful of people will ever use successfully.  Can you say regular expressions...
  
  I love the idea, it just seems like the implementation is becoming too complex for the problem it's trying to solve.

  
  

• niroshanonline

  mike:
  
  I agree, the SQL-like syntax is too big a compromise (it's not SQL-like enough for the SQL programmers, and too SQL-like for the non-SQL programmers). although I seem to recall the VB syntax having SELECT at the front, the way SQL does it, so it's certainly not an artifact of LINQ, or even Dlinq.
  
  SQL is fine, I suppose, but it's a holdover from the COBOL school of language design. its syntax is so complex (in an attempt to be "english-like") that virtually every strategy is an idiom, and there's no good way to extrapolate knowlege within the language. very much like english.
  
  SQL shows its weaknesses in precisely the places where a "pipeline"-based data model (thanks keith) works better: say, "group the data on this column and give me the first five rows in each group which contains more than ten rows". that's not a particularly straightforward join (though I fully expect that a SQL expert will immediately post a five-line query that does precisely this), but it's something I've had to do almost on a regular basis for reporting. if I had a query mechanism that let me express that type of query better, I'd leap at it.
  
  as for the "var", that's not to do with LINQ, exactly, it's an artifact of changing C# to use type inference. C# syntax requires *something* in that position (the type identifier), but with type inference you don't need any specific type, since the compiler will either locate or generate one. I imagine (though I haven't seen) the VB equivalent will remain "dim", currently used for duck typing.
  
  
  

• Manish Sinha

  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
  
  

• Steve Hulsberg

  Actualy I think that it's possible to remove any order limitations from language.

  I.e.  allow to type  select / from / where in any order you wish (or simply support both   from / where / select  and    select / from / where  orderings).

  Anyway it will be easy to figure out corresponding statements.

  Any objection

  
  

• Bjoerni

  > .... why then has VB decided to do it the wrong way

  This would hardly be a first for VB and cannot be taken as a guide for what C# should do.  I am not on the team, and am not from MS, but what's clear to me is that both SQL and VB have historic pretensions to being "English-like".  This is not a very good basis for a programming language.   Beyond this heritage, VB's mission extends to making things seem simpler / more intuitive to junior programmers in every way possible (please no VB flames).  So VB can and will (and must, or why exist ) make syntax and other compromises that are not acceptable to a systems engineering language in the C++ tradition.

  If you have not used VB.NET on a large project, you won't have a sense for the IDE and other differences from C#.  VB.NET seems to parse much more aggressively as you type, possibly just so it can jump through the hoops that its "simpler" syntax push it through, but I can tell you that the IDE doing this makes coding a different (and sluggishly unpleasant, to a C/C++/Java/C# person) experience.  So as you say, though you probably did not mean it, VB has done it the wrong way.

  
  

  
  

• flysocket

  (forgive the sloppy syntax)
  
  My opinion:  select is at the end because that's where, mechanically, it belongs.  You're describing a pipeline, consisting of sources, filters, sequencers, and packagers.  I think it's this pipeline nature which drives much of the ordering in these operations.   For example, packaging may involve calculations, so if you put packaging before filtering, you're performing potentially many wasted calculations.  
  
  Also recall that you could put all this on several seperate statements:
  
  foo = GetFoo(); // source
  foo = foo.where(); // filter
  foo = foo.select(); // package
  
  which is the same as:
  
  foo.GetFoo().where().select();
  
  It's entirely possible, I wager, to continue on:
  
  foo = foo.where(); // further filtering, using properties derived from the select
  
  In fact, I think I've seen as much in the examples.
  
  This also parallels the current programmatic model:
  
  foreach (fooItem foo in GetFoo()) // source
  {
      if (!whereIsTrue(foo)) continue; // filter
      result.Add(foo);  // package
  }
  
  .. excepting of course that we'd now take advantage of return yield.
  
  And this parallels:
  
  from foo in GetFoo()
  where whereIsTrue(foo)
  select foo
  
  Re joins:  Not every database does joins the same way.  There are differences both in syntax (MSSQL prefers the INNER JOIN/OUTER JOIN/etc syntax, Oracle prefers using the WHERE col1=col2 method, etc).  Don't tie yourself to one vendor's implementation.
  
  Re dataset:  DataSet represents a collection of weakly-typed tables.  Many people have over the years grown to dislike DataSet in favor of using entity classes.  What you're getting out of the Linq Select() method is strongly-typed entities representing, notionally, a single table.  I myself have grown very tired of always having to include a table/entity adaptation layer to take advantage of DataSets while also enforcing strong typing in my web services.
  
  
  

• ankitshah112

  I'm convinced that maybe it shouldn't be like SQL.  I can be argued into that one, but it still seems too complex and is reinventing things in some cases.
  
  
  Why add "var" to hold the result when we already have Framework classes like DatSet that do the same thing   Is it really required or are they just trying to keep the language seperate from the Framework
  
  Why make it so complicated to do sub-queries   It looks very ugly, too many indents and seems like it would be hard to remember the syntax correctly.
  
  When using a database, why an automatic PK/FK join like in Access and not a specified join like in SQL.
  
  And if it's going to be out of order SQL-like statements: from... where... select..., why not at least make it: from... select... where...   That seems easier to read and intellisense still works.
  
  

• CmoreButts

  Consider complex sql statements with nested sub-selects: it's not as easy, I think, as you believe.  All the examples that have been provided so far have been fairly simplistic, and they all translate directly into
  
  result = foo.bar().baz().gleep()....bleargh();
  
  ...and they remain independent of the query language.  Remember that Linq isn't about database queries -- that's just DLinq, and DLinq is merely a couple classes that take advantage of Linq itself.  The people involved in XLinq may object to making Linq SQL-centric.  The people involved in Linq sans database may object as well, after the revolution comes and SQL is finally abandoned in favor of a standard everyone actually implements.
  
  
  

• zznb

  Take a read this http://blogs.msdn.com/cyrusn/archive/2005/9/16.aspx blog posting to hear Microsoft explanations.

   

  In the same time - I do not understand why we should keep reverse order in source file. IntelliSense can allow to type expressions in order it's possible  - but after typing complete - convert/keep regular SQL-like order.

  
  

• SACCETTANYC

  I think that settles it then, I agree with all that, makes perfect sense.... why then has VB decided to do it the wrong way Anyone from the VB Team care to comment
  
  It hardly makes sense for a language that has always had better Intellisense than other languages to fall behind in this area.
  
  I think the scoping is most important bit though, scoping is something that should happen in exactly the same way everywhere within the language.
  

• Carl Peto

  As I recall from the spec, the queries are purely macro substitutions, without any juggling during compilation.  This makes things much easier to compile, and the sequence of things doesn't change between the query syntax and the real method calls.  It also makes intellisense tractable.
  
  As for SQL itself, as is pointed out elsewhere (by Anders, I recall), it's risky to bind yourself to a specific technology, including syntax defined by someone else:  the SQL language is such a technology.  When people find something better, SQL will be abandoned.  Linq, however, should still be perfectly applicable.  This, I think, is was why we aren't seeing C-omega.
  
  In another thread, I've suggested that the expression trees generated by DLinq be transmittable to a database for execution.  In which case, you don't need to know SQL at all: you can write in whatever, have the compiler parse it into an expression tree, and have the database server translate that into its own executable.
  

  
  
  

• tmichals

  Keith,

  You are trying to defend current syntax from technical view.

  But have you considered why  SQL (as well some others like HQL and QUEL)  placed SELECT first

  It's all becouse of readability ! Can you translate current syntax to english sentence

  As well - what about 1.000.000's of developers already familar with this ordering

  I may repeat - but the fact that typing must be done in one way does NOT mean that source code must in same order.

  If you wish to migrate to new syntax - it must not be "one true way". Allow people to do use that they feel will suit best.

  As for now - there is no any technical reasons why ordering can not be flexible. This is trivial to reformat sources after typing complete, as well this is trivial for compler to figure out corresponding  select/from statements (plz show example is this is not true).

  
  

• Jack_Orth

  You're trying to defend syntax because it's what one particular implementation uses.  That's specifically something that Anders, et al, set out *not* to do.
  
  Linq is much bigger than SQL or XQuery, and readability is a subjective matter.  Personally, I find the preview syntax much easier to follow -- I don't have to read from the inside out (a particularly evil thing to do with subqueries, and columns defined as queries).
  
  And it reads as perfectly cogent English: "Given a set of items 'c' from the collection, filter such that c.age is greater than 20, then order the collection by c.name, and then return the collection formed by c.name".
  
  And for what it's worth -- if everything is so trivial, then I'm sure it'd be no effort on your part to produce a variant csc that addressed the scope of what is being dealt with.
  
  I'm sure the LISP mavens had battles with the RPN fans years ago.  But guess what -- RPN's perfectly usable, and easy to follow.  So you spend a few minutes getting use to it; it's really no big deal.
  
  
  
• Why the reverse German-like syntax?