🚀 go-pugleaf

>>From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
>Subject: Re: Dynamic typing -- To Have and Have Not (was Runti
>Date: 14 Mar 91 22:18:56 GMT
>
>For me compile time and typechecking are both important while I'm writing a
>program. [...] Do you optimize programs while you're testing? Probably not.
>But when each test run takes a noticeable amount of time, don't you wish
>that you could make them run faster without wasting so much time on
>optimization?
>
>Similarly, in a dynamically typed language, would you turn on strict
>typechecking and other optimizations while you're testing? Probably not.

I debug and test with typechecking on in Common Lisp, and so does everyone
else I know.  When properly supported (as in CMU Common Lisp), a powerful
dynamic type system is a fairly general assertion mechanism, addressing
consistency constraints outside the scope of conventional static typing
systems.  For example, you can:
    (declare (type (integer 3 27) i))

to say that I ranges from 3 to 47.  And this assertion will be checked.
The Common Lisp type system is general enough to express many interesting
consistency constraints, but simple enough so that compilers can use it to
do quite a bit of type inference.

>But when you make type errors, don't you wish that you could have found
>them without wasting so much time on optimization? 

Compilation speed is much less of a concern in environments that support
incremental compilation.  Although Lisp compilers tend to be rather slow
compared to conventional compilers, Lisp seems faster because changes
require much less recompilation.

>Well, you could. All
>you had to do was use static typing.

Do your programs ever dump core?  That's a run-time error check, just not a
very graceful one.  Most run-time type errors in Lisp systems are of the
"dereferenceing off into space" sort, which can't be detected at compile
time.

  Robert A. MacLachlan (ram@cs.cmu.edu)