• Kagamin <spam here.lot> May 11 2011
• bearophile <bearophileHUGS lycos.com> May 11 2011
• Kagamin <spam here.lot> May 11 2011
• bearophile <bearophileHUGS lycos.com> May 11 2011
• Kagamin <spam here.lot> May 12 2011
• Caligo <iteronvexor gmail.com> May 16 2011

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?

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

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.

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

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.

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