5 ms·
Meh. People love to hate on C but the invariants you have to keep track of are relatively simple (things like 0<=i<L.) Most languages replace these with multi-d
by notwokeno 4y ago
Meh. People love to hate on C but the invariants you have to keep track of are relatively simple (things like 0<=i<L.) Most languages replace these with multi-dimensional string based hashmaps that have much more complex invariants to keep track of and similar consequences for failing to do so.
Some languages like Rust and Haskell do a little better by having the compiler keep track of most of them (if you use it right) but the consequence of misunderstanding them here is accidentally coding yourself into a corner which is extremely unpleasant.
There are other things people like to talk about like automatic memory management and package management and again I'm not convinced these really improve much. The pain of allocating memory in C means people often find ways to avoid doing it altogether which results in much more predictable behavior. Same with pulling in third party libraries. It's rare using more than a couple is actually beneficial but when the package manager is there the temptation is way too much for most people and the result is both unpleasant and very vulnerable to supply chain attacks.
I'm still not convinced any of this is the improvement people think it is.
- quotemstr 4y ago> the invariants you have to keep track of are relatively simple (things like 0<=i<L.) If maintaining these invariants were so simple, why would the smartest people in the industry have so much trouble doing so? Humans cannot consistently write correct C, not even the ones who believe they can. We have decades of evidence. > Most languages replace these with multi-dimensional string based hashmaps that have much more complex invariants to keep track of and similar consequences for failing to do so. This take reflects a profound ignorance of the relative severity of different kinds of software defect. When you get an array bound wrong in Java or Rust, you get an exception or a panic. Your program exits and restarts. You get a ticket for fixing the bug. Life goes on. When you get an array bound wrong in C, you open the door for a nefarious actor to gain control over everything that your program can access. These aren't similar consequences. They're not even on the same planet of consequences. C apologists are like apologists for asbestos and lead paint.
- notwokeno 4y agoMy point is that they can't consistently write correct software in any language. Javascript for example has similar issues where if you're not careful about which keys in a hashmap you write to you can create situations that allow for all kinds of things including arbitrary code execution. Modern C compilers/runtimes also have bounds checking (although I've never used it) like java if you want to use it. Sure there's some improvement but it's not nearly as extreme as it's made out to be.
- quotemstr 4y agoIt's true that humans will inevitably produce software with defects. There are differences in the impacts of these defects. > Javascript for example has similar issues where if you're not careful about which keys in a hashmap you write to you can create situations that allow for all kinds of things including arbitrary code execution. Not without eval() you can't. > Modern C compilers/runtimes also have bounds checking No, they don't. There are C-like languages (e.g. C++/CLI) that do, and you can use containers, but no, plain C cannot do bounds checking. There's no room in the ABI for it, at least not without CHERI or ASAN. > although I've never used it One of the most dangerous things in the world is giving powerful tools to people who don't know that they shouldn't use them.
- svnt 4y ago> My point is that they can’t consistently write correct software in any language. Javascript for example I don’t think Javascript is the counterexample you want to use as a good language. It is like C where safety is traded for flexibility. If people can’t write correct software in any language, the language designers can help, which is exactly what the Rust designers did. It’s not great for everyone because now all the scar tissue that great C devs have around what near-fatal errors they’ve made previously has lost some of its value.
- lelanthran 4y ago> Humans cannot consistently write correct C, So? Humans cannot consistently write correct code in any language. > When you get an array bound wrong in C, you open the door for a nefarious actor to gain control over everything that your program can access. What's really interesting to me is how Heartbleed (the largest example of getting an array bound wrong) was orders of magnitude less expensive to fix than Log4j, and yet it was Log4j that resulted in gauranteed RCE, not Heartbleed. > C apologists are like apologists for asbestos and lead paint. Let's not go spilling hyperbole all down our shirt. I get the feeling that a lot of people comparing C to things that kill have never worked in life-critical situations, the systems of which ran C for decades and decades, and never appeared to have lost very many lives in the process. Military, munitions, healthcare machines ... I can't remember any of them losing lives because of a misfeature in the C programming language, and yet there you are, proudly proclaiming to the word that C is like Asbestos, which has taken peoples lives. Get a grip.
- svnt 4y agoI mean I’ve worked with C for a long time. It’s love-hate. I think it’s hard to see the value from the other side of having internalized C, and Rust definitely encumbers you. The number of things a beginner doesn’t have to know or worry about to code something as essential as a function that reads a file, searches for a string, and interacts in a serious way with the network in Rust vs C is substantial. Probably I’ll get downvoted again but it’s fine.
- mturmon 4y agoBut you do learn from such things (opening a file, reading from the network). All the stuff that can go wrong, and that it all has to be handled. Like writing a device driver. It’s useful to write that C code, and then try to break it (e.g., to force a segfault rather than a proper error-then-exit). Is knowing all that necessary? No, as you are kind of implying. ;-)