"Strong typing vs. strong testing"

[Tim Bradshaw]

On 2010-09-30 13:36:17 +0100, Nick Keighley said:

> there are some application domains where neither option would be
> viewed as a satisfactory error handling strategy. Fly-by-wire, petro-
> chemicals, nuclear power generation. Hell you'd expect better than
> this from your phone!

People always give these kind of scenarios, but actually there are far 
more mundane ones.  In my day job I'm a sysadmin and I spend a bunch of 
time writing code (typically what would nowadays be called "scripts" 
rather than programs, but there's no real difference) which does things 
of the form

	for every machine in <several hundred systems>
	do <something>

where <something> is fairly often "modify critical system configuration file".

Programs like that have some absolute, non-negotiable requirements:
- they must never fail silently;
- they must check everything they do however unlikely it seems that it 
would failm
  because they will come across systems which have almost arbitrary 
misconfiguration.
- they should be idempotent if possible;
- if they come across something odd they either need to handle it,
  or put things back the way they were and back out;
- if they absolutely can not put things back, they need to report this 
very clearly
  and carefully preserve any detriitus in such a way that a human can 
pick up the bits;
- whatever they do they need to report in a completely parsable way 
what happened
  (success, failure, already done, backed out, not backed out, and so on).

These are quite mundane everyday things, but the consequences of 
getting them wrong can be quite nasty (the worst ones being "the 
machines will still run, but won't boot").