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.

And while we are at it: http://www.openbsdfoundation.org https://gnupg.org/donate/ https://www.openssl.org/support/donations.html

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.

I think you're using the words differently than the post you're replying to. As defined in that post:

"apps": entertainment or disposable

"software": serious, mission critical

Aside from the difference in terminology, it sounds like your opinions go in the same general direction.

Regarding the viability, another thing to consider is that C gives you an ubiquitous compatibility.

The Opus codec has an impressive amount of testing behind it as well:

https://www.ietf.org/proceedings/82/slides/codec-4.pdf

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 ?

Yup

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.

SQLite went through thorough testing, not verification.

These are two different things.

> SQLite went through thorough testing, not verification. These are two different things.

I think you're confusing the terms "formal verification" and "verification". Testing is a subset of verification, but not of formal verification.

SQLite is litteraly used by the military in their Android phones.

It's literally used by every Android phone, military or not. It can be used in iOS apps, too.