Remix clone Hacker News

Yes it comes from a desire to impose intuition from other contexts onto something instead of building intuition with that thing.

SQL is a declarative language. The ordering of the statements was carefully thought through.

I will say it's harmless though, the clauses don't have any dependency in terms of meaning so it's fine to just allow them to be reordered in terms of the meaning of the query, but that's true of lots and lots of things in programming and just having a convention is usually better than allowing anything.

For example, you could totally allow this to be legal:

  def
      for x in whatever:
          print(x)
  print_whatever(whatever):

There's nothing ambiguous about it, but why? Like if you are used to seeing it one way it just makes it more confusing to read, and if you aren't used to seeing it the normal way you should at least somewhat master something before you try to improve it through cosmetic tweaks.

I think you see this all the time, people try to impose their own comfort onto things for no actual improvement.

▲ whstl a day ago | parent | next [-]

No, it comes from wanting to make autocompletion easier and to make variable scoping/method ordering make sense within LINQ. It is an actual improvement in this regard.

LINQ popularized it and others followed. It does what it says.

Btw: saying that "people try to impose their own comfort" is uncalled for.

▲

ltbarcly3 20 hours ago | parent [-]

In that case you are just objectively incorrect, you can build a far, far more efficient autocomplete in the standard query order. I will guess something like half as many keystrokes to type the same select and from clauses. You are imagining a very niave autocomplete that can only guess columns after it knows the tables, but in reality you can guess most of the columns, including the first one, the tables, and the aliases. Names in dbs are incredibly sparse, and duplicate names don't make autocomplete less effective.

If you are right about why they did it its even dumber than my reason, they are changing a language grammar to let them make a much worse solution to the same problem.

▲

whstl 10 hours ago | parent | next [-]

An autocomplete that shows only the column names of the desired table BEFORE the from clause is typed by the user would require a time machine.

Sure you can do something that is close enough, but the LINQ authors were looking for precision in the autocompletion and for the LINQ query to have the same ordering as expression syntax.

The goals of this syntax are very precise and people seem to like it. Once again: calling it dumb is uncalled for.

	▲	ltbarcly3 4 hours ago \| parent [-]
		So you want it to work this way, regardless of how well autocomplete works? Sounds like its about your personal comfort to make it work like another system you are more familiar with, which is exactly what I suggested. It doesn't require a time machine, just a basic understanding of statistics or probability.

▲

pests 10 hours ago | parent | prev [-]

I don’t want to type any column names. When you start with FROM the only autocomplete suggestions available are the columns from the specific table, not the entire database. How many columns do I need to type before you can single down a single table? What if you have multiple tables with the same column names?

	▲	ltbarcly3 4 hours ago \| parent [-]
		This is extremely easy to check. It depends on the schema. If your tables have very heterogeneous column names, like 1 column will identify any table on average. There will be some duplicates but the median columns will be one or two, but generally you can even complete those after a few characters. If your database has very homogenous column names you don't need to identify a single table for autocomplete to be very precise, unless there is no correlation between column name co occurence within tables. However if there is no correlation you are back to very low number of columns to identify the table.

▲ a day ago | parent | prev [-]

[deleted]