Re: another take on hackers and painters

[Matt Hellige <address@hidden>]

[mcguire@cs.utexas.edu]
> > Clerical programmers [...] will not know what to do with the freedom
> > given by things such as dynamic typing.
> 
> Ok, so I'm none too bright.  What exact freedoms do you get with dynamic
> typing?  It seems like a type problem is going to result in a broken
> program either way, so you still have to think about types and making
> sure the right collection of stuff gets put in the right place.  The
> only real advantages I can see are:
> 
> * A dynamic type system makes the language implementation easier.
> Writing a decent static type checker is harder than a decent dynamic
> type checker.
> 
> * Macros:  I know staticly typed macro-ish systems exist, but with the
> execption of camlp4, I don't know of any that are a standard part of a
> language or even a standard part of an implementation.  Again, dynamic
> typing makes it easier, better integrated, and thus more common.
> 

Here's another big one: reflection and dynamic evaluation. Suppose I want to 
read some expression from the user, evaluate it, store the result in a
variable, perhaps dynamically determine its type, and take some action.
This kind of thing is pretty difficult to accomodate with static
typing. Solutions I've seen (although I'm sure there are others) tend
to be of the type-case form, where even though some type verification
is done at run-time, it's done only when needed and the compiler can
still be sure that each branch of the type-case is safe. So something
like (pardon my pseudo-syntax):

  (let ((result (eval-string some-string)))
    (cond
     ((string? result)   (treat-as-string result))
     ((integer? result)  (treat-as-integer result))
     (else               (handle-failure))))

becomes something like:

  type-case (eval-string some-string) of
    x : String  ->  treat-as-string x
    x : Integer ->  treat-as-integer x
    _           ->  handle-failure

But there are other complicated issues with this approach, making the
compile-time types and run-time types play well together, representing
intermediate non-typecased results and so on. I'm intrigued by work in
this direction, but so far, I haven't seen anything that matches the
ease and flexibility of doing this in a dynamic language.

In fact, I've noticed that it seems like something of a philosophical
difference. When the topic occasionally comes up, for example, on the
Haskell list, especially in one of its apparently very-dynamic forms like:

  "I want to look up a function at run-time, by name, then call it."

the response is often stony silence or a simple "You shouldn't want to
do that. You obviously don't understand the difference between
compile-time and run-time." However, as I said, there is definitely
some work in this direction, so my generalization is probably myopic
and unfair.

Matt

-- 
Matt Hellige                  matt@immute.net
http://matt.immute.net