C’s Biggest Mistake (2009) • Hacker News Board

Re: C’s Biggest Mistake (2009)

#211

Post by knaq » Sun, Sep 13, 2020, 4:24 AM UTC

brundolf wrote: post #195

knaq wrote: post #192

Earlier quoted context omitted.

I realize exactly how inefficient it would be. If it hurts, don't do that. I'm the kind of person who optimizes with assembly, counts cache misses, counts TLB misses, and pays attention to pipeline stalls. I definitely understand the performance implications, and I definitely wouldn't be passing arrays around all the time. That said, I want the ability. I want the language to let me do what I want, and on rare occasi…

Ok, but you didn't just say this should be possible, you said it should be the default best-practice . Even if it were useful in a handful of cases, this would be a terrible default way of doing things.

I didn't say it should be the default, but yes it should be. It is for structs.

We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy)

Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually want to pass by value. It works fine.

I have frequently seen beginners struggle with C arrays and pointers. Part of the trouble is that you can't pass an array. You can try, but the compiler quietly substitutes different code. It's a source of confusion, generating incorrect mental models of what is going on.

Re: C’s Biggest Mistake (2009)

#212

Post by ComputerGuru » Sun, Sep 13, 2020, 4:39 AM UTC

johnisgood wrote: post #209

ComputerGuru wrote: post #202

Earlier quoted context omitted.

What of it? > Those functions are completely non-standard and should be avoided in portable programs.

Sure, it has not been standardized, it is not part of the standard library, so what? Did the world stop? I mean, practically speaking, who cares? Implement it, or find libraries that did. There are plenty. I posted this one because it exists for an OS; OpenBSD, since 1999 . Plus, AFAIK ohash is portable enough. It consists of 2 files, and you can compile it with -std=c89 . Only the bounded attribute is ignored. If yo…

I use stb myself, so I have no qualms with that. The point is rather that GP was discussing praise for C’s standard library, and even the most portable single-file include-only dependency remains just that: an external dependency that isn’t part of the C standard library (and no, posix isn’t C).

Re: C’s Biggest Mistake (2009)

#213

Post by Gibbon1 » Sun, Sep 13, 2020, 4:42 AM UTC

asveikau wrote: post #93

rumanator wrote: post #75

Earlier quoted context omitted.

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

Maybe people are voting this down because they think it's directed at Walter Bright in particular, but I think there is actually some truth in the harsh comment. Nothing about Walter Bright in this statement, but some of the harshest criticisms from others I have seen of C are not from expert practitioners in C. People who are experts and also critics seem to have a more practical, realistic, nuanced critique, that u…

That's the way I interpreted it because it's true. A lot of the criticisms are misdirected one by people that haven't used C except being forced to use it for few assignments in school, C++ jockeys that think C is the 30 year out of date version of C that's supported by C++, and people that haven't used it at all for anything real.

I also agree that what the standard committee has been doing for the last 20 years amounts to willful sabotage.

Re: C’s Biggest Mistake (2009)

#214

Post by sriku » Sun, Sep 13, 2020, 4:42 AM UTC

konjin wrote: post #156

WalterBright wrote: post #59

Earlier quoted context omitted.

I suspect C has been steadily losing ground since I made it.

It's been 11 years, and C is running on more hardware than it ever has before, viz every android device. By what measure would C be losing ground?

C doesn't "run on hardware" .. unless you're talking interpreted C. Of course compiled machine code is running on more hardware but that's just a truism.

The question is are people using C to program these hardware more? .. or are people gravitating towards safer compiled languages (Rust?). That's a valid question, even if the answer is "no C's usage is only increasing."

Re: C’s Biggest Mistake (2009)

#215

Post by brundolf » Sun, Sep 13, 2020, 4:56 AM UTC

knaq wrote: post #211

brundolf wrote: post #195

Earlier quoted context omitted.

Ok, but you didn't just say this should be possible, you said it should be the default best-practice . Even if it were useful in a handful of cases, this would be a terrible default way of doing things.

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually wan…

Beginners don't struggle in Java, JavaScript, Python, C#, Ruby, and the dozen (at least) other languages that exclusively pass arrays by reference.

But all of this is way off-topic from the OP: the original point was, "Passing a pointer and length separately is error-prone; there should be a way to easily package the two together and this should be the default pattern for 90% of cases." Then you came in and said "No, instead C should support this totally orthogonal side-case that's a bad idea 90% of the time but has some niche uses." It's not a bad suggestion in itself, necessarily, but it's totally unrelated to the original proposal, much less an alternative to it.

Re: C’s Biggest Mistake (2009)

#216

Post by msla » Sun, Sep 13, 2020, 5:00 AM UTC

boring_twenties wrote: post #82

rumanator wrote: post #75

Earlier quoted context omitted.

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense. It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and ut…

Pro tip: Google the name of the person before responding to them, it can help avoid the taste of foot in your mouth which you are currently experiencing.

> Google the name of the person before responding to them

Is it a rule at HN that you can't take someone else's name? Otherwise, there's no guarantee that you're talking to the "Real" Walter Bright...

... or that you're talking to that Walter Bright, come to think of it.

Re: C’s Biggest Mistake (2009)

#217

Post by kmeisthax » Sun, Sep 13, 2020, 5:11 AM UTC

jschwartzi wrote: post #198

Reelin wrote: post #84

Earlier quoted context omitted.

Isn't much of the undefined behavior in C that people love to complain about intentionally left in the standard for the purpose of optimization? Similarly, bounds checks are necessary in insecure contexts (ie most places) but you probably don't want them slowing down (for example) an MD simulation. Edit: But to be clear, C really ought to have first class arrays. If you truly don't want bounds checks in a specific sc…

UB has nothing to do with optimization. It's about working around the differences between all the platforms that a C program might need to be compiled for. UB covers things like the layout of a signed integer(might be two's compliment, or it might not). It's about letting the platform or compiler dictate what the program does in the rare case where the program does something that might result in different behavior on…

Signed integer overflow could have been marked as implementation-defined rather than undefined behavior. That would have meant that compiling a program with overflows on most systems would produce the same results, but compiling it for the occasional rare sign-and-magnitude machine would produce slightly different results. However, they didn't do this. Instead, they said that it's undefined behavior, which means that any program that overflows integers has no guarantees about it's behavior at all - it could crash right away, generate the correct result 99 out of 100 times, or the compiler could outright reject the program.

A good example of this is calling functions with the wrong parameter types. UB in C, but practically allowed by every compiler. No machine would care if you do this... until WASM came along and suddenly every function call is checked at module instantiation time for exactly this behavior. This is because all WASM embedders are fundamentally optimizing compilers. And what is the mother of all optimizations? Inlining: the process of copypasting code from a function into wherever it is called. If a function is being called with the wrong arguments, how do you practically do that? You can't.

It is meaningless to talk about UB without also talking about optimizations. If you do not optimize code, then you do not have UB. You have behavior that is defined by something - if not the language spec, then the implementation of that spec, or a particular version of a compiler. There are plenty of systems with undocumented behavior that is nonetheless still defined, deterministic, and accessible. Saying that something is UB goes one step beyond that: it is saying that regardless of your mental model of the underlying machine, the language does not work that way, and the optimizer is free to delete or misinterpret any code that relies on UB.

Re: C’s Biggest Mistake (2009)

#218

Post by dpc_pw » Sun, Sep 13, 2020, 5:22 AM UTC

jschwartzi wrote: post #198

Reelin wrote: post #84

Earlier quoted context omitted.

Isn't much of the undefined behavior in C that people love to complain about intentionally left in the standard for the purpose of optimization? Similarly, bounds checks are necessary in insecure contexts (ie most places) but you probably don't want them slowing down (for example) an MD simulation. Edit: But to be clear, C really ought to have first class arrays. If you truly don't want bounds checks in a specific sc…

UB has nothing to do with optimization. It's about working around the differences between all the platforms that a C program might need to be compiled for. UB covers things like the layout of a signed integer(might be two's compliment, or it might not). It's about letting the platform or compiler dictate what the program does in the rare case where the program does something that might result in different behavior on…

> UB has nothing to do with optimization. It's about working around the differences between all the platforms that a C program might need to be compiled for.

That's what it used to mean. But at some points compilers people decided that since UB means literally "anything can happen" they can make optimizers optimize the shit out of the code assuming that UB can't be there.

C code that used to work 20 years ago, because the UB in it resulted in some weird but non-catastrophic behavior, doesn't work at all compiled modern compilers.

Re: C’s Biggest Mistake (2009)

#219

Post by knaq » Sun, Sep 13, 2020, 5:23 AM UTC

brundolf wrote: post #215

knaq wrote: post #211

Earlier quoted context omitted.

I didn't say it should be the default, but yes it should be. It is for structs. We can have giant structs. I've seen some over a megabyte in size. The default is that the callee gets a copy. (depending on the ABI it could be in the "wrong" stack frame, but it is a distinct copy) Are we having huge problems with structs being passed by value? I don't think so. Normal people pass pointers, except when they actually wan…

Beginners don't struggle in Java, JavaScript, Python, C#, Ruby, and the dozen (at least) other languages that exclusively pass arrays by reference. But all of this is way off-topic from the OP: the original point was, "Passing a pointer and length separately is error-prone; there should be a way to easily package the two together and this should be the default pattern for 90% of cases." Then you came in and said "No,…

The original claim was that the proposal would be C really passing arrays. In the article it says:

"the inability to pass an array to a function as an array, even if it is declared to be an array. C will silently convert the array to be a pointer, and will rewrite the function declaration so it is semantically a pointer"

...and later, referring to the new syntax:

"an array is passed"

In no way is it so. It has nothing to do with passing arrays. It's passing a fat pointer, which is different.

Re: C’s Biggest Mistake (2009)

#220

Post by dpc_pw » Sun, Sep 13, 2020, 5:33 AM UTC

I love how so many people here argue with the Walter Bright about technical aspects of C.

I have been a member of many programming languages communities, and every language has its own culture. C was always a language for the arrogant. "The real programmers" that can handle their memory, not afraid to work with pointers and that can get their code right.

I've been there, done that for many years, and became more humble with time. In a way I still love the brutal simplicity and low-level nature of C, but I would use it only if absolutely can't use any other language for technical reasons, and I would be really, really cautious.