- testing probes individual cases for correctness. it's
for making sure your assumptions are correct. type systems
entire categories of flaw do not exist in your code, i.e. an
number of test cases. I do not for a minute believe the
normal unit tests will find "every" error a typecheck will
find. tests and types do different things.
- moreover they are fast. a typecheck is faster than all
most utterly trivial test. the argument he makes against
compile times is surprising considering how much longer a
strong regression suite will take to run.
- really, the compile time argument is an argument against
C++, which involves both extensive machine-level
optimization and a
hiddeously poor declaration management strategy (textual
inclusion). this is not a valid critique of static type
you want near-instant builds of programs in typed languages,
get a native
non-optimizing bytecode compiler for a language with binary
declarations like ocamlc.opt
- in fact, if you are trying to produce optimized code,
time with a dynamically typed language is almost always
going to be
longer, because you have to do far more extensive partial
type systems save you the hassle, and make it much easier to
- modern HM-based
languages infer nearly all their types from the data
anyway, so you don't actually have to enter them into the
code. so unless you're actively avoiding a strong
system, you can basically get one for free. it doesn't
affect "agile processes" like XP's "aggressive refactoring"
any worse than
pointing out when you make an inconsistent change, which is
generally something you want to know about.
- redeploying software is always a fragile
affair. I can
just as easily change a "base class" or some other central
bottleneck and break a typeless language as a typed one. the
in any case is to reduce coupling around the points which
to change. It's slightly hard in C++ because it computes
explicitly (again, for speed) but you can get around it with
a compiler firewall
you think your implementation is going to change its layout.
I agree with his assertion that "scripting languages" are becoming more important, but not because they're good for producing robust software. they're important because a lot of people want to write one-off programs, and languages with "simple syntax" lower the barrier to entry. this is good. this de-thrones the high priests of programming and puts automation in the hands of normal people. it's ok to have some failures in a one-off program to automate a task you would have done sloppily, by hand anyways. nonetheless, with friendly enough syntax, you can slip a good type system in while nobody's looking, and some people will appreciate the extra error checking. perhaps mondrian will actually introduce legions of windows slaves to haskell. doubt it, but who knows?