Mike Bayer: I don’t think it’s usually very bad in practice. Especially for the places where runtime checks are most applicable, which is inside larger integration projects, as opposed to small reusable libraries. Though reusable libraries also should have good checks, as it makes the library much more pleasant to use. So… maybe it applies to both. Either way, I don’t think the efficiency is a big problem, and that it’s a good tradeoff. A simple assertion is generally quite fast.

Also, these checks are often best to put in in response to real errors, found during debugging (even during debugging of code written with TDD, as TDD also implies lots of failing tests). The total number of errors you could check for is huge, but the number of errors that a programmer is likely to make is much smaller. So maybe coming back to Michael’s post, this actually does make sense along with TDD, as you still have lots of bugs in a TDD process, those are just the bugs you pre-identified using TDD, and fixing the test and writing the code becomes the same thing.

The mere fact that static typing produces these errors at compile time is a detail, it just means that some contracts could (or should?) be checked at run time.

Tests (and similarly runtime contract checks) are not that suitable, if you want to enforce certain rules across the whole code base. I learned to program by designing types, so certain (design?) errors that I encountered during development are impossible (or very hard) to express using the new types. For example, when I find a bug, I always think: “could the bug fix be expressed as a type?”. If it is, you introduce the new type and delete the old one and the compiler will simply flag all possible bugs (= usage of old type) for you**.

Of course, it takes quite some practice to design classes/functions in a way, that bugs will actually be prevented AND your team members will understand you code. I do use both unit and functional tests in addition because it is more suitable for more localized type of bugs, though.

So, the last 6 years on the project were largely just a constant iteration (sound familiar?:) of type modifications hugely aided by static compiler checks.

** Note, this isn’t just refactoring, which is done in dynamic languages. For example, we introduced new multi-threading primitives, because old ones were found to be problematic in certain cases. You might know, that multi-threading is simply not testable dynamically (not with current tools at least), you just have to enforce it statically.

how do you deal with the performance latency as well as source code bloat introduced by injecting argument checkers throughout all methods and functions ? what I like about unit tests is that you can get similarly good results without weighing down the application’s core functionality, with the “argument checkers” focused mainly on the public-facing API functions. its still “design by contract” but the contract lives externally, with no restrictions on how deeply and completely it can validate functionality.

Having a full test suite is a great side effect that is very useful for refactoring, but it is only a side effect.

(Your ‘Website’ field in the comment form doesn’t allow enough characters by the way!)

Anyway, it’s still an open area of research. We will have practical results from it eventually though!

Of course a contract can also get kind of expensive at runtime. E.g., for item in seq: assert item is None or isinstance(item, int). You have to consider just how far you are willing to go to check values up-front. But then an assert in the middle of a function (e.g., inside a for loop) can be just as good, and often much cheaper.

The idea is that, in a dependently typed language (one in which your types can depend on the values… which sounds weird but these can be statically checked), you pass around proofs. That is, arguments in your functions call for propositions (preconditions to assert), and calling these functions will only compile if you supply appropriate proofs of these propositions. Likewise, the function can return proofs (postconditions) to be used elsewhere as well. That’s a very rough metaphor of what you actually do, anyway.

So design by contract isn’t really a substitute for static typing after all, since it can be statically checked!