On Wed, Sep 26, 2018 at 6:36 PM Paul Moore email@example.com wrote:
On Wed, 26 Sep 2018 at 06:41, Chris Angelico firstname.lastname@example.org wrote:
On Wed, Sep 26, 2018 at 2:47 PM Marko Ristin-Kaufmann email@example.com wrote:
- The contracts written in documentation as human text inevitably rot and they are much harder to maintain than automatically verified formal contracts.
Agreed, if contracts are automatically verified. But when runtime cost comes up, people suggest that contracts can be disabled in production code - which invalidates the "automatically verified" premise.
Even if they're only verified as a dedicated testing pass ("okay, let's run the unit tests, let's run the contract verifier, let's run the type checker, cool, we're good"), they're still better off than unchecked comments/documentation in terms of code rot. That said, though: the contract for a function and the documentation for the function are inextricably linked *already*, and if you let your API docs rot when you make changes that callers need to be aware of, you have failed your callers. Wholesale use of contracts would not remove the need for good documentation; what it might allow is easier version compatibility testing. It gives you a somewhat automated (or at least automatable) tool for checking if two similar libraries (eg version X.Y and version X.Y-1) are compatible with your code. That would be of some value, if it could be trusted; you could quickly run your code through a checker and say "hey, tell me what the oldest version of Python is that will run this", and get back a response without actually running a gigantic test suite - since it could check based on the *diffs* in the contracts rather than the contracts themselves. But that would require a lot of support, all up and down the stack.