5 ms·

> int (ap1)[10] = &arr; Wow that's garbage syntax. With Go it would be var ap1 [10]int = &arr

by 38 2y ago

> int (*ap1)[10] = &arr; Wow that's garbage syntax. With Go it would be var ap1 *[10]int = &arr

pavlov 2y ago
Maybe you missed the part where this is C, you know, the language designed by many of the same people as Go but 35 years earlier. It would be a time warp worthy of the Rocky Horror Picture Show if C's design could take syntax ideas from Go.
rramadass 2y ago
I actually find the C syntax easier to read and understand.
- lifthrasiir 2y ago
  How about the following then? I can read them but by no means they are intuitive. int *x[10]; // How is this different from `ap1` above? int (*f (void))[10];
  - rramadass 2y ago
    These are all simple (not necessarily intuitive) if you know how operator binding works in C, (using braces to highlight); int *x[10]; ---> { int* } x[10]; int (*f (void))[10] ---> int { { (* {f (void) } ) } [10]; } The point is that once you have had some practice you can work it out and Go's syntax is not necessarily much better.
    - lifthrasiir 2y ago
      Your original comment said it "is easier to read and understand", not "can be worked out after some practice". Of course it is not like you should inline every `typedef`s into a single mess of complicated types, but you never said that you believe only simplest types should be used and C syntax is easier for them. In any case, I think Go is a clear winner here because all logical types are consecutive tokens. For example `f` in my example is (as you correctly parsed) a pointer to a function that returns an array of 10 integers, but that return type is normally written `int [10]` or `int NAME[10]`, while here is written in two chunks `int` and `[10]` with a big parenthesis inside.
      - rramadass 2y ago
        Again, my using "is easier to read and understand" was w.r.t. the parent's claim w.r.t. Go's syntax. You understood it wrong to mean an absolute general case. You need practice for complicated things and that is what i was pointing out with "can be worked out after some practice" and not that everything trivial needed practice. "Go is a clear winner here" is your claim and not necessarily one that i agree with since as mentioned, knowing the binding rules and a little practice complicated declarations are not that big of a deal.
        lifthrasiir 2y ago
        Agreed that it's not actually a big deal (hence "here"), but it does strengthen a point that the C syntax wasn't designed carefully after all. The current C type syntax was completely accidental and any reasonable design could have avoided that. If that was too late for some reason, one could have defined a new parallel syntax that solves this problem. In fact C++ did so via its new function declaration syntax `auto f(...) -> ...`. Guess why...
        rramadass 2y ago
        > The current C type syntax was completely accidental and any reasonable design could have avoided that. Absolutely baseless claim. The C syntax and language is the product of a small group (not a committee) of smart people with the goals of syntactical brevity, close to machine architecture (PDP-7/11) and the design goal of building along the path of BCPL->B->C. Dennis Ritchie himself explains the rationale in his paper The Development of the C Language and so one does not need to make untenable assumptions. The enduring success of the language (even in the face of all the developments since then in Computer HW and PLT) is proof of the validity of its design goals. Its "Abstract Machine" is simple and there is no complicated Object Model with the syntax merely being a thin veneer over a sequence of bytes. Contrast it with most modern languages (which seem to be designed to solve world peace/hunger and everything in between) and C appears more and more relevant these days. C++ used judiciously without a lot of "new features" introduced by the standards committee (the bane of the language) takes it to the next level sweet spot.
  - eMSF 2y ago
    Well, obviously it doesn't have parentheses. It's not like this is the only instance where adding parentheses affects the end result. You could write even more complex declarators (but don't have to), but that would not prove that some other syntax is inherently intuitive. Case in point, I cannot parse the Go syntax as I do not know Go. In my experience pointers to arrays are rather uncommon and I'm not sure that I've ever written a function returning one, having even less of a need for a pointer to such. (Thus out of all these, only your first example is somewhat common in practice.)
    - rramadass 2y ago
      Right. These are just "old chestnuts" used to scare C noobs particularly in interviews. IIRC the K&R C book itself had a example program to convert C declarations to English and also there exists a utility program called "cdecl" to do the same.
      - lifthrasiir 2y ago
        Better to use that English explanation as a model of readable syntax.
        rramadass 2y ago
        It is but you just have to know how to map it.
    - lifthrasiir 2y ago
      > I cannot parse the Go syntax as I do not know Go. Or you probably never even tried. You should be immediately able to parse it if I provide a hint that `*`, `&` and `[10]` mean roughly the same thing as C, because `*[10]int` has no reasonable reason to be parsed as an array of 10 copies of something. You can't do so in C.

> int (*ap1)[10] = &arr; Wow that's garbage syntax. With Go it would be var ap1 *[10]int = &arr

by 38 2y ago

> int (*ap1)[10] = &arr; Wow that's garbage syntax. With Go it would be var ap1 *[10]int = &arr

Maybe you missed the part where this is C, you know, the language designed by many of the same people as Go but 35 years earlier. It would be a time warp worthy of the Rocky Horror Picture Show if C's design could take syntax ideas from Go.

rramadass 2y ago

I actually find the C syntax easier to read and understand.

lifthrasiir 2y ago
How about the following then? I can read them but by no means they are intuitive. int *x[10]; // How is this different from `ap1` above? int (*f (void))[10];
- rramadass 2y ago
  These are all simple (not necessarily intuitive) if you know how operator binding works in C, (using braces to highlight); int *x[10]; ---> { int* } x[10]; int (*f (void))[10] ---> int { { (* {f (void) } ) } [10]; } The point is that once you have had some practice you can work it out and Go's syntax is not necessarily much better.
  - lifthrasiir 2y ago
    Your original comment said it "is easier to read and understand", not "can be worked out after some practice". Of course it is not like you should inline every `typedef`s into a single mess of complicated types, but you never said that you believe only simplest types should be used and C syntax is easier for them. In any case, I think Go is a clear winner here because all logical types are consecutive tokens. For example `f` in my example is (as you correctly parsed) a pointer to a function that returns an array of 10 integers, but that return type is normally written `int [10]` or `int NAME[10]`, while here is written in two chunks `int` and `[10]` with a big parenthesis inside.
    - rramadass 2y ago
      Again, my using "is easier to read and understand" was w.r.t. the parent's claim w.r.t. Go's syntax. You understood it wrong to mean an absolute general case. You need practice for complicated things and that is what i was pointing out with "can be worked out after some practice" and not that everything trivial needed practice. "Go is a clear winner here" is your claim and not necessarily one that i agree with since as mentioned, knowing the binding rules and a little practice complicated declarations are not that big of a deal.
      - lifthrasiir 2y ago
        Agreed that it's not actually a big deal (hence "here"), but it does strengthen a point that the C syntax wasn't designed carefully after all. The current C type syntax was completely accidental and any reasonable design could have avoided that. If that was too late for some reason, one could have defined a new parallel syntax that solves this problem. In fact C++ did so via its new function declaration syntax `auto f(...) -> ...`. Guess why...
        rramadass 2y ago
        > The current C type syntax was completely accidental and any reasonable design could have avoided that. Absolutely baseless claim. The C syntax and language is the product of a small group (not a committee) of smart people with the goals of syntactical brevity, close to machine architecture (PDP-7/11) and the design goal of building along the path of BCPL->B->C. Dennis Ritchie himself explains the rationale in his paper The Development of the C Language and so one does not need to make untenable assumptions. The enduring success of the language (even in the face of all the developments since then in Computer HW and PLT) is proof of the validity of its design goals. Its "Abstract Machine" is simple and there is no complicated Object Model with the syntax merely being a thin veneer over a sequence of bytes. Contrast it with most modern languages (which seem to be designed to solve world peace/hunger and everything in between) and C appears more and more relevant these days. C++ used judiciously without a lot of "new features" introduced by the standards committee (the bane of the language) takes it to the next level sweet spot.
- eMSF 2y ago
  Well, obviously it doesn't have parentheses. It's not like this is the only instance where adding parentheses affects the end result. You could write even more complex declarators (but don't have to), but that would not prove that some other syntax is inherently intuitive. Case in point, I cannot parse the Go syntax as I do not know Go. In my experience pointers to arrays are rather uncommon and I'm not sure that I've ever written a function returning one, having even less of a need for a pointer to such. (Thus out of all these, only your first example is somewhat common in practice.)
  - rramadass 2y ago
    Right. These are just "old chestnuts" used to scare C noobs particularly in interviews. IIRC the K&R C book itself had a example program to convert C declarations to English and also there exists a utility program called "cdecl" to do the same.
    - lifthrasiir 2y ago
      Better to use that English explanation as a model of readable syntax.
      - rramadass 2y ago
        It is but you just have to know how to map it.
  - lifthrasiir 2y ago
    > I cannot parse the Go syntax as I do not know Go. Or you probably never even tried. You should be immediately able to parse it if I provide a hint that `*`, `&` and `[10]` mean roughly the same thing as C, because `*[10]int` has no reasonable reason to be parsed as an array of 10 copies of something. You can't do so in C.