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.