Re: dynamic vs. static typing

[Howard Stearns <address@hidden>]

OK, how's this:

   "1. Without early spellchecking, the proportion of typos which 
manifest during later stages rises significantly.

   "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.

   "I'm not arguing that spellchecking is best in all cases. But it has 
benefits which many people, including myself, have experienced.
We also know it's possible to provide more of those benefits in more 
languages simply by allowing hyphens or some other easily typed 
separator in identifiers so that it is not necessary to use KrazyCap or 
other conventions that defeat the effectiveness or spellcheckers.  What 
I've mostly been arguing against is the rejection of spellchecking 
without empirical measurement of the benefits gained."

Actually, I don't really mean to pick on either side here. (I'm inclined 
to agree with Anton's desire to have his cake and eat it, too.)  But I 
do want to ridule a common tendency (as I perceive it) of people in our 
field. We pick a dogma we like based on personal style, and then we try 
to amass reasons for it without carefully articulating the value and 
context in a way that is measurable in a repeatable way. Heck, I'm doing 
it right now, because in my heart I just don't like static type checking 
and I dolike spell checking and hyphenated identifiers! I don't agree 
when Anton writes 1 and 2 about type checking, and I do believe the same 
unscientific argument about spell checking.

Anton van Straaten wrote:

> Paul F. Dietz wrote:
> 
>>Anton van Straaten wrote:
>>
>>>>>Without early typechecking, the proportion of type errors which
>>>>>manifest during testing and at runtime rises significantly -
>>>>>and often, their nature isn't as clearly identified, so they
>>>>>take longer to track down.  Looking at this in terms of what
>>>>>percentage they are of all possible errors is misleading at best.
>>>>
>>>>But is there any evidence to support the contention that the putative
>>>>savings in debugging time exceeds the extra design and coding cost?
>>>
>>>Is there any evidence to support the above implied contention that
>>>an *extra* design and coding cost exists?  The costs (in terms of
>>>time) with DT systems may simply be shifted to later in the
>>>development cycle.
>>
>>I would like to know if your statement about savings was actually
>>evidence-based, or merely a statement of dogma or prejudice.
> 
> 
> The statement of mine quoted originally, reinserted above, makes the
> following claims:
> 
> 1. Without early typechecking, the proportion of type errors which manifest
> during testing and at runtime rises significantly.
> 
> 2. Often, the nature of those type errors isn't identified as clearly during
> testing or at runtime as it would be by a type-checker, so they take longer
> to track down.
> 
> 3. Looking at these errors in terms of what percentage they are of all
> possible errors is misleading at best.
> 
> (1) is a trivial truth.  (3) is a criticism of an earlier claim, the
> rationale for which can be found in books like "How to Lie with Statistics".
> (2) is based on evidence I've encountered during development in both DT and
> ST languages, over many years, including experience with other developers
> that I've worked with, in both development and mentoring capacities.  I
> don't consider it a statement of dogma or prejudice.
> 
> Repeating myself, I'm not arguing that ST is the best choice in all cases.
> But it has benefits which many people, including myself, have experienced.
> We also know it's possible to provide more of those benefits in DT
> languages.  What I've mostly been arguing against is the rejection of static
> typechecking without exploring or understanding what that can mean, beyond
> what e.g. C++/Java or even ML/Haskell provide, and especially when that
> rejection seems to be based on misconceptions about what static typechecking
> is capable of.
> 
> Anton
> 
>