|
The problem of C is the success of C. There have been some good, secure, large codebases written in it. Some truly beautiful code, when you scrutinize it. This creates the illusion that the language itself may be safe, if only you do everything right. That last part is often forgotten by the time people make the decision to write something large in it. There is no problem with safety nets. Good debuggers (extreme ones like Common Lisp, allowing you to rewrite broken code on the fly and resume from that spot). Good type systems (Ada, the MLs, going so far as to eliminate most errors regarding common mistakes like array-out-of-bound exceptions). Good test suites (comprehensive unit and regression test suites, fuzz testers) which are, admittedly, more pervasive across many languages (the option is available, at least). Formal methods (even the lighter weight ones, like design-by-contract). Automation, to minimize the impact of human error and fat-fingering things. There should be no concern about choosing a language which is semantically closer to your problem domain, but perhaps of slightly reduced performance, than a language that is semantically distant (see people writing half of Prolog into their complex code base involving knowledge bases and decision trees). Maybe some people will think you're not tough enough, but at least your code doesn't piss off every user. We cannot trust ourselves to do the right thing at all times. Consequently we must decide on the language and environmental elements which can enforce the right thing, while minimizing the impact to developing our solutions in a reasonable amount of time. |
Citation needed. The only one I'm aware of is SQLite, which has an order-of-magnitude more test code than implementation code and still fuzzers are able to find new memory safety bugs in it.