←back to thread

Brent's Encapsulated C Programming Rules (2020)

(retroscience.net)
78 points p2detar | 1 comments | 09 Dec 25 11:16 UTC | HN request time: 0s | source
Show context
Jean-Papoulos ◴[09 Dec 25 12:20 UTC] No.46204131[source]▶
>What this means is that you can explain all the intent of your code through the header file and the developer who uses your lib/code never has to look at the actual implementations of the code.

I hate this. If my intellisense isn't providing sufficient info (generated from doc comments), then I need to go look at the implementation. This just adds burden.

Headers are unequivocally a bad design choice, and this is why most of every language past the nineties got rid of them.

replies(3): >>46204695 #>>46205042 #>>46205098 #
antonvs ◴[09 Dec 25 14:12 UTC] No.46205098[source]▶
C's text preprocessor headers were a pragmatic design choice in the 1970s. It's just that the language stuck around longer than it deserved to.
replies(1): >>46209894 #
tomcam ◴[09 Dec 25 20:04 UTC] No.46209894[source]▶
So what language is ready to take its place in the thousands of new chips that emerge every year, the new operating systems, and millions of programs written in see every year?
replies(1): >>46213917 #
1. antonvs ◴[10 Dec 25 03:56 UTC] No.46213917[source]▶
You're alluding to the network effects that make that takeover difficult now, after decades of doubling down on a technically weak and systemically insecure solution.

Languages that are technically capable of replacing C in all those applications include Ada, (and in certain applications, SPARK Ada), D, Zig, Rust, and the Pascal/Modula-2/Oberon family. None of those language use a purely textual preprocessor like C's. They all fix many of C's other design weaknesses that were excusable in the 1970s, but really aren't today.

But Rust in the Linux kernel is no longer experimental, so perhaps things are starting to improve.