3 ms·

> C syntax is just horrible. All syntax is horrible. Rust is the en vogue tool of the moment and it's objectively harder to read than C. Python used to be cl

by ajross 2y ago

> C syntax is just horrible. All syntax is horrible. Rust is the en vogue tool of the moment and it's objectively harder to read than C. Python used to be clean and now it's sort of a mess. C++, well... Some languages try to get away with having simple syntax though. Javascript is in this camp, as of course are all the Lisps. And the result is that you end up drowning in a sea of complicated semantics instead, c.f. the famous "wat" video or the fact that every sexpr macro-ized DSL works like its own little butterfly. You can't win. C is fine. Could you do better if you started from scratch? Sure. Would it last? No.

nicoburns 2y ago
> 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.
tialaramex 2y ago
> Rust is the en vogue tool of the moment and it's objectively harder to read than C If this is "objectively" true please link the study which was able to somehow measure that.
- shrimp_emoji 2y ago
  It's subjectively objective. Rust syntax is hard and spiky, like a crab's carapace.
mmaniac 2y ago
C syntax is only better than Rust's because of its simplicity. If C were as semantically rich as Rust it'd be more of an unreadable mess. That said, C's syntactic missteps appear to be accidents, while Rust delights itself in being ugly.
samatman 2y ago
There are several languages which are motivated by providing a better experience than C in C's native domain. Rust is not one of those languages. Rust has an innovative, but highly opinionated, memory model: the premise is writing high performance memory safe programs, with 'zero cost' abstractions and so on. You might write a program in Rust rather than C in the way you might write a program in Go rather than C: because the application is better modeled in a language which isn't C. For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with an unsafe block. But no, C is not fine. It has a stunning amount of own-goals making it pointlessly difficult to write a program with a fine-grained memory policy that is correct. C also doesn't have a syntax at all until you've run CPP, and then you have a context-sensitive parse. Neither of these are mere technical formalities, they actively inhibit understanding a C program.
- steveklabnik 2y ago
  > For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with an unsafe block. This is often said, but does not reflect reality. At this point, we have tons of bare-metal and OS-level Rust code existing in the world, and it still has very little unsafe overall.
  - samatman 2y ago
    Granted, that was put poorly, let me try again. What I said doesn't in fact have the implication you took from it, but I didn't explain myself particularly well. There are many programs one can write in C, or Zig, or some other manual-transmission language, which, if you wrote them in Rust, would just be wrapped in a big unsafe block. That isn't because those programs have memory errors in them, it's because they have a memory policy which safe Rust doesn't support. Examples include certain garbage collection algorithms, and embedded programs where all memory is pre-allocated and references shared somewhat promiscuously. It's possible to write analogous programs in safe Rust, but not the same program. The space of programs which are both correct, and not possible in safe Rust, is infinite. They don't come with compiler guarantees, so other support is needed. CompCert is a good example of an approach to that which isn't Rust's. Keeping in mind that I'm referring to specific programs, not "a program which solves the problem domain". Otherwise we could just say that since you can write a program which solves the problem domain in Python, there's no use for Rust. That wouldn't lead to a productive conversation, would it. People still choose C over Rust, even knowing what Rust is. This isn't the early days of the evangelism strike force, Steve. The above is why. Sometimes they might be better off writing the analogous program in Rust, or seeing if they can get the program they're trying to write with limited use of unsafe blocks. Sometimes not. I know you've put a lot of work into your hammer over the years, but it's never going to be the only tool in the box. Languages, and I'm thinking of Zig here, which make it easier to correctly implement a memory policy which doesn't happen to be Rust's, should be applauded, and not called "a massive step backwards for the industry <pouty sad face>". Like it or not, they're working in the same domain as Rust, based on different principles. But yes, there is an infinitely large class of programs which can be written in the embedded and OS spaces, in Rust, with very little unsafe overall. I didn't intend to imply otherwise.

by ajross 2y ago

nicoburns 2y ago

> 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.

tialaramex 2y ago

> Rust is the en vogue tool of the moment and it's objectively harder to read than C If this is "objectively" true please link the study which was able to somehow measure that.

shrimp_emoji 2y ago
It's subjectively objective. Rust syntax is hard and spiky, like a crab's carapace.

mmaniac 2y ago

C syntax is only better than Rust's because of its simplicity. If C were as semantically rich as Rust it'd be more of an unreadable mess. That said, C's syntactic missteps appear to be accidents, while Rust delights itself in being ugly.

samatman 2y ago

There are several languages which are motivated by providing a better experience than C in C's native domain. Rust is not one of those languages. Rust has an innovative, but highly opinionated, memory model: the premise is writing high performance memory safe programs, with 'zero cost' abstractions and so on. You might write a program in Rust rather than C in the way you might write a program in Go rather than C: because the application is better modeled in a language which isn't C. For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with an unsafe block. But no, C is not fine. It has a stunning amount of own-goals making it pointlessly difficult to write a program with a fine-grained memory policy that is correct. C also doesn't have a syntax at all until you've run CPP, and then you have a context-sensitive parse. Neither of these are mere technical formalities, they actively inhibit understanding a C program.

steveklabnik 2y ago
> For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with an unsafe block. This is often said, but does not reflect reality. At this point, we have tons of bare-metal and OS-level Rust code existing in the world, and it still has very little unsafe overall.
- samatman 2y ago
  Granted, that was put poorly, let me try again. What I said doesn't in fact have the implication you took from it, but I didn't explain myself particularly well. There are many programs one can write in C, or Zig, or some other manual-transmission language, which, if you wrote them in Rust, would just be wrapped in a big unsafe block. That isn't because those programs have memory errors in them, it's because they have a memory policy which safe Rust doesn't support. Examples include certain garbage collection algorithms, and embedded programs where all memory is pre-allocated and references shared somewhat promiscuously. It's possible to write analogous programs in safe Rust, but not the same program. The space of programs which are both correct, and not possible in safe Rust, is infinite. They don't come with compiler guarantees, so other support is needed. CompCert is a good example of an approach to that which isn't Rust's. Keeping in mind that I'm referring to specific programs, not "a program which solves the problem domain". Otherwise we could just say that since you can write a program which solves the problem domain in Python, there's no use for Rust. That wouldn't lead to a productive conversation, would it. People still choose C over Rust, even knowing what Rust is. This isn't the early days of the evangelism strike force, Steve. The above is why. Sometimes they might be better off writing the analogous program in Rust, or seeing if they can get the program they're trying to write with limited use of unsafe blocks. Sometimes not. I know you've put a lot of work into your hammer over the years, but it's never going to be the only tool in the box. Languages, and I'm thinking of Zig here, which make it easier to correctly implement a memory policy which doesn't happen to be Rust's, should be applauded, and not called "a massive step backwards for the industry <pouty sad face>". Like it or not, they're working in the same domain as Rust, based on different principles. But yes, there is an infinitely large class of programs which can be written in the embedded and OS spaces, in Rust, with very little unsafe overall. I didn't intend to imply otherwise.