Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.lang.misc
Subject: Re: CHALLENGE: heterogeneous collections
Message-ID: <49189@nigel.ee.udel.edu>
Date: 28 Mar 91 20:30:49 GMT
References: <7689:Mar2623:28:5091@kramden.acf.nyu.edu> <49087@nigel.ee.udel.edu> <25655:Mar2803:50:2491@kramden.acf.nyu.edu>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 56
Nntp-Posting-Host: snow-white.ee.udel.edu

In article <25655:Mar2803:50:2491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Dynamic typing isn't a semantic feature. It's a state of mind. 

Exactly.  Modularization is also a state of mind.  So are local
variables.  So is recursion.  So is separate compilation. So are
libraries, for that matter.  None of these can't be done in raw machine
code (with suitable preprocessors ;-).  However, when the language I
use supports my "state of mind" then I find I can be much more
productive.  When I implement dynamic typing myself, I have to worry
about type mismatches that aren't caught by the compiler. If I let the
compiler/interpreter handle dynamic typing, it catches the errors for
me.  Just like when I implement modularization or local variables
myself, I sometimes make mistakes which the compiler can't catch
because I can't tell it that a particular variable is local.
I would much rather adjust once the computer to match my state of mind
than to adjust my state of mind to match the computer every time
they disagree.

>If you
>want to use the pair (type,value) as a value with certain constraints,
>you can, whether the language supports it or not. It takes at most a
>good preprocessor to make this just as convenient as in any
>``dynamically typed'' language.

You mean a good preprocessor like Lisp, or Objective-C?  Wow, heavy.  I
didn't realize I can do the Objective-C transformations by hand and get
the same results :-O. Of course, without a good preprocessor (which
most of the rest of us have been calling "a dynamicly-typed language
compiler") it is damn inconvenient.

>*You* are misinterpreting my comments as something like ``Dynamic typing
>is useless. Anyone who wants to use dynamic typing is a fool.'' I'm just
>saying that it's pointless to have the compiler support dynamic typing,
>as it's just as easy to do in a library.

I'm not interpreting your comments that way.  I'm interpreting your
stance as saying that dynamic typing implemented by the user on top of
static typing is just as useful and convenient as dynamic typing in a
language.  I disagree that dynamic typing innards being visible to the
user is a "good thing" any more than local variable management during
recursion being managed by the user is a "good thing."  I don't care
what semantics the language supports.  As you and I have both pointed
out, all programs can be reduced to huge finite state machines.  The
question is not the semantics of the language, but rather how well the
syntax I use to describe this huge fsm matches how I think about the
problem.

>
>---Dan
                        -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
  +=+=+ My time is very valuable, but unfortunately only to me +=+=+
+ When you drive screws with a hammer, screwdrivers are unrecognisable +