Static typing, Python, D, DbC

[Bearophile]

John Nagle:

> All signed Windows 7 drivers must pass Microsoft's static checker,
> which checks that they don't have bad pointers and call all the
> driver APIs correctly.

I didn't know this, thank you. I'll read more about this topic.

----------------

Eric S. Johansson:

> If you are careless, assertions can build up to a
> significant percentage of the code base and Slow execution. the argument for
> dealing with this, last time I looked, was that you turn off assertions when
> your code is "running". This logic is flawed because bugs exist and will assert
> themselves at the worst possible time which usually means after you turned off
> the assertions.

These are real problems.

In some situations the code is "fast enough" even with those runtime
tests, so in those situations it's better to keep them active even in
release builds or when you use the program (this is often true for
small script-like programs).

But in some situations you want a faster final program. Running the
run-time contracts only when you test the code and removing them when
you run the program for real sounds silly or dangerous. But life is
made of trade-offs, and running those contracts during testing is
better than _never_ running them. In practice if your tests are done
well enough (they are similar to the real usage of the program), the
contracts are able to catch most of the bugs anyway before the release
build.

The run-time contracts may slow down the code, but there are few ways
to reduce this problem. You have to write your contracts taking care
of not changing the computational complexity of the routine/method
they guard (so you usually don't want to perform a O(n) test for a
routine with O(n ln n) worst-case complexity).

You run your tests often, so if some tests are too much slow you see
it soon and you may fix the problem (the same is true for slow unit
tests).

In D there are several ways to "layer" the work you perform at
runtime, there is not just the release build and test build. You have
the version and debug statements, you may use them inside DbC
contracts too. So in normal test builds I use faster contracts, but if
I spot a bug I lower the debug level and I recompile the D code,
activating heavier tests, to better spot where the bug is. One good
thing of DbC is that when the "density" of presence of contracts in
your programs gets higher of some threshold, most of the bugs present
in the code show themselves up as failed assertions/contracts. To me
it seems related to percolation theory :-) (http://en.wikipedia.org/
wiki/Percolation_threshold ).

In D you may also use enforce(), that's essentially a camouflaged
throw/raise statement, if you use it outside DbC contracts, they are
tests that run even in release builds when your contracts are
disabled.

Bye,
bearophile