6 ms·

I'm absolutely biased, as one of the rustc parser maintainers, but removing all redundancies of a languages syntax is actually terrible for usability. The fewer

I'm absolutely biased, as one of the rustc parser maintainers, but removing all redundancies of a languages syntax is actually terrible for usability. The fewer "landmarks" the parser has to work with, the harder job tooling has to provide feedback when something was written incorrectly and increases the likelihood of two unrelated concepts being a typo away, which won't be caught by the compiler. Increased verbosity doesn't have to mean reduced readability, as long as the syntax is regular and allows you to selectively skim parts of the code you don't currently care about.

lmm 4y ago
Syntactic noise absolutely reduces readability. Redundancy may have value sometimes, but ignoring the information that's already there (newlines and indentation) in favour of a separate, parallel track isn't actually giving you more chances to catch an error, because indentation that doesn't match the blocks or newlines in the middle of an expression are generally a warning at best.
- estebank 4y ago
  I can give you a straightforward example: the parser can recover from missing semicolons at the end of statements. The language could do automatic semicolon insertion a-la javascript. But then that means that all the ambiguous cases have to be handled anyways, either with a confusing error, or potentially subtly incorrect behavior. The parser uses whitespace to infer intent for this, if you encounter a statement starting keyword starting a new line when you expected a semicolon, confidence is high. We also use indentation levels to infer where missing closing braces should go. That mechanism is unreliable enough that I wouldn't want to have to have to rely on that for the actual language, but for recovery you can get away with incomplete solutions. Note that relying purely on whitespace significance is particularly problematic for expression oriented grammars like Rust's, as opposed to statement oriented like Python's.
  - simon_o 4y ago
    > could do automatic semicolon insertion a-la javascript If you want to make a good faith argument against semicolon inference, that's not the way of doing it.
simon_o 4y ago
It's not about removing redundancies or landmarks, it's about Rust having made some not-so-good choices. It's slowly becoming apparent to more people (e. g. compare the screeching a few years ago about Rust's wrong choice of <>/::<> generics to today), which I guess is why we see more of these huffy articles from Rust defenders.

lmm 4y ago

Syntactic noise absolutely reduces readability. Redundancy may have value sometimes, but ignoring the information that's already there (newlines and indentation) in favour of a separate, parallel track isn't actually giving you more chances to catch an error, because indentation that doesn't match the blocks or newlines in the middle of an expression are generally a warning at best.

estebank 4y ago
I can give you a straightforward example: the parser can recover from missing semicolons at the end of statements. The language could do automatic semicolon insertion a-la javascript. But then that means that all the ambiguous cases have to be handled anyways, either with a confusing error, or potentially subtly incorrect behavior. The parser uses whitespace to infer intent for this, if you encounter a statement starting keyword starting a new line when you expected a semicolon, confidence is high. We also use indentation levels to infer where missing closing braces should go. That mechanism is unreliable enough that I wouldn't want to have to have to rely on that for the actual language, but for recovery you can get away with incomplete solutions. Note that relying purely on whitespace significance is particularly problematic for expression oriented grammars like Rust's, as opposed to statement oriented like Python's.
- simon_o 4y ago
  > could do automatic semicolon insertion a-la javascript If you want to make a good faith argument against semicolon inference, that's not the way of doing it.

simon_o 4y ago

It's not about removing redundancies or landmarks, it's about Rust having made some not-so-good choices. It's slowly becoming apparent to more people (e. g. compare the screeching a few years ago about Rust's wrong choice of <>/::<> generics to today), which I guess is why we see more of these huffy articles from Rust defenders.