www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Re: Patterns of Human Error - my presentation at the DC ACM

reply Kagamin <spam here.lot> writes:
bearophile Wrote:

 A better solution:
 http://blog.moertel.com/articles/2006/10/18/a-type-based-solution-to-the-strings-problem
 

What do you think about unittesting efficiency section?
May 11 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Kagamin:

 What do you think about unittesting efficiency section?

I always use unit testing, in Python I especially like doctests. But often unit tests aren't enough, so I use Contracts too. Type system-based solutions too help, a quotation I've read elsewhere (written by a Haskell programmer):
Rather, what you need is a way to make deep structural changes to your code,
and still end up with a fair amount of confidence that the result is at least
reasonable, that you havenít forgotten something big. Unit testing wonít do the
job; there are just too many false failures, since making such a large change
tends to invalidate huge swaths of your unit tests anyway.  You already know
that they wonít work, because you deleted or changed the arguments to the
pieces that you were testing.  Indeed, while test-driven development works
great for the vast majority of programming tasks that fall squarely in the "not
difficult" category, it has a tendency to crystallize the code a bit quickly
here.  You don't want to be told about and need to fix every place something
changed; you want to know specifically when you've made changes that are not
consistent between themselves. That, of course, is the job of a type system.<

On the other unit tests are about single functions, and often small leaf-functions don't need to change if you change other parts of your program, so their tests don't need to change. Generally you use all tools you have to increase the probability your code is correct. Bye, bearophile
May 11 2011
next sibling parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:

 Kagamin:
 
 What do you think about unittesting efficiency section?

I always use unit testing, in Python I especially like doctests. But often unit tests aren't enough, so I use Contracts too.

I rather meant the assertion that in languages with duck type system unittesting eliminates to some degree the need for strong type system.
May 11 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Kagamin:

 I rather meant the assertion that in languages with duck type system
unittesting eliminates to some degree the need for strong type system.

I like both dynamically typed languages and statically typed ones, both have advantages and disadvantages. The "dynamic" C# keyword and other things in other new languages tells me that we're going to languages that try to combine the advantages of both. I sometimes prefer dynamic typing to build prototypes, but sometimes a _flexible_ static typing (like Haskell one) is useful for prototypes too. Unit testing is able to replace some of the tests done by a static type system. On the other hand a type system is able to test _all_ code paths, while the unittests cover only the paths exercised in the tests. So in the end I use about an equal number of unit tests in D and Python. And beside normal unit testing there are other forms of testing, like QuickCheck (http://en.wikipedia.org/wiki/QuickCheck ). Very large Python programs (like Zope) implement some kind of interfaces (and recent versions of Python have added ABC, Abstract Base Classes), some some help from a bit more structured type system is useful even in dynamically typed languages when the programs become large. Bye, bearophile
May 11 2011
parent Kagamin <spam here.lot> writes:
bearophile Wrote:

 The "dynamic" C# keyword and other things in other new languages tells me that
we're going to languages that try to combine the advantages of both.

As I understand, this feature is only to simplify interoperability with dynamic type systems like ActiveX, DOM and IronPython. This doesn't mean, it's a feature good by itself.
May 12 2011
prev sibling parent Caligo <iteronvexor gmail.com> writes:
Have you ever placed a 9-volt battery on your tongue?  It's not very
pleasant, specially when someone asks you to do it and you don't know
what's coming.

On a serious note, the topic reminds me of an interesting book that I
read; The Design of Everyday Things by Donald Norman, "is one of the
classics of human interface design. Norman shows how badly something
as simple as a kitchen stove can be designed, and everyone should read
it who will design a dialog box, write an error message, or design
just about anything else humans are supposed to use." --Qt Docs
May 16 2011