[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
>
>...
>
> I don't for a moment dispute the usefulness of types, just /static/
> typing. Static typing as aid to programmer effectiveness is something of
> a myth, tho' it's very handy if you're a compiler or a runtime. Systems
> do get build with dynamically typed languages and seem to work fine;
> notably these languages are notoriously productive.
When I am creating new code, dynamic type checking almost always allows
me to be more productive than static type checking. As Jonathan says,
when you are changing or refactoring code, static type checking can more
often catch your mistakes. Since maintenance lasts longer than initial
development this would seem like a clear win for static type-checking
except that it can often bloat and complicate the code and thus provide
more opportunities for bugs to creep in. Here's what Robert C. Martin
has to say:
"""
As an industry we became enamored of type-safety in the early '80s. Many
of us had been badly burned by C or other type-unsafe languages. When
type-safe languages like C++, Pascal, and Ada came to the fore, we found
that whole classes of errors were eliminated by the compiler. This
safety came at a price. Every variable had to be declared before it was
used. Every usage had to be consistent with its declaration. In essence,
a kind of "dual-entry bookkeeping" was established for languages. If you
wanted to use a variable (first entry) you had to declare it (second
entry). This double checking gave the compiler vast power to detect
inconsistency and error on the part of the programmer, but at the cost
of the double entries, and of making sure that the compiler had access
to the declarations.
With the advent of agile processes like extreme programming (XP), we
have come to find that unit testing is far more important than we had at
first expected. In XP, we write unit tests for absolutely everything.
Indeed, we write them before we write the production code that passes
them. This, too, is a kind of dual-entry bookkeeping. But instead of the
two entries being a declaration and a usage, the two entries are a test
and the code that makes it pass.
Again, this double-checking eliminates lots of errors, including the
errors that a type-safe compiler finds. Thus, if we write unit tests in
the XP way, we don't need type safety. If we don't need type safety,
then its costs become very severe. It is much easier to change a program
written in a dynamically typed language than it is to change a program
written in a type-safe language. That cost of change becomes a great
liability if type safety isn't needed.
"""
* http://www.itworld.com/AppDev/1262/itw-0314-rcmappdevint/
I think it is pretty well understood that for programming in the small,
dynamic type checking wins. I think it will be another five or ten years
before we have a clear answer about programming in the large. We need
more programmers to move back and forth between the two types of
developments, working on very large programs, and report their findings.
Current anecdotal evidence goes both ways: some people claim that
dynamic type checking helps in the large and others claim it hurts.
Paul Prescod
|
