Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C’s Biggest Mistake (2009)

digitalmars.com

Post reply on HN
Print view View original

131–140 of 382 posts

Re: C’s Biggest Mistake (2009)

#131

Post by WalterBright »

skywhopper wrote: post #70

It’s not a “mistake”. This article is complaining about a misinterpretation of C’s functionality. Arrays are not “real” data structures in C: there’s no such thing. The array-ish syntax that’s available is just a some syntactic sugar on top of pointers. You could say that having the sugar at all is a mistake. Or that C is incomplete without first-class array types. This is a cute hack, but at this point (far more tha…

> Arrays are not “real” data structures in C: there’s no such thing.

I assure you, there are arrays in C.

    int a[100]; // `a` is an array, not a pointer
    int* p;     // `p` is a pointer, not an array

    a = p;      // error, array is not a pointer
> The array-ish syntax that’s available is just a some syntactic sugar on top of pointers.

Sorry, this is incorrect. In some circumstances, C will implicitly convert an array to a pointer, which is what the article is about, but don't mistake a conversion with identity.

Re: C’s Biggest Mistake (2009)

#132

Post by rowanG077 »

colejohnson66 wrote: post #95
rowanG077 wrote: post #44

Earlier quoted context omitted.

I don't feel it's so bad. You have a a specific flag to tell the compiler to show warnings if you have any.

Why should I need to use a flag to fix something that doesn’t make sense? I can understand implicit up -conversions, but down -conversions too?

I'm not arguing that the original design was good or bad. I'm simply saying that it's as simple as adding a flag to the compiler these days.

Re: C’s Biggest Mistake (2009)

#133

Post by ratww »

mark-r wrote: post #102
pjmlp wrote: post #27

Earlier quoted context omitted.

Unfortunely until we get rid of UNIX/POSIX clones, C will be kept around. So not in my lifetime.

Or at least not in Torvalds' lifetime. His views on replacements for C are legendary. It would be interesting to see his comments on this proposal.

Torvalds himself might have a different opinion:

People have been looking at that for years now. I’m convinced it’s going to happen one day. It might not be Rust, but it’s going to happen that we will have different models for writing these kinds of things

https://thenewstack.io/linus-torvalds-on-diversity-longevity...

Re: C’s Biggest Mistake (2009)

#134

Post by mark-r »

Skunkleton wrote: post #87
Snarwin wrote: post #47

Earlier quoted context omitted.

More precisely, it doesn't have a string type .

It certainly has string literals, which are a kind of type.

That's the thing, they're not a type - they're just an array of char with an unspecified length, indistinguishable from any other array of char or pointer to char. Only the convention of ending them with a null character makes them usable at all.

Re: C’s Biggest Mistake (2009)

#135

Post by sam_bristow »

nordsieck wrote: post #85
teej wrote: post #54

Earlier quoted context omitted.

C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

> C code is being replaced by Rust fast. One of the key areas C is used that Rust cannot be used easily is in limited embedded devices. That looks like it'll be the case for at least 10 years and probably much longer than that.

The embedded Rust ecosystem is actually pretty vibrant these days. The number and quality of #![no_std] crates is improving rapidly.

The main limitation is going to be if your MCU is supported by LLVM. If you're targetting ARM, RISC-V, MSP430 or Xtensa you might get further than you'd expect.

There's a hell of a lot of tooling built around C though. So nomatter what happens I don't think we'll ever be rid of it.

Re: C’s Biggest Mistake (2009)

#136

Post by MaxBarraclough »

AnimalMuppet wrote: post #115
pritovido wrote: post #94

I actually believe the way C works is great, as simple as it could be and it gives you power to do exactly what you want, they way you want it. I would certainly hate(and would continue using them btw) that they remove normal pointers from C. It would be like removing s expressions from lisp. I believe that the solution to this "mistake" is just not using c directly, using other languages to write C code for you, or…

My solution is different: Don't use dynamically-allocated variable-sized buffers unless you have to. C++ gives you more tools for avoiding them than C, BTW.

> C++ gives you more tools for avoiding them

A direct link, for the curious: https://en.cppreference.com/w/cpp/container/array

As an aside, the C’s Biggest Mistake article cropped up in HN discussion 8 days ago, https://news.ycombinator.com/item?id=24373728

Re: C’s Biggest Mistake (2009)

#137

Post by leetcrew »

johnisgood wrote: post #98
teej wrote: post #54

Earlier quoted context omitted.

C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way. The syntax is extremely simple, too, vs. Rust. Rust is close to Perl when it comes to syntax; full of symbols. Too implicit for me. I want to look at the code, and I want to understand what the heck is going on, even if it is written by someone else. I usually do, with C. Rust? Not so much, and believe me…

> One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way.

not saying you're necessarily wrong (c is definitely simpler than rust), but I think most people would write a similar comment for whatever language they feel most comfortable with. I write c++ most days. even though it's the most verbose and complicated language I've ever used, I can still probably get stuff done way faster than in another language I happen to pick up.

if I'm just throwing something together really fast, I do mostly use the old school C functions though. scanf is way nicer than streams.

Re: C’s Biggest Mistake (2009)

#138

Post by datman347 »

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.

Anyone that has to rely on their name for an argument isn't worth listening to.

Re: C’s Biggest Mistake (2009)

#139

Post by kinoglazkinoeye »

teej wrote: post #54
Upvoter33 wrote: post #49

Earlier quoted context omitted.

"C is finished if it doesn't address the buffer overflow problem" You should keep making this prediction ... one day you might be right! :)

C code is being replaced by Rust fast. The only limit is how quickly programmers can become good at Rust. It's already happening.

I will never use software that's been Rusted

Re: C’s Biggest Mistake (2009)

#140

Post by peterwwillis »

leetcrew wrote: post #137
johnisgood wrote: post #98

Earlier quoted context omitted.

One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way. The syntax is extremely simple, too, vs. Rust. Rust is close to Perl when it comes to syntax; full of symbols. Too implicit for me. I want to look at the code, and I want to understand what the heck is going on, even if it is written by someone else. I usually do, with C. Rust? Not so much, and believe me…

> One of the niceties of C is that I can get anything done pretty damn quickly, without anything getting in my way. not saying you're necessarily wrong (c is definitely simpler than rust), but I think most people would write a similar comment for whatever language they feel most comfortable with. I write c++ most days. even though it's the most verbose and complicated language I've ever used, I can still probably get…

Agreed - in that I write it in Perl if I need it to just work right now. Perl is still, to me, the most useful programming language for completing a generic program in the smallest amount of time. (Part of that is due to CPAN, and part to the gazillion built-in features of Perl 5)
Post reply on HN