Brian Hurt scripsit:

> No, the big advantage of static typing is development time. First of all,
> static typing drastically reduces the number of unit tests you need-
> responsibility for the correctness of many of the constraints that unit
> tests are checking can instead be ensured automatically by the type
> system.

That's a big advantage for supporting static typing, but not a big
advantage for requiring it. Nor is it an advantage particular to static
typing as opposed to any other sort of compile-time declaration system.

> As an example of what I mean by this, note in the example code
> I tossed off I casually introduced the FieldName.t type, which
> (obviously) represents a field name. The underlying representation
> of this type is probably just a string- but by controlling when and
> how field names can be created, I can enforce generic constraints.
> For example, already it's an error if you accidentally reverse the
> field name and field values.

This is a consideration orthogonal to static vs. dynamic typing: what
I will call generic vs. specific types. It's perfectly reasonable in a
dynamically typed language to put the field name into a specific type,
which provides the same type safety at run time that the statically
typed version does at compile time. Furthermore, there is nothing about
a statically typed language that prevents an API designer from using a
generic type such as String to represent a field name.

It may be true that dynamically- typed-language programmers are more
likely to use generic types, as a result of the easy availability
of type-heterogeneous containers such as lists and dictionaries.
What's more, few languages (CL is the exception here) provide syntax
for literals of specifically typed objects.

> But you can go further than that. I might not let arbitrary strings be
> converted into field names, I might only allow the database interface to
> create field names- and have some function where given a table, you can
> produce the list of FieldName.t' s that represent that table's fields.
> This way I gaurentee that a field name is a valid field name of at least
> some table. With phantom types and some trickery I can even gaurentee, in
> the type system, that the field names are valid for the table being
> selected against.

This of course is very straightforward in a dynamically typed language
by writing your own checking routines, if indeed you need them. You have
a Turing-complete engine, so use it.

> Over the course of say, a thousand bugs, that' s 83 working hours,
> or over two weeks of time lost.

If you have a thousand bugs of the kind a type system can catch, by all
means use it.

> You could make a dynamically typed system with variant types and pattern
> matching, but I've yet to see it.

The Scheme "match" macro does exactly that, and so does Q/Pure, which are
based on generalized term rewriting.

--
Dream projects long deferred John Cowan <cowan@...>
usually bite the wax tadpole. http://www.ccil. org/~cowan
--James Lileks