Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How can C Programs be so Reliable? (2008)

tratt.net

Post reply on HN
Print view View original

51–60 of 97 posts

Re: How can C Programs be so Reliable? (2008)

#51

Post by lifthrasiir »

flohofwoe wrote: post #48
lifthrasiir wrote: post #35

Earlier quoted context omitted.

Then learn an assembly language instead, because C also has a fair amount of bookkeeping hidden behind the scene. C is typically described as a "low-level" programming language, where the "low-level" normally refers to the supposed distance from the language to the actual hardware. But as many incidents with UB demonstrate, this distance is still quite larger than expected. I think there is another sense of the word…

This is mostly only true for modern optimising C compilers. If you take a simple C compiler from the 90's, or disable optimisations in a modern compiler, there's a near 1:1 relationship between the C code and compiler output.

Yes, but I don't think you necessarily argue for using those simpler compilers today.

Re: How can C Programs be so Reliable? (2008)

#52

Post by bdjsiqoocwk »

wiseowise wrote: post #23
AtlasBarfed wrote: post #6

1) were C programmers "better"? In sum total, pretty much. 2) C programs, at least the ones we use now, are a product of a lot of use and debugging 3) It didn't take too many debugging sessions as a C programmer to learn to program a bit more carefully. 4) and the more it gets used, the more error codes it encounters, and the more robust the handling gets. I think a dirty secret of software engineering isn't that the…

> were C programmers "better"? In sum total, pretty much No. Original programmers that just happened to use C were better, not the other way around.

I disagree. The early adopters are usually exceptional. When adoption grows the average level decreases. This is a well known phenomenon which is larger than just programmers. It was even on HN recently, as applied to IQs in high schools over time: as more kids reach high school, the average decreases.

So yes. C programmers were better.

Re: How can C Programs be so Reliable? (2008)

#53

Post by flohofwoe »

tored wrote: post #43
flohofwoe wrote: post #42

Earlier quoted context omitted.

> C is horrible for exploratory programming... Completely opposite experience here. C is great for explorative coding because it's just structs and functions. There's no agonizing about whether some piece of code should go here or better there, wrapped in this or that concept or high level abstraction. Instead you start with an empty screen and incrementally build your ideas from small building blocks, much like in L…

What is stopping you from only using functions and structures in any language?

Java or C# required me to wrap every piece of code into class boilerplate (I think that has changed in the meantime, but just as an example).

In C++, Visual Studio will bombard you with all sorts of silly C++ Core Guideline advice if you try to write simple and straightforward code.

Finally, the standard libraries and 3rd party libraries might also get in the way if 'simple and straightforward' clashes with the idiomatic style of the language.

Re: How can C Programs be so Reliable? (2008)

#54

Post by tored »

flohofwoe wrote: post #53
tored wrote: post #43

Earlier quoted context omitted.

What is stopping you from only using functions and structures in any language?

Java or C# required me to wrap every piece of code into class boilerplate (I think that has changed in the meantime, but just as an example). In C++, Visual Studio will bombard you with all sorts of silly C++ Core Guideline advice if you try to write simple and straightforward code. Finally, the standard libraries and 3rd party libraries might also get in the way if 'simple and straightforward' clashes with the idiom…

Probably even better to pick PHP then, large standard library included, open foo.php to code, no main function required, just start writing, no build step, can output to stdout or http without effort

Re: How can C Programs be so Reliable? (2008)

#55

Post by flohofwoe »

lifthrasiir wrote: post #51
flohofwoe wrote: post #48

Earlier quoted context omitted.

This is mostly only true for modern optimising C compilers. If you take a simple C compiler from the 90's, or disable optimisations in a modern compiler, there's a near 1:1 relationship between the C code and compiler output.

Yes, but I don't think you necessarily argue for using those simpler compilers today.

Of course not, but it might explain where the idea comes from that "C is high level assembly". Apart from that, I think every programmer should play around with godbolt at least once in a while to get an idea how the high level source code maps to machine code. Even with optimizations enabled, the output of C code is usually much closer to the source (e.g. more "recognisable") than (for instance) highly abstracted C++ or Rust code.

Re: How can C Programs be so Reliable? (2008)

#57

Post by flohofwoe »

tored wrote: post #54
flohofwoe wrote: post #53

Earlier quoted context omitted.

Java or C# required me to wrap every piece of code into class boilerplate (I think that has changed in the meantime, but just as an example). In C++, Visual Studio will bombard you with all sorts of silly C++ Core Guideline advice if you try to write simple and straightforward code. Finally, the standard libraries and 3rd party libraries might also get in the way if 'simple and straightforward' clashes with the idiom…

Probably even better to pick PHP then, large standard library included, open foo.php to code, no main function required, just start writing, no build step, can output to stdout or http without effort

Sure, but it depends on the task. For instance if I need to talk to operating system APIs directly then C (or ObjC on Mac) might still be the better choice. Best tool for the job etc... I guess the gist is that languages that are built around the idea of high level abstractions and enforcing a specific coding style on large teams might not be the best language for exploring and prototyping.

Re: How can C Programs be so Reliable? (2008)

#58

Post by quelsolaar »

mbivert wrote: post #24
lifthrasiir wrote: post #21

Earlier quoted context omitted.

While I agree with last two paragraphs, C is not good even for that purpose because it doesn't give any tool to manage them. An effective C education should really be paired with various static analyses and formal verification strategies.

Well, there are such tools for C, but wouldn't using them be detrimental in this context? Think, like using a debugger vs. trying to wrap the execution in one's mind: I'not saying that one shouldn't use debuggers, but not using one has benefits, as a teaching device. Like running in a weight vest. Edit: ah, perhaps you meant, in addition to using raw C, one should also learn how to use such static analyzers & cie

As the author notes, to know what C code does you need to run it. A good debgger is a C programmers best friend.

Re: How can C Programs be so Reliable? (2008)

#59

Post by tored »

This text doesn’t make much sense, on the one hand the author argues that software written in C is robust, on the other hand the author admits that he has unknown bugs lurking in his own project.

One bug took several months to track down. This is cognitive dissonance at its finest.

Re: How can C Programs be so Reliable? (2008)

#60

Post by lifthrasiir »

flohofwoe wrote: post #55
lifthrasiir wrote: post #51

Earlier quoted context omitted.

Yes, but I don't think you necessarily argue for using those simpler compilers today.

Of course not, but it might explain where the idea comes from that "C is high level assembly". Apart from that, I think every programmer should play around with godbolt at least once in a while to get an idea how the high level source code maps to machine code. Even with optimizations enabled, the output of C code is usually much closer to the source (e.g. more "recognisable") than (for instance) highly abstracted C+…

> Even with optimizations enabled, the output of C code is usually much closer to the source (e.g. more "recognisable") than (for instance) highly abstracted C++ or Rust code.

That's usually true, but you can write C++ and Rust codes that more closely map to machine code as well. Most C code exhibits that only because you can't have enough abstractions to disrupt that mapping. It is good when you do need that kind of correspondence, but most applications rarely need them, and even performance-sensitive applications don't need them all the time. C does give you a knob, but that knob is stuck in a lower but not lowest position.

Post reply on HN