splork: imho dynamically typed languages are really not your friend for large projects. the arguments put forth in this article are really wrong-headed.

• testing probes individual cases for correctness. it's important for making sure your assumptions are correct. type systems prove entire categories of flaw do not exist in your code, i.e. an infinite number of test cases. I do not for a minute believe the claim that 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 but the most utterly trivial test. the argument he makes against lengthy compile times is surprising considering how much longer a really strong regression suite will take to run.

• really, the compile time argument is an argument against compiling 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 systems. if 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 or jikes. they cook.

• in fact, if you are trying to produce optimized code, your compile time with a dynamically typed language is almost always going to be longer, because you have to do far more extensive partial evaluation. type systems save you the hassle, and make it much easier to write optimizing compilers.

• modern HM-based languages infer nearly all their types from the data constructors anyway, so you don't actually have to enter them into the source code. so unless you're actively avoiding a strong type 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 dependency bottleneck and break a typeless language as a typed one. the solution in any case is to reduce coupling around the points which are likely to change. It's slightly hard in C++ because it computes vtbl offsets explicitly (again, for speed) but you can get around it with a compiler firewall or some componentware if 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?