Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object
Subject: Re: Do we really need types in OOPL's?
Message-ID: <1990Oct10.053840.8421@odi.com>
Date: 10 Oct 90 05:38:40 GMT
References: <0yw10qr@Unify.Com> <60700003@inmet> <1426@media01.UUCP> <1990Oct9.190813.23402@ux1.cso.uiuc.edu>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 47
In-Reply-To: render@cs.uiuc.edu's message of 9 Oct 90 19:08:13 GMT

In article <1990Oct9.190813.23402@ux1.cso.uiuc.edu> render@cs.uiuc.edu (Hal Render) writes:

								The problem 
   with languages that do not support static typing is that *all* error-checking 
   must be done at run-time.  This is the reason (I think) that languages
   such as Smalltalk have superior symbolic debuggers--they're absolutely
   necessary to make the language usable.  Good symbolic debuggers are also
   necessary for statically-typed languages, because of the kinds of problems
   that compilers cannot check.  

I agree with the last sentence above.  In my opinion, good symbolic
debuggers are needed just much whether the language is statically or
dynamically typed.  I use C++ these days, but even with static type
checking, I spend a lot of time tracking down bugs; it's really not
that different from when I was using Lisp, except that the compiler
catches more of the easy bugs for me.  Unfortunately, there are plenty
of hard ones that don't manifest themselves as type inconsistencies.

I think the reason that implementations of dynamically typed languages
tend to be accompanied by superior debuggers is that it's easier to
produce a good debugger for that style of implementation.  Again, it's
the style of implementation that counts, not the language definition.
The debuggers that you get with Sabre C and Symbolics C are great.
The debuggers that you get with optimized compiled Lisp on a Sun are
not so great.  It all has to do with the way the language system is
implemented, in particular how much information is easily available at
runtime.

One particularly neat thing about debugging in an interactive
environment such as Symbolics provides is that you can provide each
object with a "here's how to print me" and "here's how to describe my
contents" methods, which are a nice convenience.  While I can sort of
imagine how to hack this into the AT&T cfront implementation of C++
and the gdb debugger, let's say, it would be kind of kludgey and
error-prone for various reasons.  In practice, although it's not
impossible, it isn't done.

   Thus, you are trading load-image size and speed for debugging support.
   This is why dynamically-typed languages are better for prototypes
   while statically-typed langauges are better for production code.

<< Insert my usual comment about how you're really talking about the
distinction between language system implementations, rather than
language definitions. >> Try prototyping your C programs using Sabre
C, and then running them using a hairy optimizing C compiler of the
usual sort, and you'll see that it has nothing to do with the
language.