On 25/09/18 21:09, Lee Braiden wrote:
Eh. It's too easy to cry "show me the facts" in any argument. To do that
too often is to reduce all discussion to pendantry.
I will resist pointing out the spelling mistake... oh damn :-)
The trouble with not crying "show me the facts" is that it is very easy
to make beautiful sounding assertions into a vacuum that fall apart the
moment you subject them to reality. I'm sure we can all think of
politicians of a variety of parties and nationalities with an
unfortunate habit of doing exactly that.
Marko is making some very big assertions about how much of a benefit
Design by Contract is. I flat-out don't believe him. It's up to him to
provide some evidence, since he's the one pressing for change.
That verifying data against the contract a function makes code more
reliable should be self evident to anyone with even the most rudimentary
understanding of a function call, let alone a library or large
application.
Let's assume that the contracts are meaningful and useful (which I'm
pretty sure won't be 100% true; some people are bound to assume that
writing contracts means they don't have to think). Assuming that you
aren't doing some kind of wide-ranging static analysis (which doesn't
seem to be what we're talking about), all that the contracts have bought
you is the assurance that *this* invocation of the function with *these*
parameters giving *this* result is what you expected. It does not say
anything about the reliability of the function in general.
It seems to me that a lot of the DbC philosophy seems to assume that
functions are complex black-boxes whose behaviours are difficult to
grasp. In my experience this is very rarely true. Most functions I
write are fairly short and easily grokked, even if they do complicated
things. That's part of the skill of breaking a problem down, IMHO; if
the function is long and horrible-looking, I've already got it wrong and
no amount of protective scaffolding like DbC is going to help.
It's the reason why type checking exists,
Except Python doesn't type check so much as try operations and see if
they work.
and why bounds checking exists,
Not in C, not most of the time :-)
and why unit checking exists too.
Unit tests are good when you can do them. A fair bit of the embedded
code I write isn't very susceptible to automated testing, though, not
without spending twice as long writing (and testing!) the test
environment as the code.
--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
