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?

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

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.

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

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.

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