• Gary Whatmore <no spam.sp> Nov 06 2010
• bearophile <bearophileHUGS lycos.com> Nov 06 2010
• bearophile <bearophileHUGS lycos.com> Nov 06 2010

Gary Whatmore <no spam.sp> writes:

bearophile Wrote:

 Gary Whatmore:
 
 You're missing the point. The reason for seg faults is to terminate the
application as quickly as possible. The developer then fires up the debugger
and fixes the app. Seg faults should never happen in production code. You only
release when all seg faults are fixed. The builtin unit tests in D can
guarantee this with 100% test coverage.


 Unittests help remove and avoid some bugs, but experience shows they don't
solve/avoid all problems. Null exceptions do happen in production code. 100%
coverage of unittests can't avoid all possible bugs, because it's easy to miss
some code paths in unittests. Take a look at bugzilla to see many basic bugs in
Phobos despite the usage of unittests.


Doesn't it mean that instead of complicating the language we write more unit
tests? Surely the stream of new bugs ends at some point. Then we are production
ready. Just look how look it took to stabilize C++. 30+ years is acceptable for
D. C++ didn't have test driven development knowledge, we have.

bearophile <bearophileHUGS lycos.com> writes:

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

bearophile <bearophileHUGS lycos.com> writes:

 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. 


Sorry, unfinished post. I was saying:

Languages like Spec#, Haskell and others try to be in the middle, and be almost
usable for general purpose programs despite having a very flexible and powerful
static type system.

Bye,
bearophile