4 ms·

C# is designed with IDE support in mind. For example, in Linq the "map" syntax is: from a in b select a.x This syntax is actually backwards compared to bot

by olavk 16y ago

C# is designed with IDE support in mind. For example, in Linq the "map" syntax is: from a in b select a.x This syntax is actually backwards compared to both SQL and list comprehension syntax is most languages, which have the selector expression is before the input list. E.g in SQL: select b.x from b Or list comprehensions (in eg. Python): [a.x for a in b] So why did MS change the syntax like this? Most developers already knows SQL syntax, and Linq queries are supposed to be able to map directly to SQL. The reason it that it is not possible to provide code completion in the selector expression if the type of the list is not yet known. Hence in C# the list is written before the selector expression, so the editor helpfully can list all a's members when typing `select a.` Another example is "Partial Classes" which is a curious language feature which makes it more smooth to work with UI-designer generated files, but which I don't think has any useful function outside of an IDE. I don't think many other languages are designed with IDE support in mind in such a way. This makes it possible to provide a very smooth IDE experience.

wvenable 16y ago
From a theory perspective, SQL has it backwards. The projection operation in relational algebra would come last. It certainly helps with IDE interactions but it makes sense entirely on its own.
- buro9 16y ago
  That's how I saw it too, much closer to set theory and relational algebra. Besides... when I write SQL I write it thus: SELECT * FROM BLAH Then refine to: SELECT * FROM BLAH WHERE FOO Before finally adding: SELECT COL1, COL2 FROM BLAH WHERE FOO Linq matches the way I construct SQL by putting it into the order I logically think of it: FROM BLAH WHERE FOO SELECT COL1, COL2
- olavk 16y ago
  I may be confused, but according to Wikipedia http://en.wikipedia.org/wiki/Projection_%28relational_algebra%29 http://en.wikipedia.org/wiki/Projection_%28relational_algebr... it seems that in relational algebra notation the attribute names are written before the relation, since the relation is an argument to the projection function. This seem to me to be closer to SQL syntax.
  - wvenable 16y ago
    The attribute names are written first, but it's like nested function calls: projection(selection(R)). The joins are 'evaluated' first, then selection (where), and then projection. I suspect that SQL was actually designed to match the notational order (but reversing the intent) they still got it wrong: to match the notation, it should be SELECT .. WHERE .. FROM.
    - olavk 16y ago
      Interesting point, but that would apply to function notation in general, not just relational algebra. a(b(c(x))) is "backwards" because the functions are evaluated in the opposite order than they are written. This is a flaw in math and in most programming languages! I suppose stack-based languages have it right, and the OO method chaining syntax in Linq and in e.g. JQuery has it right, since evaluation order is left-to-right.
koenigdavidmj 16y ago
You can also say b.select(a => a.x) if you want the more traditional syntax.
- mullr 16y ago
  I use this syntax all the time and greatly prefer it to the special 'from' keyword. I think it scares my co-workers a little less. There are a few cases where the from syntax is necessary, but it's not common.
kakuri 16y ago
I think tying language design to IDE design is absolutely brilliant. Languages are just a tool, IDEs are just a tool, we're missing brilliant opportunities if we neglect to design them synergistically.

by olavk 16y ago

wvenable 16y ago

From a theory perspective, SQL has it backwards. The projection operation in relational algebra would come last. It certainly helps with IDE interactions but it makes sense entirely on its own.

buro9 16y ago
That's how I saw it too, much closer to set theory and relational algebra. Besides... when I write SQL I write it thus: SELECT * FROM BLAH Then refine to: SELECT * FROM BLAH WHERE FOO Before finally adding: SELECT COL1, COL2 FROM BLAH WHERE FOO Linq matches the way I construct SQL by putting it into the order I logically think of it: FROM BLAH WHERE FOO SELECT COL1, COL2
olavk 16y ago
I may be confused, but according to Wikipedia http://en.wikipedia.org/wiki/Projection_%28relational_algebra%29 http://en.wikipedia.org/wiki/Projection_%28relational_algebr... it seems that in relational algebra notation the attribute names are written before the relation, since the relation is an argument to the projection function. This seem to me to be closer to SQL syntax.
- wvenable 16y ago
  The attribute names are written first, but it's like nested function calls: projection(selection(R)). The joins are 'evaluated' first, then selection (where), and then projection. I suspect that SQL was actually designed to match the notational order (but reversing the intent) they still got it wrong: to match the notation, it should be SELECT .. WHERE .. FROM.
  - olavk 16y ago
    Interesting point, but that would apply to function notation in general, not just relational algebra. a(b(c(x))) is "backwards" because the functions are evaluated in the opposite order than they are written. This is a flaw in math and in most programming languages! I suppose stack-based languages have it right, and the OO method chaining syntax in Linq and in e.g. JQuery has it right, since evaluation order is left-to-right.

koenigdavidmj 16y ago

You can also say b.select(a => a.x) if you want the more traditional syntax.

mullr 16y ago
I use this syntax all the time and greatly prefer it to the special 'from' keyword. I think it scares my co-workers a little less. There are a few cases where the from syntax is necessary, but it's not common.

kakuri 16y ago

I think tying language design to IDE design is absolutely brilliant. Languages are just a tool, IDEs are just a tool, we're missing brilliant opportunities if we neglect to design them synergistically.