4 ms·

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

by 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?
layer8 6y ago
> how do you comment out a region with comments inside? s/^/\/\// Or just Ctrl+/ in some IDEs. That’s also better than multiline comments because it provides indentation levels, and because it’s visible on every line that you’re inside a comment (and no need to place artificial “*”s at the start of in-comment lines). If I were to design a new programming language, I would only provide single-line comment syntax and relegate the multiline use case to editor support (i.e. for marking a line range and commenting it out/in).
- patrec 6y ago
  I agree that // is the way to go but this only landed in C99, so almost 3 decades after the fact (~5 if you care about msvc support).
  - layer8 6y ago
    Good point. Even before C99, I would be using C++ as a “better C” for reasons like that.

by patrec 6y ago

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?

layer8 6y ago

> how do you comment out a region with comments inside? s/^/\/\// Or just Ctrl+/ in some IDEs. That’s also better than multiline comments because it provides indentation levels, and because it’s visible on every line that you’re inside a comment (and no need to place artificial “*”s at the start of in-comment lines). If I were to design a new programming language, I would only provide single-line comment syntax and relegate the multiline use case to editor support (i.e. for marking a line range and commenting it out/in).

patrec 6y ago
I agree that // is the way to go but this only landed in C99, so almost 3 decades after the fact (~5 if you care about msvc support).
- layer8 6y ago
  Good point. Even before C99, I would be using C++ as a “better C” for reasons like that.