"Strong typing vs. strong testing"

[RG]

In article <slrnia86l9.2esf.usenet-nospam at guild.seebs.net>,
 Seebs <usenet-nospam at seebs.net> wrote:

> On 2010-09-30, RG <rNOSPAMon at flownet.com> wrote:
> > Of course.  Computers always do only exactly what you ask of them.  On 
> > this view there is, by definition, no such thing as a bug, only 
> > specifications that don't correspond to one's intentions.  
> 
> f00f.
> 
> That said... I think you're missing Keith's point.
> 
> > Unfortunately, correspondence to intentions is the thing that actually 
> > matters when writing code.
> 
> Yes.  Nonetheless, the maximum() function does exactly what it is intended
> to do *with the inputs it receives*.  The failure is outside the function;
> it did the right thing with the data actually passed to it, the problem
> was a user misunderstanding as to what data were being passed to it.
> 
> So there's a bug -- there's code which does not do what it was intended
> to do.  However, that bug is in the caller, not in the maximum()
> function.
> 
> This is an important distinction -- it means we can write a function
> which performs that function reliably.  Now we just need to figure out
> how to call it with valid data... :)

We lost some important context somewhere along the line:

> > > in C I can have a function maximum(int a, int b) that will always
> > > work. Never blow up, and never give an invalid answer. If someone
> > > tries to call it incorrectly it is a compile error.

Please take note of the second sentence.

One way or another, this claim is plainly false.  The point I was trying 
to make is not so much that the claim is false (someone else was already 
doing that), but that it can be demonstrated to be false without having 
to rely on any run-time input.

rg