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

171–180 of 382 posts

Re: C’s Biggest Mistake (2009)

#171

Post by blame_lewis »

WalterBright wrote: post #30
rightbyte wrote: post #24

Earlier quoted context omitted.

The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

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.

Promises/async functions in JS and C# do absolutely nothing that you couldn't do without them. But they've had a structural effect on the average developer's ability to write scalable code.

Re: C’s Biggest Mistake (2009)

#172

Post by knaq »

WalterBright wrote: post #30
rightbyte wrote: post #24

Earlier quoted context omitted.

The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

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.

C could have gained the safety of function prototypes without them. Note that the function bodies and call sites had the type information. It could have been propagated through the compiler and assembler to the linker, which would then check for compatibility.

In some ways it would have worked much better. Header files can easily be wrong. The object files being linked are what really matter.

So, suppose we decided to implement this today, on a GNU toolchain. At the call site, we'd determine the parameter types based on the conventional promotions. This info gets put into the assembly output with an assembler directive. The assembler sees that, then encodes it in an ELF section. It might get a new section called ".calltype" or it is an extension to the symbol table or it involves DWARF. Similar information is produced for the function body. The linker comes along, compares the two, and accepts or rejects as appropriate.

Re: C’s Biggest Mistake (2009)

#173

Post by kps »

chadcmulligan wrote: post #71

Niklaus Wirth would concur - that was similar to his argument for pascal - strings contain a size.

Wirth's Pascal didn't have a string type. You could have a fixed-length arrty of CHAR, but you couldn't have _fewer_ than 16 characters in a 16-character array, and you couldn't pass a 16-character-array to a function with a 256-character-array parameter. Only the magic ‘functions’ built in to the language like write() could accept strings of different lengths. Since this made the language worse than FORTRAN and handling text, most implementations added some sort of string handling.

Re: C’s Biggest Mistake (2009)

#174

Post by jkoudys »

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 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 I spend most of my days in rust now. No shortage of rust devs who are big on C too.

Re: C’s Biggest Mistake (2009)

#175

Post by knaq »

brundolf wrote: post #170
knaq wrote: post #164

Earlier quoted context omitted.

The meat of the proposal: "a pair consisting of a pointer to the start of the array, and a size_t of the array dimension" No, that still doesn't fix the ABI. It's syntactic sugar. It is most definitely not passing an array. Passing an array means exactly that, no more and no less. For example, suppose this is your array: double foo[100][100]; The size is 80000 bytes. That is exactly how much data needs to be copied o…

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 my reasons. The language shouldn't block me.

Re: C’s Biggest Mistake (2009)

#176

Post by jkoudys »

viraptor wrote: post #65
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.

I love the move to d/rust/zig/nim/... but there are other issues too. Ecosystem of libraries, stabilisation of common patterns (futures and Tokio issues are still out there), platform compatibilities, industry support for moving away from known solutions, and many other issues. Even if we all suddenly knew Rust perfectly tomorrow, there are other issues in the way.

futures is definitely the big one for me. Getting all concurrency fully on async/awaits is amazing, e.g. actix-web awaiting an endpoint calling juniper for graphql, with async resolver methods making async calls against my DB, without needing to spawn a single thread, is lovely. Still doesn't work as smoothly as that, even though on paper it ought to. Getting close though.

Re: C’s Biggest Mistake (2009)

#177

Post by Skunkleton »

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

Earlier quoted context omitted.

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.

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

Re: C’s Biggest Mistake (2009)

#178

Post by Skunkleton »

mhh__ wrote: post #40
rightbyte wrote: post #24

Earlier quoted context omitted.

The proposal is just syntactic sugar for an size argument. It doean't add or solve anything really.

It allows automatic bounds checking i.e. I don't need to point out how many bugs that could fix. If you're worried about performance test it and turn it off.

Bounds checking is a solved problem in C. The challenge is proving that your program _cannot_ go out of bounds. That is very much not a solved problem in C.

Re: C’s Biggest Mistake (2009)

#179

Post by knaq »

Koshkin wrote: post #66
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.

I wonder if a better idea (in principle) would be to have some kind of hardware implementation, sort of like a finer-grained memory segmentation.

CHERI is an attempt. DARPA paid to have it for RISC-V and ARMv8. It was originally for MIPS.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

It is fundamentally like the 80286 segments, but with all sorts of usability troubles solved. The 80286 segments were impractical because there were a small number available and because the OS couldn't safely hand over direct control. Every little segment adjustment required calling the OS.

Re: C’s Biggest Mistake (2009)

#180

Post by Skunkleton »

diegocg wrote: post #122
ajsnigrutin wrote: post #32

Earlier quoted context omitted.

> I don't see a future where C survives I've been seeing those exact words for decades now, and C is still going strong. Every few year a new language comes, somes writes something in it, that was written in C before, someone might even write a basic OS in it, and after a few years, that language is almost forgotten, a new one is here, and again, someone is writing something in it, but in the end, we still use C for…

Usage of C in new projects has fallen dramatically in the latest decades. It used to be the case that C was considered a general purpose programming language and applications such as Evolution were written in it. Today big applications in C are increasingly rare, and Rust is only accelerating this trend - nobody wants to have buffer overflows anymore.

Do you have a citation? Genuinely curious.
Post reply on HN