Python for large projects

[Jacek Generowicz]

Joe Mason <joe at notcharles.ca> writes:

> In article <tyfptb22o9u.fsf at pcepsft001.cern.ch>, Jacek Generowicz wrote:
> > Sometimes I want to run a program that I _know_ full well is full of
> > bugs, dammit!  During the whole of the development process, the
> > program is full of bugs, by definition ... I still want to be able to
> > see how it behaves, in order to investigate what to do about
> > it. Static type systems all too often forbid me to do this. (Even
> > Hindley Milner type systems.)
> 
> But, like you said, type errors are the most trivial kinds of errors.
> Why do you want to know what'll happen if you pass it a float instead of
> an int, when you know full well that can never happen in practice due to
> static typing?

I probably wouldn't want to check what happens when I pass a float
instead of an int, but a static type system is quite likely to
complain about my "passing a float instead of an int"[*] in one part
of the program when I am actually trying to see what happens when I
try changing an int to a float in some other part of the program. (So
I try changing the int the static type system found for me,
temporarily, in order to proceed with my trial ... but then it
complains about another float-int mismatch a bit further along ... so
I try changing that int, and then it complains about ... you get the
picture. By the time I've satisfied the type system, I've completely
forgotten what it was that I was trying to do in the first
place. Sound familiar to anyone ?)


[*] I trust that we all understand that this phrase represents inane
    type errors in general.