Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Dynamic typing (part 31,497)
Message-ID: <2397@optima.cs.arizona.edu>
Date: 24 Apr 91 18:13:26 GMT
Sender: news@cs.arizona.edu
Lines: 31

In article  <1991Apr24.051522.28988@tkou02.enet.dec.com> Norman Diamond writes:
]
]Why not both?  A lot of people might agree that dynamic typing is
]necessary in some cases too.  Maybe someday the two sides might agree
]that the programmer should be allowed to specify types and/or classes
]when it helps catch errors and/or improve efficiency, etc.; and that
]the programmer should be allowed to omit specifications when it helps
]speed development time or extend reusability.

That was the suggestion that spawned all of these threads.  Some
people seemed to feel that any dynamic typing is too "dangerous" and
discussions of that led to all the rest.

]>When the implementator
]>does it, it leads to less code, less complexity, and fewer bugs.
[       ^ (meaing dynamic typing)]

]No.  When the programmer is allowed to do the portions that need it,
]it can also lead to less complexity and fewer bugs.

That doesn't make any sense.  How can it lead to less complexity and
fewer bugs when the implementer has to explicitely handle details
instead of letting them be handled by the language?  Does it lead to
less complexity and fewer bugs when implementers handle array bounds
checking without language help?  What about checking for dereferencing
a null pointer?  Whenever you leave such things up to the implementer
you are providing opportunities for careless bugs.
--
					David Gudeman
gudeman@cs.arizona.edu
noao!arizona!gudeman