"Strong typing vs. strong testing"

[Nick Keighley]

On 1 Oct, 19:33, RG <rNOSPA... at flownet.com> wrote:
> In article <slrniabt2j.1561.usenet-nos... at guild.seebs.net>,
>  Seebs <usenet-nos... at seebs.net> wrote:
> > On 2010-10-01, RG <rNOSPA... at flownet.com> wrote:

<snip>

> > >> Those goal posts are sorta red shifted at this point.
[...]
> > > Red shifted?
>
> > Moving away fast enough that their color has visibly changed.

doppler shift for instance or one of them cosmological thingies when
space itself stretches

<snip>

> > In a statically typed language, the of-the-wrong-type is something which
> > can, by definition, be caught at compile time.
>
> Any time something is true "by definition" that is an indication that
> it's not a particularly useful fact.

I'm not sure I agree. On occaision knowing something is true-by-
definition is very useful!

> The whole concept of "type" is a
> red herring.  It's like this: there are some properties of programs that
> can be determined statically, and others that can't.  Some of the
> properties that can't be determined statically matter in practice.  But
> all of the properties that can be determined statically can also be
> determined dynamically.

sometimes with quite a lot of effort. I know the halting problem gets
thrown around a lot but to execute every path may take an inordinate
amount of effort.

>  The *only* advantage that static analysis has
> is that *sometimes* it can determine *some* properties of a program
> faster or with less effort than a dynamic approach would.

agreed


> What I take issue with is the implication made by advocates of static
> analysis that static analysis is somehow *inherently* superior to
> dynamic analysis,

probably a fair point


> that static analysis can provide some sort of
> "guarantee" of reliability that actually has some sort of practical
> meaning in the real world.  It doesn't.  The net effect of static
> analysis in the real world is to make programmers complacent about
> properties of programs that can only be determined at run time, to make
> them think that compiling without errors means something,

who are these people?  I don't think I've ever met any programmer that
claimed a clean compile implied a correct program. Ada people come
close with things like "when you finally get an Ada program to compile
you've got a good chance it's actually right". Part of their
justification is that you tend to have to think hard about your type
system up front. But given the fields Ada programmers typically
operate in I don't think they'd dare ship a program that merely
compiled.

> and that if a
> program compiles without errors then there is no need for run-time
> checking of any sort.

again this is a massive straw man. Yes, people who claim this are
wrong. But they are much less prevalent than you claim.

Though the lack of enthusiasm I encounter when I suggest the liberal
use of assert() is a data point in your favour.

> *You* may not believe these things, but the vast
> majority of programmers who use statically typed languages do believe
> these things, even if only tacitly.

not the programmers I've encountered

> The result is a world where
> software by and large is a horrific mess of stack overflows, null
> pointer exceptions, core dumps, and security holes.
>
> I'm not saying that static analysis is not useful.  It is.  What I'm
> saying is that static analysis is nowhere near as useful as its
> advocates like to imply that it is.  And it's better to forego static
> analysis and *know* that you're flying without a net at run-time than to
> use it and think that you're safe when you're really not.

obviously some of us disagree