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

251–260 of 382 posts

Re: C’s Biggest Mistake (2009)

#251

Post by mslm »

johnisgood wrote: post #184
saagarjha wrote: post #162

Earlier quoted context omitted.

Do they? Or are they just told that they should be using Rust? Even putting aside outdated curriculum, Rust is a fairly involved language to teach to a new programmer.

Indeed. What languages are most common in universities anyways? Haskell? Java? C++? OCaml? Which ones are the most common? Maybe he meant outside of the education system. I think the reason for that would be hype and peer pressure, and the feeling of novelty, with a hint of FOMO. I do not see any languages being pushed/hyped as hard as Rust.

I can't imagine universities actually caring to teach new programmers Rust... it's an overly complex language that most professors themselves would steer far away from because they know there's more to programming than following trends.

(We learned C++ in university in New York which was basically C with occasional help from C++'s standard library).

Re: C’s Biggest Mistake (2009)

#252

Post by AlphaSite »

giancarlostoro wrote: post #200
konjin wrote: post #156

Earlier quoted context omitted.

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?

> By what measure would C be losing ground? When we start seeing Rust or similar being used instead of C would be a good metric and / or major OS development.

Linux is currently investigating using Rust in drivers (The main issue being lack of compiler support for the more isoteric architectures).

Re: C’s Biggest Mistake (2009)

#253

Post by teddyh »

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…

See chapter 6 of the C FAQ: http://c-faq.com/aryptr/

Re: C’s Biggest Mistake (2009)

#254

Post by mjevans »

ktpsns wrote: post #2

I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…

Then don't return or expect arrays. Return and expect Pointers of a given type.

That's not going away in the article's proposal. It's being complimented by an array syntax that makes the current size (in memory) of a non-static data structure bounded upfront.

Re: C’s Biggest Mistake (2009)

#255

Post by elgfare »

ratww wrote: post #123
WalterBright wrote: post #30

Earlier quoted context omitted.

In my experience with language design, a little bit of syntactic sugar can have transformative results. C's function prototypes, syntactic sugar added circa 1990, were transformative for C programming.

> In my experience with language design, a little bit of syntactic sugar can have transformative results. I agree 100%. This also reminds me of this article: https://nibblestew.blogspot.com/2020/03/its-not-what-program... HN discussion: https://news.ycombinator.com/item?id=22696229

I totally agree that C shepherds you into pointers. I also think C shepherds you into writing everything from scratch. Most of all I think it's a self-perpetuating cycle of "there's no system for X (e.g. sized arrays, packaging system, classes) so everyone makes their own, and now all other code feels slightly incompatible with all other code."

Re: C’s Biggest Mistake (2009)

#256

Post by IshKebab »

konjin wrote: post #153
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.

It isn't. You can tell how much a language is used by the inverse of the number of blogposts about it. People who have jobs don't have the time to write about how they would solve problems using that language, because they already are and have better things to do in their free time.

It is. Since 2012 C has dropped from about 4% of Github code to 3%. Meanwhile Rust has climbed from 0 to about 1%. That on its own doesn't prove that people are moving from C to Rust but it's not a risky guess. I did see some data on language transitions a while ago but can't find it now unfortunately (why is browser history search still so shit?).

https://madnight.github.io/githut/#/pull_requests/2020/2

Re: C’s Biggest Mistake (2009)

#257

Post by Stratoscope »

sam_lynx wrote: post #237
msla wrote: post #216

Earlier quoted context omitted.

> 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.

I’m new here, so this seems like a valid criticism to me — but judging by the number of downvotes, it may not be. Can someone explain why this comment is incorrect?

Perhaps because so many of know Walter from his work and his history here on HN? Sometimes you have to just trust that someone is who we all say they are.

Re: C’s Biggest Mistake (2009)

#258

Post by Taniwha »

It's probably worth remembering the history of C - it didn't appear fully formed, lots of stuff evolved as people used it - for example in V6 Unix += used to be =+.

In particular you used to use structures in a weird way, essentially field names within structures lived in their own global name space, any pointer could be used with any structure - there weren't unions yet so this was used for good effect in Unix kernel drivers (there was a standard buffer queue header you could add your own stuff at the end of.

I think this was kind of descended from the BCPL/Bliss world view where explicit pointers were a relatively new thing in languages and their typing was pretty simple (there was a limit to the number of indirections allowed) - fully orthogonal typing systems were only just becoming a thing then.

Also I suspect that the idea that a[i] was the same as a+i was an idea with legs, this is still legal C:

  char *x()
  {
        int i; char *p;
        return &i[p];
  }

Re: C’s Biggest Mistake (2009)

#259

Post by IshKebab »

baybal2 wrote: post #147
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. The only limit is how quickly programmers can become good at Rust. It's already happening. I think Rust has been very quickly fading into obscurity. What Rust hast brought to the tables was nearly the same what was brought by 100+ other programming languages in attempts to "fix C."

Oh... can you show me those 100+ other languages that have opt-out memory safety, explicit lifetime annotation, a borrow checker and no runtime?

Re: C’s Biggest Mistake (2009)

#260

Post by otabdeveloper4 »

diegocg wrote: post #112
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…

Young programmers seem to prefer learning Rust than C. Generational replacement will take care of making Rust prevalent, no matter what existing programmers think.

Lol.

For every young programmer learning Rust there are probably 10000 learning C.

C is still the only language you can count on anyone with a programming-related education to have knowledge of. (That doesn't translate into being able to program is C, but still.)

Post reply on HN