3 ms·

> Rust is the en vogue tool of the moment and it's objectively harder to read than C I think you're just used to C syntax. I find Rust syntax much easier to re

> Rust is the en vogue tool of the moment and it's objectively harder to read than C I think you're just used to C syntax. I find Rust syntax much easier to read than C syntax (and that was already true when I didn't know either language well).

ajross 2y ago
Meh. Grandparent who thinks "C is horrible" just isn't used to C. Familiarity breeds facility, that's no surprise. But no, Rust is just bad at this point given all the stuff that's been added and all the historical idioms that were pushed and then abandoned. It's not C++ bad, but it's objectively "worse" than C whose quirks all fit in a tiny K&R paperback.
- leetcrew 2y ago
  it's subjective to an extent, but requiring a "reverse spiral rule" (which itself has exceptions) to understand inline types is about as close to objectively bad as it gets. rust surely has it's issues, but reading types is not one of them. whatever you put inside the <> of a outermost symbol is a straightforward tree parse.
  - jstimpfle 2y ago
    The "reverse spiral rule" is a myth and that website should be shut down. It only adds confusion for the already confused. C type syntax has a simple guiding principle, there is no type syntax and "declaration follows usage" i.e. normal expression syntax. A few ugly additions that don't cleanly fit in this model were made later for practical reasons, but they don't change the basic idea, which is that there is so little to C type syntax that you can barely see it (which may also be why it's so easy to read once you've grokked it).
- kibwen 2y ago
  If anything is objectively wrong, it's C's grammar, and it's not even close. When you have an entire Wikipedia article dedicated to how infamously hard your language is to parse, you have no choice but to admit that you've messed up: https://en.wikipedia.org/wiki/Lexer_hack https://en.wikipedia.org/wiki/Lexer_hack And let's not forget: https://en.wikipedia.org/wiki/Dangling_else https://en.wikipedia.org/wiki/Dangling_else
  - uecker 2y ago
    Having written a C parser, C is not hard to parse. It does not fit some nice model, and if you assume this and don't know about the issues, you might waste your time. It iis still simple to write a C parser.
  - jstimpfle 2y ago
    C itself is not that hard to parse. The "lexer hack" thing is a theoretical impurity but it just means you have to add types to a type table -- and probably open and close scopes -- while parsing. The preprocessor though seems to be pretty annoying. C++ must be comparatively a lot harder to parse -- C++ syntax is a huge amount of complexity added to a system that wasn't designed with that in mind. That you link "Dangling else" is curious. The wikipedia page talks about "ambiguity" but in my mind it's no different than the ambiguity in "a + b * c", does it mean "(a + b) * c" or "a + (b * c)"? Well, make a choice and write it down.
    - skitter 2y ago
      > Well, make a choice and write it down. Or don't and don't allow unnecessary ambiguity. For * and +, there's a agreed upon order of operations far more universal than a programming language, but it's sensible to use a partial order so nobody is mistaken about whether e.g. logical or and bitshift binds tighter. Similary C counld have just not have allowed omitting the braces around single-line else clauses and would have been a simpler language for it.
      - ajross 2y ago
        > For * and +, there's a agreed upon order of operations So... we collectively made a choice and wrote it down, then? I think you whooshed on the point. The if/else ambiguity is just a precedence rule, like many others in the expression grammar of every (well, every non-lisp) language that exists.
        kibwen 2y ago
        Needing to specify associativity for operations that have absolutely no reason to be ambiguous in the first place is a flaw of language design. It's needless complexity. Isn't C supposed to be a "simple" language?

ajross 2y ago

Meh. Grandparent who thinks "C is horrible" just isn't used to C. Familiarity breeds facility, that's no surprise. But no, Rust is just bad at this point given all the stuff that's been added and all the historical idioms that were pushed and then abandoned. It's not C++ bad, but it's objectively "worse" than C whose quirks all fit in a tiny K&R paperback.

leetcrew 2y ago
it's subjective to an extent, but requiring a "reverse spiral rule" (which itself has exceptions) to understand inline types is about as close to objectively bad as it gets. rust surely has it's issues, but reading types is not one of them. whatever you put inside the <> of a outermost symbol is a straightforward tree parse.
- jstimpfle 2y ago
  The "reverse spiral rule" is a myth and that website should be shut down. It only adds confusion for the already confused. C type syntax has a simple guiding principle, there is no type syntax and "declaration follows usage" i.e. normal expression syntax. A few ugly additions that don't cleanly fit in this model were made later for practical reasons, but they don't change the basic idea, which is that there is so little to C type syntax that you can barely see it (which may also be why it's so easy to read once you've grokked it).
kibwen 2y ago
If anything is objectively wrong, it's C's grammar, and it's not even close. When you have an entire Wikipedia article dedicated to how infamously hard your language is to parse, you have no choice but to admit that you've messed up: https://en.wikipedia.org/wiki/Lexer_hack https://en.wikipedia.org/wiki/Lexer_hack And let's not forget: https://en.wikipedia.org/wiki/Dangling_else https://en.wikipedia.org/wiki/Dangling_else
- uecker 2y ago
  Having written a C parser, C is not hard to parse. It does not fit some nice model, and if you assume this and don't know about the issues, you might waste your time. It iis still simple to write a C parser.
- jstimpfle 2y ago
  C itself is not that hard to parse. The "lexer hack" thing is a theoretical impurity but it just means you have to add types to a type table -- and probably open and close scopes -- while parsing. The preprocessor though seems to be pretty annoying. C++ must be comparatively a lot harder to parse -- C++ syntax is a huge amount of complexity added to a system that wasn't designed with that in mind. That you link "Dangling else" is curious. The wikipedia page talks about "ambiguity" but in my mind it's no different than the ambiguity in "a + b * c", does it mean "(a + b) * c" or "a + (b * c)"? Well, make a choice and write it down.
  - skitter 2y ago
    > Well, make a choice and write it down. Or don't and don't allow unnecessary ambiguity. For * and +, there's a agreed upon order of operations far more universal than a programming language, but it's sensible to use a partial order so nobody is mistaken about whether e.g. logical or and bitshift binds tighter. Similary C counld have just not have allowed omitting the braces around single-line else clauses and would have been a simpler language for it.
    - ajross 2y ago
      > For * and +, there's a agreed upon order of operations So... we collectively made a choice and wrote it down, then? I think you whooshed on the point. The if/else ambiguity is just a precedence rule, like many others in the expression grammar of every (well, every non-lisp) language that exists.
      - kibwen 2y ago
        Needing to specify associativity for operations that have absolutely no reason to be ambiguous in the first place is a flaw of language design. It's needless complexity. Isn't C supposed to be a "simple" language?