Hacker News Reader

Comment by fermigier | Hacker News Reader

A reference for your dissertation?

The usefulness (or lack thereof) of contracts was famously discussed in 1997 in this paper: https://www.irisa.fr/pampa/EPEE/Ariane5.html (with additional comments here: https://www.irisa.fr/pampa/EPEE/Ariane5-comments.html ).

I have tried several times (a couple of decades ago) to introduce DBC in Python, using one of the many available libraries (for an overview: see https://lab.abilian.com/Tech/Python/DbC%20in%20Python/ ) but, like you, wasn't convinced.

I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.

View on HN

> I believe your argument on the performance penalty is right, and as a corollary, this implies that contracts are mostly useful if associated with a formal proof system. Contracts in production are probably a bad idea, in most cases.

Agree! There is a sliding scale between testing contracts and proving them too. My labor of love for the past several years has been a tool for checking Python contracts using an SMT solver (using symbolic inputs over concrete paths): https://github.com/pschanely/CrossHair

That said, these days I think property-based testing gets you the ~same benefits as contracts, and is easier for most people to apply.

Wow, people miss the point of contracts. You never want to turn them off in production, because that's where all the weird shit happens that you never thought of. Contracts catch bugs in those times. Maybe people find them useless precisely because they turn them off.

Finally, somebody said it! I am always bemused when people say they turn off contracts in production code. They don't understand the difference between contracts (a program state guarantee) and testing for special/error cases (must be handled explicitly). The excuse usually given is runtime performance which can be mitigated by using a subset from pre/post-conditions/invariants.

C++ contracts as currently designed can execute 4+ times per call to do full checking. That gets expensive quickly.

But they also give you 4 different evaluation semantics (ignore, observe, enforce, quick_enforce) to tweak as needed. You don't need to do full checking everywhere and always.

Exactly. What I do is litter my code with contracts. I then profile to find the hot loop and minimize (not turn them off) there. For the 99% of the other code, the user won't notice any slowdown.

The value is just too high to turn them off in production. Do you want bug free code? This is the only way I know how to do it.

Reply on news.ycombinator.com