Python from Wise Guy's Viewpoint

[William Lovas]

In article <bn687n$l6u$1 at f1node01.rhrz.uni-bonn.de>, Pascal Costanza wrote:
> Marshall Spight wrote:
>> But why should more regression testing mean less static type checking?
>> Both are useful. Both catch bugs. Why ditch one for the other?
> 
> ...because static type systems work by reducing the expressive power of 
> a language. It can't be any different for a strict static type system. 
> You can't solve the halting problem in a general-purpose language.

What do you mean by "reducing the expressive power of the language"?  There
are many general purpose statically typed programming languages that are
Turing complete, so it's not a theoretical consideration, as you allude.

> This means that eventually you might need to work around language 
> restrictions, and this introduces new potential sources for bugs.
> 
> (Now you could argue that current sophisticated type systems cover 90% 
> of all cases and that this is good enough, but then I would ask you for 
> empirical studies that back this claim. ;)

Empirically, i write a lot of O'Caml code, and i never have to write
something in a non-intuitive manner to work around the type system.  On the
contrary, every type error the compiler catches in my code indicates code
that *doesn't make sense*.  I'd hate to imagine code that doesn't make
sense passing into regression testing.  What if i forget to test a
non-sensical condition?

On the flip-side of the coin, i've also written large chunks of Scheme
code, and I *did* find myself making lots of nonsense errors that weren't
caught until run time, which significantly increased development time
and difficulty.

Furthermore, thinking about types during the development process keeps me
honest: i'm much more likely to write code that works if i've spent some
time understanding the problem and the types involved.  This sort of
pre-development thinking helps to *eliminate* potential sources for bugs,
not introduce them.  Even Scheme advocates encourage this (as in Essentials
of Programming Languages by Friedman, Wand, and Haynes).

> I think soft typing is a good compromise, because it is a mere add-on to 
> an otherwise dynamically typed language, and it allows programmers to 
> override the decisions of the static type system when they know better.

When do programmers know better?  An int is an int and a string is a
string, and nary the twain shall be treated the same.  I would rather
``1 + "bar"'' signal an error at compile time than at run time.

Personally, i don't understand all this bally-hoo about "dynamic languages"
being the next great leap.  Static typing is a luxury!

William