Re: Static vs. Dynamic typing
Re: Static vs. Dynamic typing
- Subject: Re: Static vs. Dynamic typing
- From: Tim Ramsey <email@hidden>
- Date: Wed, 2 Jul 2003 10:52:29 -0500
On 7/2/03 3:48 PM, "Eugene Lee" <email@hidden> wrote:
On Tue, Jul 01, 2003 at 11:57:32PM +0200, Marco Scheurer wrote:
:
: An uncaught exception in Objective-C kills the program too. Catching
: exceptions as to not to crash the program has nothing to do with the
: language, but how it is used (you could do the same thing in C++). And
: crashing or not a deployed application is an engineering tradeoff.
: There could be good reasons not to crash after all. The current
: operation has probably failed, but the app might still be usable in
: it's next passage in the run loop. I agree that a quietly writing
: something in the error log is not very user-friendly, but then crashing
: is even less user friendly, if more informative that something went
: wrong.
I guess the question comes down to a question of whether it's better for
a program to crash or to continue running with an increased possibility
of outputting less correct results.
Personally I feel that programs should fail fast, rather than continue on in
an improper state.
The reason is simple, if it fails quickly, then it's easy to catch these
errors in testing and it makes it easier to locate the error. If it
continues in an improper state, the error might not get caught during
testing, or it might be very difficult to track down since it may not cause
any problems until long after the actual error occurred.
The point is to eliminate bugs before they ever get to the user. And, I
feel, it is especially important to eliminate elusive or intermittent bugs,
since these will be the hardest ones to track down later.
I could not agree more. I have found bugs in programs that have been
running, bug-free as far as anyone knew, for as long as seven years.
They were caused by unlikely but valid parameter combinations and/or
computational paths. Debugging was typically very time consuming once
their existence was known.
I have a similar feeling about the static/dynamic issue. Static typing
creates compiler errors where dynamic typing would create runtime errors.
Compiler errors are always easier to catch than runtime errors. So, as much
as possible, I'd like to let the compiler do my testing for me.
Again, I agree. In addition, moving operations out of runtime to
compile time tends to make programs more efficient. Dynamic
configurations are extremely flexible and powerful, but nothing comes
for free. The cost is increased overhead and longer runtimes.
I actually had read Bruce Eckel's essay before
<http://mindview.net/WebLog/log-0025>. While I agree with most of what he
says, I'm still not convinced that dynamic is better than static.
His argument seems to be largely based on economics. That dynamic languages
allow faster development, and when paired with strong testing it produces
high quality products in less time.
He never proves that static typing is wrong or bad, just that it may not be
financially viable.
This financial viability may only be for the short term. What is the
cost to you when a user abandons your product for another because of
bugs?
For example, he says, "If it's not tested, it's broken." I agree with this
100%. Strong testing should be a part of any software development--static or
dynamic.
However, he goes on to say "The only guarantee of correctness, regardless of
whether your language is strongly or weakly typed, is whether it passes all
the tests that define the correctness of your program."
I have a problem with this. Testing can never guarantee a program's
correctness--at least not any programs of any real complexity. There is no
way to exhaustively test a program.
Too true - combinatorial explosion always does you in. I have built
simulations that could not be tested completely within anyone's
lifetime even if they were to be run 24/7 - too many possible
combinations of paths and parameters.
No matter how strong your testing regimen is, bugs can and will slip through
the cracks. Given that it is much more time consuming and costly to fix bugs
during the maintenance phase of a project than during development, my
instincts tell me I should do whatever I can to eliminate potentially
elusive bugs. If this means taking a time hit to use a strongly typed
language AND strong testing, so be it.
I also don't always see a big time savings in dynamic languages. In some
areas, yes. For example, processing lists of objects always seems easier in
a dynamic language. But many tasks are equally tedious in both, and some
tasks may take longer in a dynamic language (for example, assessors in
Objective C).
However, given a language as big and complex as C++ I am willing to concede
that many people using it do not know enough to fully leverage the
language's strengths. And there are a lot of subtitle gotchas waiting to
strike. The complexity of the language may cause more bugs than the strong
typing prevents. Though this is actually a separate issue, and doesn't mean
that strong typing itself is bad.
One of the biggest time/cost savings of Cocoa and Objective C is the
way they facilitate rapid prototyping. It is not a pretty sight when
a software designer, using traditional top-down methods, makes a poor
choice of architecture early, paints himself into a corner, and does
not find out until it is far too late to change the design. I believe
dynamic typing provides its benefit via helping to enable rapid
prototyping and by providing flexibility where it matters. This also
tends to improve the situation by making software more testable and
by incorporating testing into more of the development cycle. Using
this ability to routinely avoid static typing is just plain laziness.
It would be interesting to see serious research done on the relative
development costs of the entire lifecycle of projects done using static and
dynamic typing. It may be that dynamic typed projects are still
cheaper--even over the long haul. But I am not 100% convinced.
I don't believe either side of this argument could ever be proved.
The best design is whatever is the appropriate technology for the
project. A lot of factors, of which dynamic typing is only one, play
together to determine lifecycle cost.
On the other hand, programming Cocoa and Objective C is somewhat addictive.
I really am enjoying using the language, and the more I use it, the quieter
these nagging doubts become.
-Rich-
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
--
Tim
The reasonable man adapts himself to the world; the unreasonable one
persists to adapt the world to himself. Therefore all progress depends on
the unreasonable man. -George Bernard Shaw, writer, Nobel laureate
(1856-1950)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.