steve+comp.lang.python at pearwood.info
Tue Mar 4 12:47:53 CET 2014
On Tue, 04 Mar 2014 11:56:07 +0100, Antoon Pardon wrote:
> Op 04-03-14 09:56, Steven D'Aprano schreef:
>>> If you
>>> explicitly say that this is an int, then yes, that should be
>> It's that "explicitly" part that doesn't follow. Having to manage types
>> is the most tedious, boring, annoying, *unproductive* part of languages
>> like Java, C and Pascal. Almost always, you're telling the compiler
>> stuff that it can work out for itself.
> In the same way writing unit tests is the most tedious, boring,
> annoying, *unproductive* part.
Actually, I like writing unit tests. How do you know what the function
does until you test it? I'm not a TDD fanatic, but often I write tests
before I write the code, and there's really nothing nicer than seeing a
whole lot of failing unit tests suddenly start working.
Well, maybe a nice BLT sandwich, when the bacon is nice and lean and the
lettuce crisp and the tomato flavourful and not too soggy. But other than
that, writing unit tests and seeing them pass is great.
On the other hand, writing
int n, m
double x, y
and similar three hundred times throughout your program is not terribly
exciting. Even when it compiles, it doesn't mean it works.
> Amost always you are giving the program
> results it can work out for itself.
Not even close. I'd like to see the compiler that can work out for itself
that this function is buggy:
def sine_rule(side_a, side_b, angle_a):
"""Return the angle opposite side_b."""
If you don't remember your Sine Rule from trigonometry, that's okay.
Trust me, the function is badly wrong. It's rubbish really. But short of
some really impressive AI coupled with a Mathematica-level of maths
knowledge, how is the compiler supposed to know that?
Static type testing, while valuable, cannot tell you that the program
does what you wanted it to do.
More information about the Python-list