7 ms·

I disagree. Another comment here mentions "military grade verification" (?!) is required to write such high quality C applications. No, not at all, unless you c

I disagree. Another comment here mentions "military grade verification" (?!) is required to write such high quality C applications. No, not at all, unless you count knowing what you're engineering as Military Grade Awareness. You seem to be saying you prefer the code-slinging style of "see if it works, it seems to work... release it". I've been including SQLite in various applications for 10 years, as well as have been coding, primarily in C, for 35 years. If you are not testing your work to a degree of statistical awareness of it's behavior, you're an irresponsible cowboy, hardly a true professional, and probably a liability to you and your team.

TheDong 9y ago
The evidence is on the side of the parent poster. Incredibly experienced programmers write C without those tools, and with practically no exceptions memory issues, crashes, and vulnerabilities surface if the code is large enough and the project used enough. An easy example of this is the Linux kernel. They historically had relatively few verification tools and have one of the largest C codebases out there. There's a new vulnerability related to memory safety every two or three weeks. There's a bug fixed due to C memory management at least daily. None of those bugs would have happened in Rust. Most of them couldn't have happened in well written C++ (whereas this well-written C is chock full of them). Note as well that the kernel now gets some of the most exhaustive verification of any project (such as from google's syzkaller, etc), and it still has tons of C memory issues.
- bsenftner 9y ago
  "Incredibly experienced programmers" ? The language is simple and well defined to the degree one can map out exactly what happens on paper, if need be. Everyone is so brainwashed to think C is some low level assembly like language that is "hard". No, not at all. It simply provides no training wheels or safety harness - meaning one needs to know what they are doing, not coding in a "type and see what it does" style.
  - TheDong 9y ago
    > It simply provides no training wheels or safety harness - meaning one needs to know what they are doing Meaning that if you are human you will make mistakes. My point is that people who do know what they're doing still make mistakes. Clearly the tool does not match the reality of human cognition.
    - geezerjay 9y ago
      > Meaning that if you are human you will make mistakes. You can make mistakes in any language, and they will bite you in the backside any way. Just because some people prefer to live in padded rooms that doesn't mean they can't or won't get hurt if they decide to pull stunts. Padded rooms just provide them with a false notion of safety that ends up making matters worse.
      - deleted 9y ago
        [deleted]
      - TheDong 9y ago
        > You can make mistakes in any language, and they will bite you in the backside any way. This is a false equivalency.. It's akin to saying "you can hit your thumb putting in a nail with any tool, so you might as well use a rock not a hammer since they're both bad". Yes, you can make mistakes in any language, but that's not a reason to ignore modern tooling and advances and continue. Other languages allow us to build abstractions and solve mistakes in ways which are just impossible with C... and without those abstractions, it's just needlessly difficult to keep all the state in your head and write correct code. An easy example of this is locking and ownership. In C, mutexes are managed manually and what they hold is by convention. It's easy to write races or accidentally deadlock (again as evidenced by such a bug in the kernel existing every few weeks). In languages with RAII, python's "with", etc, you can't forget to unlock the lock. It's one less thing to think about. In languages like rust, it's possible to model in the type system that a given resource can only be accessed while a mutex is locked. Again, one less way to make a mistake. C has no ability to provide or build abstractions that are this robust. Using C is, more often than not, like using a rock to hammer in a nail. > Just because some people prefer to live in padded rooms With C, people are living in a room where the floor is lava and nails coat most surfaces. I'll take my room that's carpeted, and if I need to pull a stunt and rip up the carpet, sure, I can do that, but at least I can walk normally most of the time.
dbaupp 9y ago
This is almost a "no true scotsman": in practice, a lot of C projects and programmers (even ones that, by most other metrics, would be regarded as professional programmers) do not have the resources to test as extensively as SQLite.
- blub 9y ago
  It's more than that, it's a manipulative comment, designed to put others on the defensive about their own skills and muddle the issue. Any real-world project will be developed unter specific time constraints and have a certain budget. There will be a mix of developers and other roles in the team, with varying skills. There will be politics involved and the project will probably be in use for decades, ensuring that all of the above will significantly change during its lifetime. Under such conditions, C is an abject failure at supporting robust, quality code, because it neither benefits from a culture of safety (like Ada or even Rust) nor does it have any enforceable safety switches or indeed safety-by-default. Anything that can be screwed up, will be screwed up over the years by someone, some configuration option, procedure or project management decision. Java is on average significantly safer than C or C++, because no matter what happens, the language won't allow certain errors to happen. C can be assumed to be a hopeless case, but a purely theoretical way of avoiding these kinds of issues is to have a sufficient supply of bsenftner clones which will supervise a project through its development and operation until it's retired from production (assuming bsenftner is as awesome as they say).
- buserror 9y ago
  I agree, I'm paid by the hour to deliver a set of features, and the client very, VERY rarely would pay for me to start 'diverging' and writing test cases for something they see as superfluous. A bit of field tests (ie, users as testers) and if it works, it ships. I don't make the rules. The scary bit is, often, it works just fine; in many cases, it's cheaper to reboot/relaunch for a 1/100000 crashing bug than paying me to find it and fix it!
  - Yoric 9y ago
    That's one of the reasons I'm pretty happy to work in a place where my manager will generally agree if I tell them that I'm planning to spend the next 3 months improving the test suite or harness or adding one layer of safety to eliminate a class of bugs or adding a new static analysis. Of course, this is also a place where we practice static analysis, continuous integration, code reviews and we're now progressively migrating code to Rust.

TheDong 9y ago

The evidence is on the side of the parent poster. Incredibly experienced programmers write C without those tools, and with practically no exceptions memory issues, crashes, and vulnerabilities surface if the code is large enough and the project used enough. An easy example of this is the Linux kernel. They historically had relatively few verification tools and have one of the largest C codebases out there. There's a new vulnerability related to memory safety every two or three weeks. There's a bug fixed due to C memory management at least daily. None of those bugs would have happened in Rust. Most of them couldn't have happened in well written C++ (whereas this well-written C is chock full of them). Note as well that the kernel now gets some of the most exhaustive verification of any project (such as from google's syzkaller, etc), and it still has tons of C memory issues.

bsenftner 9y ago
"Incredibly experienced programmers" ? The language is simple and well defined to the degree one can map out exactly what happens on paper, if need be. Everyone is so brainwashed to think C is some low level assembly like language that is "hard". No, not at all. It simply provides no training wheels or safety harness - meaning one needs to know what they are doing, not coding in a "type and see what it does" style.
- TheDong 9y ago
  > It simply provides no training wheels or safety harness - meaning one needs to know what they are doing Meaning that if you are human you will make mistakes. My point is that people who do know what they're doing still make mistakes. Clearly the tool does not match the reality of human cognition.
  - geezerjay 9y ago
    > Meaning that if you are human you will make mistakes. You can make mistakes in any language, and they will bite you in the backside any way. Just because some people prefer to live in padded rooms that doesn't mean they can't or won't get hurt if they decide to pull stunts. Padded rooms just provide them with a false notion of safety that ends up making matters worse.
    - deleted 9y ago
      [deleted]
    - TheDong 9y ago
      > You can make mistakes in any language, and they will bite you in the backside any way. This is a false equivalency.. It's akin to saying "you can hit your thumb putting in a nail with any tool, so you might as well use a rock not a hammer since they're both bad". Yes, you can make mistakes in any language, but that's not a reason to ignore modern tooling and advances and continue. Other languages allow us to build abstractions and solve mistakes in ways which are just impossible with C... and without those abstractions, it's just needlessly difficult to keep all the state in your head and write correct code. An easy example of this is locking and ownership. In C, mutexes are managed manually and what they hold is by convention. It's easy to write races or accidentally deadlock (again as evidenced by such a bug in the kernel existing every few weeks). In languages with RAII, python's "with", etc, you can't forget to unlock the lock. It's one less thing to think about. In languages like rust, it's possible to model in the type system that a given resource can only be accessed while a mutex is locked. Again, one less way to make a mistake. C has no ability to provide or build abstractions that are this robust. Using C is, more often than not, like using a rock to hammer in a nail. > Just because some people prefer to live in padded rooms With C, people are living in a room where the floor is lava and nails coat most surfaces. I'll take my room that's carpeted, and if I need to pull a stunt and rip up the carpet, sure, I can do that, but at least I can walk normally most of the time.

dbaupp 9y ago

This is almost a "no true scotsman": in practice, a lot of C projects and programmers (even ones that, by most other metrics, would be regarded as professional programmers) do not have the resources to test as extensively as SQLite.

blub 9y ago
It's more than that, it's a manipulative comment, designed to put others on the defensive about their own skills and muddle the issue. Any real-world project will be developed unter specific time constraints and have a certain budget. There will be a mix of developers and other roles in the team, with varying skills. There will be politics involved and the project will probably be in use for decades, ensuring that all of the above will significantly change during its lifetime. Under such conditions, C is an abject failure at supporting robust, quality code, because it neither benefits from a culture of safety (like Ada or even Rust) nor does it have any enforceable safety switches or indeed safety-by-default. Anything that can be screwed up, will be screwed up over the years by someone, some configuration option, procedure or project management decision. Java is on average significantly safer than C or C++, because no matter what happens, the language won't allow certain errors to happen. C can be assumed to be a hopeless case, but a purely theoretical way of avoiding these kinds of issues is to have a sufficient supply of bsenftner clones which will supervise a project through its development and operation until it's retired from production (assuming bsenftner is as awesome as they say).
buserror 9y ago
I agree, I'm paid by the hour to deliver a set of features, and the client very, VERY rarely would pay for me to start 'diverging' and writing test cases for something they see as superfluous. A bit of field tests (ie, users as testers) and if it works, it ships. I don't make the rules. The scary bit is, often, it works just fine; in many cases, it's cheaper to reboot/relaunch for a 1/100000 crashing bug than paying me to find it and fix it!
- Yoric 9y ago
  That's one of the reasons I'm pretty happy to work in a place where my manager will generally agree if I tell them that I'm planning to spend the next 3 months improving the test suite or harness or adding one layer of safety to eliminate a class of bugs or adding a new static analysis. Of course, this is also a place where we practice static analysis, continuous integration, code reviews and we're now progressively migrating code to Rust.