Python for large projects
crap1234 at hotmail.com
Wed Mar 24 16:31:45 CET 2004
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
> - Test suites point out where your program deviates from expected
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 Axelsson (email at http://www.cs.chalmers.se/~sax)
More information about the Python-list