Who's minister of propaganda this week?

[Alex Martelli]

"Nicola Musatti" <objectway at divalsim.it> wrote in message
news:3AAFA13D.76E32C3F at divalsim.it...
> Hi,
> I'm a Python curious not yet sold to the advantages of typeless
> languages; I tend to think that typelessness is suited to a set of tasks
> that has only a limited overlap with the tasks for which static typing
> is preferable.

Indeed, for any given task, either static or dynamic typing
is 'preferable' -- not both (by definition of 'preferable');
so, the overlap between the set of tasks for which each is
best suited is nil...!-)  [Rather tautologically].


> > >Robert C. Martin meant two things. A> If you write wall-to-wall unit
tests
> > >when you code, if you use a typeless language you will add bullet-proof
> > >features faster than if you use a statically typed language, even
though
> > >the former has less built-in error checking at type conversion time.
The
> > >latter supports refactoring easier.
>
> But those things that the compiler used to check for you may well have
> become new tests for you to write:

Except this "may well" does not in fact happen -- or, at least, this
seems to be the common experience of several people known as being
pretty good at statically typed languages (Martin, Eckel, me, just to
name a few:-).  You do need to check via testing anyway that all
meaningful objects are "behaving as needed" -- and this turns out
to cover ``having the right type'' as a by-product.

Not surprising.  Say you're passing a reference to an abstract itf
which has method 'foo' taking one int parameter.  The compiler can
assure that, yes, all objects passed do satisfy that interface.  But
*what ensures the calls to theobj.foo(23) actually DO what they're
MEANT to do...*?!  Answer: the unit-tests.  But then, the unit tests
would ensure failure (at runtime, during the test) if theobj had no
foo method at all, or a method not callable with an int argument.

So, all the compile-time checking is buying is catching (a small
subset of) the errors that would be caught in testing anyway, a
little bit earlier (thus, a little bit cheaper) -- it's never the
case that one has to write a test which would not be needed at
all if type-checking was static, since "the object has the right
type" is a small subcase of "the object _behaves_ per the specs".


> >   Expressiveness ... is a far better aid to
> >   correctness ...
>
> Here I'm puzzled, but maybe it's only a "language" problem. What do you
> mean by "Expressiveness"? I ask because until now I thought
> expressiveness was an advantage of strongly typed languages (namely,
> C++) over typeless ones.

I'll pass on this one, as I don't know what the original quote
meant when seeing it out of context like this.  I consider the
expressiveness of C++ on a par with Python's -- actually, what
you can do in a C++ template is quite close to what you can do
in a Python function == the Python advantage is that you're not
limited to doing it at compile-time only, the C++ advantage one
of speed (doing more at compile time means faster-running code,
all other things being equal -- of course, sometimes they aren't).


Alex