Chandrashekhar Mullaparthi wrote:
Verifying the output is not practical for the average end user except for the most trivial piece of software.
A serious discussion on this would be very long :-) However, we may briefly check on this, so that we may practically benefit out of this discussion.
So far as office suites and text editors are concerned, the output is fairly obvious and we can take back up of the files we create. Even if the software fails, we can simply reinstall or use some other machine with our back up files and continue with our work. We may also backup the contents of directories containing valuable files. The only verification we do in these cases, is check if the backup is written correctly.
I use PostgreSQL database server. The backup for my database is done merely with:
# pg_dump dbname > dbdumpname
dbdumpname is a mere text file, that we could open with a text editor and read. I could check on every thing: from the database schema to the contents of the table. If it is a very large database, we can break up the output and share work among different users. In the case of a crash, I may use the backup merely with:
# dropdb dbname # createdb dbname # psql -e dbname < dbdumpname
Generally, every application worth its name maintains error logs that enable bug fixing and trouble shooting. Some sort of feedback system should be available if not already there.
Practically, some kind of checking on the output directly with our senses, through the same machine or a different machine is generally possible. My fair rent calculator script is more than 50K long but the ouput may be only 10 to 15 lines long, and the user may concern himself with just this, and not really worry about the 50K of source code. PostgreSQL is a complex application I use, and the output can be reasonably verified, both while actually using and through backups.
Further, is not eternal vigil always desirable? This is a must, if we desire to remain in control of our computers.