[rileymat2]

I like it starting with the desired output columns, often when I work with a db quite a bit and have common naming conventions that’s all I need to know.

Even writing queries I think in terms of outputs then build the query from there.

I am blanking about the advantages of starting with from, people clearly share your view, but I have no idea why.

Maybe it comes from my C++ background where return type comes first, then function name, then inputs.

[arzig]

Ability to tab complete columns in an interactive settings.

If I’m in psql I can tab complete columns in the where clause but not in the select because I haven’t actually given any information about what I’m selecting from yet.

[rileymat2]

This feels like a tradeoff we make where a convenience while writing once harms long term readability?

But that is a valid usecase!

[duped]

Imagine if methods on your C++ classes had to be called like method(object) instead of object.method(). While it's a meaningless syntactic difference, the latter makes autocomplete in an IDE possible.

[rileymat2]

Sure, in that very small example, if you don't care internal about visibility.

But method(object1, object2, object3, object4) is different than object.method().

[duped]

I don't think visibility is important, since you want autocomplete to work both in public and private methods. It would be a crappy IDE experience if you couldn't autocomplete on private methods within other private methods.

And sure, multimethods are too complex for naive autocompletion. But it's useful for people to have tooling that can say "given an input tell me what outputs are possible" because that's how we write code.