Newsgroups: comp.lang.misc, comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!mit-eddie!xn.ll.mit.edu!xn!olson
From: olson@juliet.ll.mit.edu ( Steve Olson)
Subject: Re: A Hard Problem for Static Type Systems
In-Reply-To: cjeffery@optima.UUCP's message of 2 May 91 09:53:35 GMT
Message-ID: <OLSON.91May2145734@goneril.juliet.ll.mit.edu>
Followup-To: comp.lang.misc
Lines: 32
Sender: usenet@xn.ll.mit.edu
Organization: M.I.T. Lincoln Lab - Group 43
References: <566@eiffel.UUCP> <2672@optima.cs.arizona.edu>
Date: 2 May 91 14:57:34

In article <2672@optima.cs.arizona.edu> cjeffery@optima.UUCP (Clinton Jeffery) writes:
   From article <566@eiffel.UUCP>, by bertrand@eiffel.UUCP (Bertrand Meyer):
   > If we were able to build static checkers that were totally
   > unobtrusive performance-wise, and did their work in - say -
   > ten seconds after a comparatively small change even to a very large
   > system, then who in the world would forsake the extra benefits of type
   > checking?

Because static type checking mostly solves problems introduced by ... 
static typing.  Now, if I'm forced to use static typing, there is no
question that I would also want a good type checker.  And I have no
problem with the notion that as static type checkers go, Eiffel has
a very good one.

   I would.  I am not willing to type one keystroke (e.g. type declarations)
   more than I have to in order to satisfy your need for everyone to do so.
   What is this sweeping generalization doing here after your very nice
   concession to dynamically typed languages earlier in your post?

Um, well, in my opinion, the extra keystrokes involved are the weakest of
the arguments against static typing.  I mean, the botom line isn't keystrokes,
its total programmer effort.  And of course, in many applications, machine
effort must be considered also.  I don't mind typing the declarations so much
as I mind being forced to specify my data objects at the bits 'n' bytes level.
("32 or 64 bits, pal, thats all we got here, and you better not get 'em
mixed up either!")

--
-- Steve Olson
-- MIT Lincoln Laboratory
-- olson@juliet.ll.mit.edu
--
