🚀 go-pugleaf

me: Consider an arbitrary program, with (for example) several thousand
me: variables and a few dozen types.  If the program says: f(x), what
me: does static typing buy you, security-wise?  You can only
me: misidentify x a few hundred ways instead of a few thousand?
me: (Awesome reliability there).

Norman Diamond:
   Exactly.  In this scenario, if you misidentify x, there is a 90%
   chance that your error will be caught.  This is 9 times as valuable
   as a case previously discussed, where other fields of engineering
   value a 10% improvement in safety.

Enumerating the number of ways a variable may be misidentified does
not properly identify the chances that it will be caught.  Run-time
insanity checks can provide a degree of robustness that is not
available using only compile time checks.

Just because your language will not catch certain errors except with
static typing doesn't mean that my language has the same problem.
Also note that dynamic typing allows wonderful properties in a
debugger.

Note that I'm classifying as type checking: array bounds checking,
un-assigned variable checking, range checking, storage class checking
and exceptional values checking.  A compiler can catch some instances
of un-assigned variables, and some instances of storage class
checking.  It's not going to be able to check anything dynamic (except
the static references). A really good compiler might be able to catch
_some_ instances of value out of range.

Ultimately, making the programmer work to make sure that variable Quad
is not assigned to variable Tape is not going to do anything to make
sure that Quad is being used correctly -- it's just going to make sure
that one of many stupid mistakes is not made.

me: Unless you are intending to allow only one instance of a type in
me: any lexical name-space?  That would be security!  [And you'd be
me: writing your program at least twice, once in "type expressions",
me: and once in "imperative expressions".  There's nothing quite like
me: trying to keep two versions of the same thing in sync to improve
me: reliability...]

Norman Diamond:
   Although excessive and rhetorical, this also has its value.  Why
   did businesses used to use "verifiers" on their punched cards for
   data entry?  Why do fault-tolerant machines compute many results
   twice?  You'd better believe there is nothing like redundancy to
   improve reliability.

Why do some machines associate type with a variable at runtime?  Could
it be because there is nothing like redundancy to improve reliability?

(yeah, I'm leaving out an issue here:  additional features which come
with a typing system.  Some such features are gratuitous, some are so
significant that they make reliability arguments pale.)

Raul Rockwell