Path: utzoo!attcan!uunet!sci34hub!sci!dc
From: dc@sci.UUCP (D. C. Sessions)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 3)
Summary: OK, cases!
Message-ID: <962@mgt3.sci.UUCP>
Date: 20 Mar 91 19:17:44 GMT
References: <626@optima.cs.arizona.edu>
            <1991Mar13.163629.12630@engage.enet.dec.com>
Reply-To: dc@mgt3.sci.com (D. C. Sessions)
Organization: SCI Technology, Inc., Huntsville, Al.
Lines: 85

In article <626@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
# In article  <1991Mar13.163629.12630@engage.enet.dec.com> grier@marx.enet.dec.com writes:

  [Deleted for brevity -- DCS]

# ]... I just wouldn't do my banking or trust my life to software which
# ]relies on extensive testing rather than some level of ensurred correctness.
# 
# You must be joking.  Static type checking doesn't give any reasonable
# level of assurance at all -- it is never the case that simply because
# program compiles without errors, there is reason to believe that it
# has some level of reliability.  Testing is the _only_ known way to
# give any assurance at all.  And a given amount of testing generally
# provides more assurance for a language with dynamic typing than it
# would for a language with static typing.  (Because programs in
# dynamically typed languages are usually much smaller and have fewer
# paths to test.)

  [More deletions -- DCS]

# 					David Gudeman

Let's try this theory on a real-life test case:

  Once upon a time, there was an engineering team which got stuck 
  maintaining a (big) mess of spaghetti.  This spaghetti contained
  records -- *lots* of records -- which got passed around all over the
  place.

  Most of the record types (Type_A through Type_M) were of the form:

        <header>
        <foo>
        <stuff>

  But record type Type_N was of the form:

        <header>
        <bar>
        <more stuff>

  (And by the way, <foo> and <bar> were both integers.)

  Now, since this was in the bad old days before function prototypes, 
  all of the functions which expected a Type_A would quite cheerfully 
  accept a Type_N instead.  This happy circumstance was widely exploited 
  to allow common handling of the header record, which contained
  information controlling the routing of the record between concurrent 
  threads.

  One day, a problem showed up.  On examination, it turned out that some 
  values of <foo> dictated an alternate routing, so one of the 
  message-routing functions was modified to handle the situation.  What 
  everyone missed was the fact that the routing function sometimes 
  handled Type_N messages.

  Of course, the results of interpreting <bar> as if it were <foo> could
  be amusing in the extreme.  Especially so since the consequences
  usually didn't show up until the record had been passed along to
  another concurrent thread.  Testing didn't discover the gotcha since 
  the anomalous value never turned up in <bar>.

  At least, it didn't turn up until a certain major corporation with a 
  three-letter name revised its communications protocol.  Oops.  *Big* 
  oops.  Banks.  Airlines.  Can you say "panic debug"?  It didn't take 
  long to find the Record from Mars; tracing back to where it came from 
  was a bit slower.  Lots slower.  Especially since working backwards 
  just showed the mutant being handled correctly, right back to the 
  point where Type_D records shouldn't come from.

The upshot of this little affair was the conversion of an entire shop 
full of C hackers into Modula-2 fanatics, purely because they *never* 
wanted to give up intermodule type-safety again.

So: for the purposes of the current discussion, how do our ideal 
dynamically-typed languages ensure that a similar little 
misunderstanding doesn't happen again?  Of course, sufficient human 
discipline would avoid the problem (by doing a manual static 
type-check?) but this is one of those little things that some 
programmers have come to expect computers to do for them.
-- 
| The above opinions may not be original, but they are mine and mine alone. |
|            "While it may not be for you to complete the task,             |
|                 neither are you free to refrain from it."                 |
+-=-=-    (I wish this _was_ original!)        D. C. Sessions          -=-=-+