Re: Strong Typing, Dynamic Languages, What to do?

[kragen@pobox.com (Kragen Sitaker)]

Brent Fulgham writes:
> I find myself in an uncomfortable state of language equivocation.  I
> seem to be forever vascillating between the strongly-typed and
> "dynamic/untyped" programming languages.

Scheme and OCaml are strongly typed; Forth, BCPL, and almost all
assembly languages are untyped.  C is almost untyped.  From the rest
of your post, I'm assuming you're talking about the dynamic/static
dichotomy, not the strong/weak dichotomy, and I won't discuss the
strong/weak dichotomy further.

Python is strongly typed; Perl and Tcl are similar, but offer so many
peremptory coercions that the strong typing doesn't help much to catch
bugs, although it may shorten development time.

> The proponents of so-called "[statically]-typed" languages in the
> Hindley-Milner school make the seemingly compelling argument that
> such type-checks provide superior program quality and reliability by
> catching syntax and logic errors before execution time.

There are two other arguments for static typing: it helps document
interfaces (you don't have to do manual type inference or read
documentation to tell whether the first argument to hash-table-ref is
a hash table (as it should be) or a hashable object), and it helps
compilers produce efficient code.

Superior program quality with the same effort, of course, means less
effort to achieve the same program quality.

Type declarations (either of the simple kind C uses, or the more
involved Hindley-Milner kind) can be added to dynamically-typed
languages.  Common Lisp does this for efficiency.  I haven't used this
feature enough to know if it helps with reliability and documentation
of interfaces.  Intuitively, it seems that it should.

> On the other hand, such [static] typing would seem to prevent the
> construction of polymorphic routines that allow a wide variety of
> types to be accepted as arguments.  It also seems to prevent you
> from arbitrarily expanding the types of data that a particular
> program might be exposed to without rebuilding the entire world.
> You do not always have the luxury of revising an object (or type)
> hierarchy, especially if you don't have the source code for all the
> different units, etc.

Generally you need some kind of "type abstraction firewall" between
parts of a large program to limit the code changes required by some
data representation change.  This is true no matter how your program
is structured, whether procedural, functional, object-oriented, or
something else.

These firewalls need to be present in the source code to allow code to
evolve; they may or may not be in place in the compiled output,
depending on the way the program is structured, and whether or not
they are in place determines how much of the compiled output you have
to rebuild and replace when upgrading the program.

If you do not put such firewalls in place, expanding the types of data
your program can handle will require rebuilding the whole world.

Statically-typed languages tend to require less work to determine what
parts of a program must change (they fail typechecking), but more
effort to make the change (because you must typically fix type
declarations and because elementary operations tend to be less
polymorphic).

> However, my experience with some [dynamically-typed] languages
> (notably Visual Basic and Python) lead me to believe that this
> dynamicism often shifts bugs forward in time, so that you do not
> encounter them until users are exercising a program in ways not
> previously anticipated by the SQA team -- or when the program runs
> in an environment that differs in some fashion from the original
> test bed.

Carefully reasoning about your programs, seeking convincing arguments
that they must be correct, is a much more efficient way of making code
correct than testing is.  Perhaps static typing encourages programmers
to do this.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
When the battle between "us" and "them" is equated with the battle between 
good and evil -- then we have placed ourselves above all evil. This is to 
make gods of ourselves.  -- Steve Talbot, NETFUTURE #129, via SMART Letter