4 ms·

Another point to this is that we should switch to writing the numbers in the right order too: 123 should be three-hundred-twenty-one. This way, as soon as you

Another point to this is that we should switch to writing the numbers in the right order too: 123 should be three-hundred-twenty-one. This way, as soon as you type "1", it is truly one, you add a "2" and you know that's adding twenty... IIRC Arabic gets this right! /s

teo_zero 1y ago
Haha. Except in Arabic numbers are written as in English.
- necovek 1y ago
  Right, but all the other letters are written right-to-left too :)
zahlman 1y ago
You joke, but you highlight an important problem with the argument. The idea is that we write `foo.bar`, where `foo` is in scope, exactly because `foo` is in scope. We don't write `bar from foo` or whatever, because it would be hard to reverse search the things that have `bar` in them. But which is more likely: will `foo` be Liskov-substitutable for `bar`, or will other things that contain a `bar` have a `bar` of a Liskov-substitutable type? Which is to say, the author is depending on a particularly idiosyncratic meaning of "valid". That said, the problem the author describes at the beginning can be easily worked around, if you like this kind of workflow: words_on_lines = [st # 'str' is a plausible autocompletion words_on_lines = [str.sp # must be either 'split' or 'splitlines', unless 'str' is shadowed words_on_lines = [str.split(line) for # 'line in' can be suggested words_on_lines = [str.split(line) for line in text.splitlines()] # IDE can automatically check type and refactor the idiom And it also isn't at all true that IDEs work left to right. They're constantly auto-typing the balancing close parentheses/braces/brackets for me and it's never clear to me what the intended flow is for moving past what was automatically typed, or whether manually typing that bracket explicitly (since I'm in my own "automatic typing") will double it up or not. There's nothing preventing the IDE from expecting you to type the clauses of the comprehension in a different order and I wouldn't at all be surprised to hear that someone has already implemented this.

teo_zero 1y ago

Haha. Except in Arabic numbers are written as in English.

necovek 1y ago
Right, but all the other letters are written right-to-left too :)

zahlman 1y ago

You joke, but you highlight an important problem with the argument. The idea is that we write `foo.bar`, where `foo` is in scope, exactly because `foo` is in scope. We don't write `bar from foo` or whatever, because it would be hard to reverse search the things that have `bar` in them. But which is more likely: will `foo` be Liskov-substitutable for `bar`, or will other things that contain a `bar` have a `bar` of a Liskov-substitutable type? Which is to say, the author is depending on a particularly idiosyncratic meaning of "valid". That said, the problem the author describes at the beginning can be easily worked around, if you like this kind of workflow: words_on_lines = [st # 'str' is a plausible autocompletion words_on_lines = [str.sp # must be either 'split' or 'splitlines', unless 'str' is shadowed words_on_lines = [str.split(line) for # 'line in' can be suggested words_on_lines = [str.split(line) for line in text.splitlines()] # IDE can automatically check type and refactor the idiom And it also isn't at all true that IDEs work left to right. They're constantly auto-typing the balancing close parentheses/braces/brackets for me and it's never clear to me what the intended flow is for moving past what was automatically typed, or whether manually typing that bracket explicitly (since I'm in my own "automatic typing") will double it up or not. There's nothing preventing the IDE from expecting you to type the clauses of the comprehension in a different order and I wouldn't at all be surprised to hear that someone has already implemented this.