Spec#, nullables and more

[bearophile]

Gary Whatmore:

> Doesn't it mean that instead of complicating the language we write more unit tests?

This is true, it's a design decision. And we are indeed trying to decide if this feature is worth it.

A sufficiently large amount of unittests is indeed able to remove and avoid a large enough percentage of bugs. And you are are right in saying that a too much complex language (with too many features) is not a good thing. So I can't answer you, but you too can't answer yourself.

So it's also a matter of what the most handy solution is. If nonnull types are able to avoid the need of a sufficiently large amount of unittesting, then the feature is good to have, because it saves you time. If the amount of unittests it allows you to avoid is too much small, then it's not worth to have it.

Nonull reference types are an extension of the static type system. Unittests are known to be a partial replacement for (static) type systems. Dynamic languages as Python use unitesting to perform some of the tests done at compile time by the D static type system.

Python programmers argue that static strong type systems are not better than strong dynamic typing because the kind of bugs caught by the simple static type systems as the Java one are easily and quickly avoided with simple & quick to write unittests. And then you need to add other unittests anyway, that test the logic of the code, that simple static type systems aren't able to test and enforce.

New and much more flexible static type systems are possible, like the SPARK and ATS ones, but they require a kind of programming that asks lot of brain from the programmer, so they are mostly for special purposes only. Languages like Spec#, Haskell and others

Bye,
bearophile