Re: Static/Dynamic typing, lessons from the field

Marcin 'Qrczak' Kowalczyk wrote:
> "pp" <pedro.e.pinto@xxxxxxxxx> writes:
>
> > http://opal.cabochon.com/~stevey/blog-rants/strong-weak-typing.html
>
> This article is being discussed at
> http://lambda-the-ultimate.org/node/1268
> and the general conclusion is that it's clueless.

My general conclusion is that the article is clueless, and most of that
discussion also.

When we eliminate obvious obsolescence like C++ and Java with type
declarations everywhere, what is left is that the difference between
static and dynamic typing is one between what sets of programs are
accepted.

Firstly, ignoring for a second the idea that catching type exceptions
can be incorporated into the logic of a software system, type checking
is not strictly required. A program that is free of type mismatch
errors will run properly whether or not type checking is performed. It
chugs along and always correct operations to correctly typed data.

Type checking, whether static or dynamic, is a safety net that we apply
because we don't trust programs to be free of type errors.

Static type checking means that there is a safety net consisting of a
function that analyzes the program without actually running it. That
function can either conclude that the program A) has a type mismatch
error, B) that it certainly has no type mismatch error, or C) that
although no error was found, no conclusion can be drawn that there
isn't an error.

A statically typed language applies the type checking function, and
then rejects programs that land into case A, but also ones that fall
into case C.

Under a dynamic language, type checking means that the program for
which C was reported can be run anyway, and the type checking safety
next extends into the run time.

Therefore, static languages are quite simply crippleware: they duck out
of case C) whereas dynamic languages keep going. They don't have the
run-time support to deal with case C.

The static diagnostics themselves are valuable, of course; it's the
rejection of some perfectly good programs that is the problem. At the
very least, there should be a switch. The developer should decide
whether the program is to be run anyway, an the run-time support should
rise to the occasion. In category C) are all kinds of useful programs
which make our programming lives easier and more productive. Then you
can decide which paradigm is appropriate for any given problem without
switching languages.

One posting in the above blog, compares dynamic typing to manual memory
management in a completely clueless way.

If we compare type systems to memory management, then static type
checking is analogous to statically computing object lifetimes and
inserting the object liberation calls into the compiled code, so that
dynamic garbage collection is unnecessary.

The static object lifetime computation can either conclude that the
lifetimes of all objects can be determined, or that the lifetimes of
some objects could not be determined.

In the latter case, if the program is to be run anyway, then dynamic
object lifetime computation, i.e. garbage collection, is necessary.

If garbage collection is not implemented and such programs are
rejected, it means that all kinds of useful software cannot be written.

So, because garbage collection is dynamic, it is not commensurable with
static type checking. Garbage collection does not reject programs, it
cleans up after them.

.