[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: dynamic vs. static typing



Joe Marshall wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
>
> > Howard Stearns wrote:
> >> OK, how's this:
> >>
> >>    "1. Without early spellchecking, the proportion of typos
> >> which manifest during later stages rises significantly.
> > ...etc.
> >
> > There's no comparison, because it's quite rare that spelling
> > errors result in subtle semantic errors which require tracing
> > program behavior in a debugger (whatever spelling analogy you
> > want to use);
>
> Then how come so many scheme programs have a variable called LST?

That's just the unrehabilitated Common Lisp programmers, don't mind them.
:oP

Besides, spellchecking wouldn't help if you had a *valid* variable named
LST, and via typo or otherwise, got it confused with LIST.  A good
typechecker, on the other hand, would catch such an error.

Howard's spellchecking analogy just didn't strike me as valid, but I didn't
do a good job of identifying why.  You could make an argument for it similar
to the one I used regarding the desirability of layers of checking which
perform different types of checks.  I argued that since typechecking and
unit-checking catch different kinds of errors (even though there's a lot of
overlap), and catch them in different ways (analyzing vs. running the
program), one cannot replace the other.

However, in the case of spellchecking, most typechecking systems would catch
*all* identifier spelling errors, as a subset of type errors; and they would
be caught in a similar way, by analysis of the program source.  So "early
spellchecking" is subsumed by early typechecking.  Howard claimed otherwise:

   "2. Often, the nature of those typos isn't identified as clearly
during compiling, testing, or runtime as it would be by a spell-checker,
so they take longer to track down."

Assuming "compiling" includes type-checking, though, this seems false to me.

Anton