I agree. SQLite gets away with using C because it literally uses military-grade levels of verification. As John Regehr pointed out, SQLite is quite possibly the only piece of software that goes to that level of validation and testing without being required to by law.
It's not just a matter of skill, either. The cost in terms of money and time needed to develop software in that way is completely impractical in almost any commercial scenario. Aside from some very specific situations, it's not an economically viable way to produce software.
it is not economically viable for entertainment or disposable "apps", but extremely required for any serious, mission critical software. Seriously, the comments here betray how many people are in disposable software careers.
The comments here betray how much of the software economy depends on developer productivity. The fact is that SQLite style verification is not practical for almost any software, very much including "mission-critical" software.
Yes, but look how much of the software economy's infrastructure* depends on underfunded products. OpenSSH, GnuPG and OpenSSL are just 3 projects which are installed on pretty much every Linux server on the internet, including the servers of billion-dollar-businesses. It got a lot better in recent years, but still: Quite a few economically viable software companies just depend on free labor for mission-critical software product which take a lot of resources to become solid.
Can't it be both? We need it right now and we don't need to to work perfectly or last forever.
Really, we're talking about the same thing like they're two separate things: The software [1] (in this case, SQLite) and the application (whatever tables, queries, etc. you need to solve your problem) are used together. So we build the poorly tested, quick and dirty application on top of the well tested, solid software.
[1] Yes, I realize that "software" is a terribly generic term to use to mean "well designed and tested software" and that "application" is also a terribly generic term to use to mean "hastily designed and untested software". Feel free to mentally substitute your own terms if you have better ones.
I wish that were true. I've worked on products that are very much not "disposable" and I've seen some terrible code and very poor testing infrastructure. It's especially bad in shops that were not primarily writing software and had to integrate software solutions to remain competitive. Execs don't understand it, don't care for it, don't invest enough resources in it. It's often delegated to some 3rd party and integrated like a black box in their solution.
First: Apps can definitely be mission-critical. If you're lost somewhere dangerous, your GPS and mapping app can be as mission-critical as it gets. Your app which makes a phone call (and, yes, I'm calling the be-a-phone functionality of a cell phone an app here) can be mission-critical.
Is that software held to the standards of mission-critical software? Probably not.
Second: There's a lot of space between the software which is recognized as being mission-critical and software which is just Bioware's latest patch target, and that software includes things like web browsers and the web server software which hosts your company's website. Given how essential a web presence is to, you know, being able to make money, web server software is hardly disposable, but it is not held to the rigorous standards of mission-critical software.
In Germany there are strict regulations if you're writing secure software, especially under the lens of BSI and of the Bundesdruckerei. Softwares which deal with eID are verified and certified with strict rules
> In Germany there are strict regulations if you're writing secure software, especially under the lens of BSI and of the Bundesdruckerei. Softwares which deal with eID are verified and certified with strict rules
just curious, does this extend to dependent libraries as well ?
Most/All these tests are done by machine. Debugging (in production) (while your service is down) costs much more then writing a bunch of tests. The more states your program can be in the more rigorous tests are needed.
It's not just a matter of skill, either. The cost in terms of money and time needed to develop software in that way is completely impractical in almost any commercial scenario. Aside from some very specific situations, it's not an economically viable way to produce software.