[Python-ideas] Why is design-by-contracts not widely adopted?

[Rhodri James]

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