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

181–190 of 382 posts

Re: C’s Biggest Mistake (2009)

#181

Post by johnisgood »

jkoudys wrote: post #174
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 way rust's just a different tool for a different job, is it really doesn't optimize for knowing everything that's happening inside someone else's code. It's a great example of the difference in procedural vs functional programming, where in rust you mostly just care what your function args are and what it returns. Nothing wrong with learning multiple languages, of course. C was my first professional language, and…

Sure. I code in C, Go, OCaml, Ada/SPARK, Factor (Forth-like, Lisp-y), Common Lisp (rarely), and Erlang (moving to Elixir).

But I was responding to "C code is being replaced by Rust fast.".

Re: C’s Biggest Mistake (2009)

#182

Post by brundolf »

knaq wrote: post #175
brundolf wrote: post #170

Earlier quoted context omitted.

Are you non-jokingly suggesting copying the entire array to and from the stack each time, as an alternative to the OP's proposal (and as a default best-practice)?

Yes. If you don't really want to pass an array then don't do that. The language shouldn't get in the way when somebody wants to pass an array. Take the address, and pass a pointer, if that is what you want to do. Maybe I want the callee to be able to modify the array without affecting the caller. Maybe I'm even telling the linker to put that array in ROM, but I want a writable copy in the callee. Whatever... I have m…

I don't think you realize how intractably inefficient that would be for all but the smallest cases.

Re: C’s Biggest Mistake (2009)

#183

Post by rixed »

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.

Thank you for enforcing arguments of authority.

Re: C’s Biggest Mistake (2009)

#184

Post by johnisgood »

saagarjha wrote: post #162
diegocg wrote: post #112

Earlier quoted context omitted.

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

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.

Re: C’s Biggest Mistake (2009)

#185

Post by knaq »

baby wrote: post #17
WalterBright wrote: post #15

Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.

I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.

I definitely like the "lack of package manager, common build system". For me, having those is a negative for a language like rust.

You see, my OS already comes with those, and I expect to use them. I have the Debian package system: dpkg, apt, aptitude, and so on. It's a big mess when other software tries to steal that role. I have the traditional build systems and more: make, cmake, autoconf, scons, and so on. If I'm building a large project with multiple languages, I'm going to use one of those tools. If a language wants to fight me on that, I'm not interested in that language.

Re: C’s Biggest Mistake (2009)

#186

Post by moonchild »

SamReidHughes wrote: post #5

The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.

The exact-width integer types proposal[1], implemented in clang, happens to fix this.

1. http://blog.llvm.org/2020/04/the-new-clang-extint-feature-pr...

Re: C’s Biggest Mistake (2009)

#187

Post by dnautics »

johnisgood wrote: post #181
jkoudys wrote: post #174

Earlier quoted context omitted.

One way rust's just a different tool for a different job, is it really doesn't optimize for knowing everything that's happening inside someone else's code. It's a great example of the difference in procedural vs functional programming, where in rust you mostly just care what your function args are and what it returns. Nothing wrong with learning multiple languages, of course. C was my first professional language, and…

Sure. I code in C, Go, OCaml, Ada/SPARK, Factor (Forth-like, Lisp-y), Common Lisp (rarely), and Erlang (moving to Elixir). But I was responding to "C code is being replaced by Rust fast.".

You might like zig. It's still pre 1.0, but I feel like it really has that "get out of your way" feel of C with a ton of safety. If you write tests, you can get tested memory safety, too.

Re: C’s Biggest Mistake (2009)

#188

Post by munificent »

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 relevant metric would be what fraction of hardware it's running on.

Re: C’s Biggest Mistake (2009)

#189

Post by colejohnson66 »

kens wrote: post #111

C's pointers wouldn't be an issue if the world had used the Intel iAPX 432 processor instead of the 8086. The iAPX 432 included bounds checking for every array in hardware (among many other features), so it was impossible to make an out-of-bounds access. Unfortunately the iPAX 432 was delayed, so Intel introduced the 8086 as a stopgap processor and computers have been using the x86 architecture ever since. It's inter…

x86 has MPX. It provides 4 registers, BND0-3, that can be used for hardware bounds checking. Unfortunately, no one seems to have adopted it.

Re: C’s Biggest Mistake (2009)

#190

Post by hannasanarion »

rixed wrote: post #183
boring_twenties wrote: post #82

Earlier quoted context omitted.

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.

Thank you for enforcing arguments of authority.

There's "arguments of authority" and then there's "accusing Walter Bright of having never written a line of code before".
Post reply on HN