Python for large projects

[Stefan Axelsson]

Jacek Generowicz wrote:
> As this statement appears to be causing some interest, I thought I'd
> best prestent, in public, a slightly more thoughtful summary of my
> thoughts on the subject:

Ah, a static vs dynamic typing argument! A perennial favourite on 
comp.lang.functional. And incidentally on one of my places of work, 
Ericsson, where we use Erlang (dynamic typing).

> - Static typing systems refuse to compile programs which contain type
>   errors.
> 
> - Test suites point out where your program deviates from expected
>   behaviour.

You're really not comparing like with like here. While the first 
statement is true on the face of it. The second is also true on the face 
of it, but probably not what you meant. It's that if the unit tests have 
been designed to find deviations from the 'expected' behaviour they 
will. Whether the 'expected' behaviour was actually the 'specified' 
behaviour is another question entirely. Programmers/designers 
misunderstanding the specification is all to common an occurrence.

So, in the case of unit testing the specification has to be interpreted. 
And there's nothing to stop the programmer to take advantage of a static 
typing system to make the same interpretation, aka 'typeful 
programming'. There's little difference between thinking up a test case 
and a type during the design. (And you have to do both anyway).

It should be noted that I speak of Hindley Milner type typesystems. I.e. 
that do type inference and can handle polymorphism in data structures as 
in e.g. Haskell.

I've found that a problem with making this restriction is that someone 
always draws up 'C' or 'C++' as an example of 'static typing' and by all 
means, if that's what you're comparing against, then allmost anything 
would be an improvement. However they're not state of the art and any 
example drawn from the that world is not an argument against static 
typing per se.

> What is more important to you and/or your clients ?  Ask yourself the
> following questions:
> 
> - Do your clients give a hoot about whether or not a program is
>   considered to be type-correct by the type system of programming
>   language X ?
> 
> - Do your clients care whether your program does what it is supposed to
>   do ?

As I said. Given typeful programming the first statement is more or less 
the same as the second. And the second doesn't follow from your 
statements above, there's a crucial difference. (That typeful 
programming doesn't solve either, granted). One of my job titles is 
requirements bureaucrat, so I've seen this time and time again.

Myself, I've moved from O'Caml (strong static typing with type inference 
and polymorphism) to Python, so I've found that the benefits outweigh 
the drawbacks. That's not to say that I don't miss the typechecker. I 
do. I don't see how it could be grafted onto Python though without 
changing it to something else.

Stefan,
-- 
Stefan Axelsson  (email at http://www.cs.chalmers.se/~sax)