Re: Static vs. Dynamic typing
From: Richard Riehle (adaworks_at_earthlink.net)
Date: 09/07/04
- Next message: Phlip: "Is abstract test pattern also stairway to heaven pattern?"
- Previous message: Phlip: "Re: why a factory class?"
- In reply to: Ronald E Jeffries: "Re: Static vs. Dynamic typing"
- Next in thread: Cristiano Sadun: "Re: Static vs. Dynamic typing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 07 Sep 2004 02:42:55 GMT
"Ronald E Jeffries" <ronjeffries@acm.org> wrote in message
news:2jolj05fr4o6t177su59dou0igos0iq95m@4ax.com...
> On Sun, 05 Sep 2004 00:55:52 GMT, "Richard Riehle"
> <adaworks@earthlink.net> wrote:
>
> >I find it peculiar that so many of my colleagues rely so heavily
> >on testing. Tests are certainly an important part of the development
> >process, but they are almost never sufficient, by themselves, for
> >ensuring a program is defect free. At most, I can test to determine
> >that those errors I can anticipate will not occur.
>
> From what you write here, Richard, it appears that you haven't as yet
> gotten into "Test-Driven Development". Is that the case?
> >
I suppose I have been doing test-driven development for longer
than such a term has existed. A key difference is that I continue
to use the compiler as part of my testing process.
I am in favor of creating as much automated testing and using
it as often as possible throughout the the development (or
maintenance) of a software process. However, I do not see
testing as sufficient, just as I do not see type safety as sufficient.
In Ada, I design using types, constrained types, types that can
be checked by the compiler for consistency, and can be used
by the compiler to determine other potential errors in my design.
However, if type checking were the only benefit, it would be
a small benefit indeed.
When the type model is integrated into the larger language design,
it becomes useful. At that point, I can combine the many ideas
about my software into a coherent design, one where I can test
those things that can be tested and reason about those things that
cannot be tested.
A software product is so often characterized by the unexpected.
Unfortunately, the unexpected rarely manifests itself in the testing
process, regardless of how good that testing might be. This means
we must, as serious developers, take advantage of all the intellectual
and development tools available and use them appropriately.
Testing can deal with the expected. The unexpected requires design.
We are still a long way from having the complete set of design tools
we need. Costin Cozianu makes an excellent point
in his comment about the lack of attention to formal methods. In
the SPARK approach, formal methods are de rigueur, and this
works quite well for safety-critical software. However, formal
methods also fall short of what we will require for more effective
software design in the future.
As I look at the state of software practice, in our time, I believe
that those who develop software 100 years from now will look
back on what we do with the same admiration we accord the
mathematicians in the time of Charlemagne. Hint. This was
the time called "The Dark Ages."
Test-driven design has its place, but it must not be a substitute
for careful engineering, good architectures, and well-reasoned
design. There are simply too many features of a serious software
system than cannot be tested.
Richard Riehle
- Next message: Phlip: "Is abstract test pattern also stairway to heaven pattern?"
- Previous message: Phlip: "Re: why a factory class?"
- In reply to: Ronald E Jeffries: "Re: Static vs. Dynamic typing"
- Next in thread: Cristiano Sadun: "Re: Static vs. Dynamic typing"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
