🚀 go-pugleaf

Dan Bernstein writes:

   In contrast, the supposed conciseness of dynamically typed languages
   costs dearly in compile time, run time, and (for projects with many
   debugging runs) programming time. For these disadvantages it would have
   to provide a huge benefit for maintenance, yet its proponents never seem
   to come up with examples showing such a benefit.

Perhaps Dan would like to explain why dynamically typed languages "cost dearly
in compile-time", since the compiler is performing fewer checks? I can think of
three possible interpretations:

(a) The compiler is slower, because it has to generate extra code for the
necessary run-time checks.

Planting a few extra procedure calls is unlikely to take as much time as (say)
doing ML-style type unification.

(b) The compiler is faster, *but* it will be called on to compile entities very
many more times as their trivial type errors are detected.

Removing type errors doesn't tka that long (by observation). Also, for entities
that are complex enough that they take several passes before their type errors
are removed dynamically, they'll probably take several passes through the
static checking compiler - trashing any presumptive speed advantage.

(c) The compiler is written in the language it compiles, hence is dynamically
typed, hence is slow.

Begs the question. Also the compiler (being a relatively fixed application) may
have had optimisations applied to it - such as optional type declarations - to
make it go faster. It may have had optimisations applied to it that are only
possible by virtue of being dynamically typed.

Dan being Dan, he probably has some alternative (i) in mind; perhaps he would
enlighten us.
--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."