Python from Wise Guy's Viewpoint

[Pascal Costanza]

William Lovas wrote:

> 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.

For example, static type systems are incompatible with dynamic 
metaprogramming. This is objectively a reduction of expressive power, 
because programs that don't allow for dynamic metaprogramming can't be 
extended in certain ways at runtime, by definition.

>>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?

You need some testing discipline, which is supported well by unit 
testing frameworks.

> 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).

Yes, thinking about a problem to understand it better occasionally helps 
to write better code. This has nothing to do with static typing. This 
could also be achieved by placing some other arbitrary restrictions on 
your coding style.

>>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.

Such code would easily be caught very soon in your unit tests.


Pascal