The Industry choice
donn at drizzle.com
Sat Jan 1 13:39:01 EST 2005
Quoth Hans Nowak <hans at zephyrfalcon.org>:
| Paul Rubin wrote:
|> You should write unit tests either way, but in Python you're relying
|> on the tests to find stuff that the compiler finds for you with Java.
| As I wrote on my weblog a while ago, I suspect that this effect is
| largely psychological. You jump through hoops, declaring types all over
| the place, checking exceptions, working around the language's
| limitations, etc. So when your code compiles, it *feels* safer. Like
| you're at least part of the way towards ensuring correctness. All that
| work must be good for *something*, right? Never mind that when writing
| unit tests for a dynamic language, you don't check for these things at
| all. How often do you explicitly check types in Python unit tests?
| IMHO, when using a dynamic language, you don't need most of the checks
| that Java, C# and their ilk force upon you.
I have been fooling around with strongly, statically typed languages
for a couple of years, in my spare time - Objective CAML, Haskell,
O'Haskell. This is a little different experience than what you two
are talking about - I don't think Java, C# and their ilk are quite as
rigorous, nor do they use type inference - but as much as it would
probably gag an FP enthusiast to say this, the basic idea is the same.
I can only believe that if you think the benefit of static typing is
psychological, either something is very different between the way you
and I write programs, or you're not doing it right.
For me, the effect is striking. I pound out a little program, couple
hundred lines maybe, and think "hm, guess that's it" and save it to
disk. Run the compiler, it says "no, that's not it - look at line 49,
where this expression has type string but context requires list string."
OK, fix that, iterate. Most of this goes about as fast as I can edit,
sometimes longer, but it's always about structural flaws in my program,
that got there usually because I changed my mind about something in
midstream, or maybe I just mistyped something or forgot what I was doing.
Then, when the compiler is happy -- the program works. Not always, but
so much more often than when I write them in Python.
Now you may repeat here that we all must make thorough unit testing
a cornerstone of our Python programming, but don't tell me that the
advantage of static typing is psychological. It does substantially
improve the odds that a program will be correct when it runs, because
I have seen it happen.
If unit testing does so as well, then obviously there will be some
redundancy there, but of course only where you actually have complete
coverage from unit testing, which not everyone can claim and I'm sure
even fewer really have. And like the man said, you're doing that work
to find a lot of things that the compiler could have found for you.
Donn Cave, donn at drizzle.com
More information about the Python-list