4 ms·

I always found this to be one of C's (and it's descendants) more ridiculous aspects. You should not need an entire algorithm just to mentally parse a declarati

I always found this to be one of C's (and it's descendants) more ridiculous aspects. You should not need an entire algorithm just to mentally parse a declaration. The rules should be sufficiently straight forward so that the advanced pattern matching in our brains should suffice. It is excusable since C is old, but ridiculous nonetheless.

busfahrer 6y ago
I recall reading that the reason for this was that it made the implementation of the compiler a lot easier
qsort 6y ago
Pretty much everyone agrees that the "best" syntax for declarations is Go-style "x: int;" and not C-style "int x;", but to be fair you don't see declarations like that very often. Once you understand the (admittedly bad) syntax for "pointer to function returning type" as opposed to "function returning pointer to type", most declarations you're likely to find aren't hard to read. I mantain some C code as part of my job and I don't recall declarations ever being a problem to mentally parse.
- coldpie 6y ago
  The only truly difficult declarations I've encountered dealing with real-world C code is mixing pointers, const, and arrays. Pointer to const str, easy: const char *str; array of pointers to const strs, also fairly easy: const char *strs[4]; const array of pointers to const strs... umm... const char *const strs[4]; I think? Which const does what? This is a dummy example, but real-world examples can be a bit less obvious, as you sometimes have to elide the array length: const char* const* enabledExtensionNames; From: https://www.khronos.org/registry/OpenXR/specs/1.0/man/html/openxr.html#_xrinstancecreateinfo3 https://www.khronos.org/registry/OpenXR/specs/1.0/man/html/o... What is this, again?
patrec 6y ago
It really is not excusable, since a) As far as I'm aware no other languages at that time suffered from this ridiculous defect. b) It doesn't really seem like the thing where you'd need 20/20 hindsight to figure out it's a bad idea. The same applies to a lot of the lasting braindamage C has inflicted on the computing industry. It's just that people have been numbed to it thanks to constant exposure as every single popular language in the last twenty years has aped at least some of C's defects. Other major problems either introduced or spread by C include: - the execrable octal number syntax - fallthrough-as-default case statements - non-first class arrays - strings that don't know their length - the unsafe/ub-by-default mindset - braindamaged linking - abusing = for assignment, combined with making assignment an expression. For most of C's history you'd not even get a compiler warning for if (a = b) ... - generally there is a very unhealthy mix of of being highly imperative and statement based and at the same time having a lot of ad hoc ways to "expressionify" things (comma operator, ternary, pre-and-post increment/decrement), which, combined with undefined order of evaluation, encourages all sorts of errors. - error-prone optional braces syntax (dangling if etc.) - remainder (rather than modulo) operator - very nasty implicit number promotion rules - messed up operator precedence - "if (!pred(x) || a <= b && y)" for "if not pred(x) or a =< b and y" - the c pre-processor - a broken comment syntax (how do you comment out a region with comments inside?) - spuriously non-grepable function definitions/declarations
- amboar 6y ago
  > - braindamaged linking I mean, it's simple, but brain-damaged? > - "if (!pred(x) || a <= b && y)" for "if not pred(x) or a =< b and y" I guess more parentheses would improve the clarity but your English translation suffers the same problem as the code > the c pre-processor > - a broken comment syntax (how do you comment out a region with comments inside?) Use the pre-processor that you complained about #if 0 ... #endif
  - patrec 6y ago
    > I mean, it's simple, but brain-damaged? Linking is not a hard problem at all. For the last 40 years with a sane language you'd say "I depend on A, B and C" (in any order) and often that would happen implicitly as part of writing your code rather than having to screw around with some abortion of a build system as in C or C++ land. Things would just work, and quickly at that; the fact that there was a linking step would hardly ever even enter your conscious awareness with Turbo Pascal for example. By contrast, in C and C++ you get: - Often horrendously slow linkage, so slow in fact that it can dominate build times. - Massive complexity. Contrary to what you claim, linking with C isn't simple at all (although it ought to be, especially considering how stupid it is!). Have you ever looked at a C linker manpage or obj format description? Also, because linker performance of GNU ld is so abysmal, people have written several replacements (gold, lld) and there are all sorts of exciting issues associated with getting different compilers talk to different linkers on different platforms/toolchains as well. There is an enormous cottage industry of (mostly terrible) tools around linking in C. And this complexity is before we even try anything like LTO or cross-platform builds. - Lots of exciting challenges for even the most trivial tasks ("I'd like a statically linked artifact, please", "I'd like to be able to debug this, please"). - You need to specify link order, and the order matters and can introduce obvious as well as more subtle failures. - Lots of random weirdness (e.g. djb errno patches). - Little gems like this: > echo $'#include<stdio.h>\nvoid hello() {puts("hello world!");} int main() { hello();}' | gcc -xc - && ./a.out hello world! vs > echo $'#include<stdio.h>\ninline void hello() {puts("hello world!");} int main() { hello();}' | gcc -xc - && ./a.out /usr/bin/ld: /tmp/ccYdbjTB.o: in function `main': :(.text+0xe): undefined reference to `hello' collect2: error: ld returned 1 exit status How is any of this not braindamaged? Have you never used (a possibly ancient) language which did not suffer from any of these problems? > your English translation suffers the same problem as the code Sorry, I wasn't very clear here: what I meant to convey is that C syntax for logical operations is bizarre and unreadable. Why the bogus parens after the if? Why replace "not" with a weird symbol that does not in any way traditionally relate to logical negation and is moreover super easy to overlook? > Use the pre-processor that you complained about If someone sets my leg on fire, am I supposed to feel grateful when he pisses on it?
londons_explore 6y ago
A simple fix to the language would be to require everything to either be on the left or the right of the variable. I wonder why that wasn't done?

busfahrer 6y ago

I recall reading that the reason for this was that it made the implementation of the compiler a lot easier

qsort 6y ago

Pretty much everyone agrees that the "best" syntax for declarations is Go-style "x: int;" and not C-style "int x;", but to be fair you don't see declarations like that very often. Once you understand the (admittedly bad) syntax for "pointer to function returning type" as opposed to "function returning pointer to type", most declarations you're likely to find aren't hard to read. I mantain some C code as part of my job and I don't recall declarations ever being a problem to mentally parse.

coldpie 6y ago
The only truly difficult declarations I've encountered dealing with real-world C code is mixing pointers, const, and arrays. Pointer to const str, easy: const char *str; array of pointers to const strs, also fairly easy: const char *strs[4]; const array of pointers to const strs... umm... const char *const strs[4]; I think? Which const does what? This is a dummy example, but real-world examples can be a bit less obvious, as you sometimes have to elide the array length: const char* const* enabledExtensionNames; From: https://www.khronos.org/registry/OpenXR/specs/1.0/man/html/openxr.html#_xrinstancecreateinfo3 https://www.khronos.org/registry/OpenXR/specs/1.0/man/html/o... What is this, again?

patrec 6y ago

It really is not excusable, since a) As far as I'm aware no other languages at that time suffered from this ridiculous defect. b) It doesn't really seem like the thing where you'd need 20/20 hindsight to figure out it's a bad idea. The same applies to a lot of the lasting braindamage C has inflicted on the computing industry. It's just that people have been numbed to it thanks to constant exposure as every single popular language in the last twenty years has aped at least some of C's defects. Other major problems either introduced or spread by C include: - the execrable octal number syntax - fallthrough-as-default case statements - non-first class arrays - strings that don't know their length - the unsafe/ub-by-default mindset - braindamaged linking - abusing = for assignment, combined with making assignment an expression. For most of C's history you'd not even get a compiler warning for if (a = b) ... - generally there is a very unhealthy mix of of being highly imperative and statement based and at the same time having a lot of ad hoc ways to "expressionify" things (comma operator, ternary, pre-and-post increment/decrement), which, combined with undefined order of evaluation, encourages all sorts of errors. - error-prone optional braces syntax (dangling if etc.) - remainder (rather than modulo) operator - very nasty implicit number promotion rules - messed up operator precedence - "if (!pred(x) || a <= b && y)" for "if not pred(x) or a =< b and y" - the c pre-processor - a broken comment syntax (how do you comment out a region with comments inside?) - spuriously non-grepable function definitions/declarations

amboar 6y ago
> - braindamaged linking I mean, it's simple, but brain-damaged? > - "if (!pred(x) || a <= b && y)" for "if not pred(x) or a =< b and y" I guess more parentheses would improve the clarity but your English translation suffers the same problem as the code > the c pre-processor > - a broken comment syntax (how do you comment out a region with comments inside?) Use the pre-processor that you complained about #if 0 ... #endif
- patrec 6y ago
  > I mean, it's simple, but brain-damaged? Linking is not a hard problem at all. For the last 40 years with a sane language you'd say "I depend on A, B and C" (in any order) and often that would happen implicitly as part of writing your code rather than having to screw around with some abortion of a build system as in C or C++ land. Things would just work, and quickly at that; the fact that there was a linking step would hardly ever even enter your conscious awareness with Turbo Pascal for example. By contrast, in C and C++ you get: - Often horrendously slow linkage, so slow in fact that it can dominate build times. - Massive complexity. Contrary to what you claim, linking with C isn't simple at all (although it ought to be, especially considering how stupid it is!). Have you ever looked at a C linker manpage or obj format description? Also, because linker performance of GNU ld is so abysmal, people have written several replacements (gold, lld) and there are all sorts of exciting issues associated with getting different compilers talk to different linkers on different platforms/toolchains as well. There is an enormous cottage industry of (mostly terrible) tools around linking in C. And this complexity is before we even try anything like LTO or cross-platform builds. - Lots of exciting challenges for even the most trivial tasks ("I'd like a statically linked artifact, please", "I'd like to be able to debug this, please"). - You need to specify link order, and the order matters and can introduce obvious as well as more subtle failures. - Lots of random weirdness (e.g. djb errno patches). - Little gems like this: > echo $'#include<stdio.h>\nvoid hello() {puts("hello world!");} int main() { hello();}' | gcc -xc - && ./a.out hello world! vs > echo $'#include<stdio.h>\ninline void hello() {puts("hello world!");} int main() { hello();}' | gcc -xc - && ./a.out /usr/bin/ld: /tmp/ccYdbjTB.o: in function `main': :(.text+0xe): undefined reference to `hello' collect2: error: ld returned 1 exit status How is any of this not braindamaged? Have you never used (a possibly ancient) language which did not suffer from any of these problems? > your English translation suffers the same problem as the code Sorry, I wasn't very clear here: what I meant to convey is that C syntax for logical operations is bizarre and unreadable. Why the bogus parens after the if? Why replace "not" with a weird symbol that does not in any way traditionally relate to logical negation and is moreover super easy to overlook? > Use the pre-processor that you complained about If someone sets my leg on fire, am I supposed to feel grateful when he pisses on it?

londons_explore 6y ago

A simple fix to the language would be to require everything to either be on the left or the right of the variable. I wonder why that wasn't done?