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

261–270 of 382 posts

Re: C’s Biggest Mistake (2009)

#261

Post by jcelerier »

leptons wrote: post #155
datman347 wrote: post #146

Earlier quoted context omitted.

He never said explicitly, he was just making a general statement. Not that it matters whether he did or didn't, there's a lot of things wrong with C, it will most likely eventually disappear, but not for reasons outlined in this article. That's what he was saying.

Someone once said COBOL would disappear. C will still be used long after you and I and everyone here have returned to dust.

> C will still be used long after you and I and everyone here have returned to dust.

there are also people still riding horses. does not make it relevant in any way.

Re: C’s Biggest Mistake (2009)

#262

Post by elgfare »

leetcrew wrote: post #46
eps wrote: post #35

Earlier quoted context omitted.

I'm not sure whom this proposal is aimed at exactly. Any production-quality C code will already use a (pointer + count) combo when passing arrays to a function, which is something that will still be needed under your proposal because the vast majority of arrays is dynamically sized. So unless all arrays in C are given the fat pointer treatment, I don't really see how what you suggest would make much of a difference.…

pointer + size does not really fix anything, as you are relying on the programmer to correctly keep track of the size. I'm not even sure what alternative this improves upon. even more error-prone null value marking the end? praying the array will be big enough (looking at you, gets!)? unless you have a team of incredibly diligent coders, people are going to read past the end of bare arrays over and over again. one sp…

But it makes it so much easier to

- Statically check the code, since the static analysis tool knows for certain which value is the size and can check that you're using correctly.

- Initialize the size correctly, since you don't have to enter it twice, or more crucially, remember to change it twice (or create a #define in another part of the file, name it, and document it)

You also make an excellent point yourself about the meaning of 'size'. If this was standardized, it would be the same everywhere, minimizing the risk of ambiguity.

Re: C’s Biggest Mistake (2009)

#263

Post by pjmlp »

konjin wrote: post #249
pjmlp wrote: post #229

Earlier quoted context omitted.

The pyrrhic victory, other than the Linux kernel, everything else is a mix of C++ and Java, with a native compiler written in C++. And the history of Linux kernel and Android might come to an end if Zirkon ever replaces it, then it will be no more C on Android.

[[citation needed]]

Citations for what?

Android and Fuchsia source code are public available, just as their code reviews and ongoing work to port ART to Fuchsia.

Anyone skilful to use C without creating CVEs of their own, is surely able to find that information.

Re: C’s Biggest Mistake (2009)

#264

Post by rightbyte »

Skunkleton wrote: post #177
mark-r wrote: post #134

Earlier quoted context omitted.

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.

printf("%lu\n", sizeof("Well, actshully")); -> 16

One could say that C has a different type for each string size plus the joker pointer to char.

Re: C’s Biggest Mistake (2009)

#265

Post by ayende »

raverbashing wrote: post #225
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 number of new projects using it (without counting legacy code) Nobody would do a project in C today with Go/Rust/C++ etc unless it's for a very specific situation

I started a project this year, I write it in C.

Re: C’s Biggest Mistake (2009)

#267

Post by saagarjha »

sriku wrote: post #214
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?

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

You’re being pedantic to the point of being actively misleading.

Re: C’s Biggest Mistake (2009)

#268

Post by mytherin »

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?

The same is likely true of Fortran, since Fortran code is shipped around with several Python data science libraries and included in R. Does that mean Fortran is a thriving language, or does it just mean Fortran was used a long time ago to write some important libraries that are now hard to get rid of?

Re: C’s Biggest Mistake (2009)

#269

Post by saagarjha »

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.

My guess is that those four see more use than Rust does, with Java and C++ forming the base of a typical undergraduate curriculum alongside Python and C and Haskell and OCaml showing up in classes where the concepts behind them are typically introduced. (FWIW: my college experience was C++, C, Scala for the required courses.)

Re: C’s Biggest Mistake (2009)

#270

Post by saagarjha »

mslm wrote: post #251
johnisgood wrote: post #184

Earlier quoted context omitted.

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

Sadly the latter is often how C++ is taught even though it is not at all how modern C++ is used…
Post reply on HN