🚀 go-pugleaf

David Gudeman writes:

]In article  <8872@skye.cs.ed.ac.uk> Nick Rothwell writes:
]]
]]No runtime *type* errors. Runtime errors are restricted to a small set of
]]exception conditions defined by the language.

]The only runtime error you have eliminated with static type checking
]is a "message not understood" or "domain error".  The elimination of
]this single type of error hardly seems to justify the limitations on
]expressiveness -- particularily since this is the easiest type of
]error to find by testing.

  Yes, a statically typed language, of course, still leaves all kinds of holes
for all kinds of bugs...

]The only reason you can kind find type errors at compile time is
]because the errors are so trivial that the test is decidable.  How
]much are you willing to give up in expressiveness to find the most
]trivial and obvious programming error a few minutes earlier?

  What about the type error that only shows up under rare circumstances?  It
is quite possible that production software may contain some hidden type error
that only shows up if the user performs action A, followed immediately by
action B, and then immediately performs action A again.  (OSTTE).  This may
or may *not* be caught by testing.

  However, with a statically (or dynamically) typed language, it is of course,
possible to have hidden bugs that have nothing to do with type.   

  Many C (or C++) programmers can be found who write code like this:

void  printXValue( someType  *p)
{
  printf("%d\n", p->x);
}

  The code will type check, and thus get by the compiler if x is a valid
member of the type someType.  However, what if, under some strange circumstance,
the function printXValue() is passed a NULL pointer?  I am amazed by the number
of people who insist that a language type check, but turn around and assume that
their functions will never be passed a bad pointer.

  Writing code that *appears* to be type-safe to a compiler is only a small
part of the whole issue of writing correct code.  There is no question that
a dynamically typed language increases the risk that an error may occur during
runtime that the software is not prepared to handle.  Of course, dynamically
typed languages permit more generic (and therefore reusable) code.  Thus,
we have a tradeoff.  Two questions then arise:

1)  What is the possiblity that a type error will occur at runtime? 
2)  Is the expressiveness provided by a dynamically typed language worth the 
    possiblity of a runtime type error?