Though it's stated at the beginning of that post, it was primarily a response to this vacuous post attacking dynamic languages. Frankly, the main problem with dynamic languages is that they're still relatively new and finding their feet. As a result, there are plenty of things which quickly get frustrating about them. However, the author of the 'attack' post seems to miss the point quite a bit. For example:

Can dynamic typing result in a reduction in code volume of 80 to 90 percent? It seems highly improbable to me. Suppose I had a piece of Java code and went through it removing all the type qualifications. Would that reduce the code volume by 80 to 90 percent? No, I don't think so. Maybe there are other omissions that dynamic typing would make possible, such as obviating adapter-style classes and some interfaces. But even including such omissions, claiming an 80 to 90 percent code saving seems a bit rich.

The author doesn't seem to have extensive familiarity with dynamically typed languages. It's far more than removing type qualifications, adapter-style classes and the like. Consider the classic case of writing a line to a file in Java:

import java.io.*;

class WriteFile {
    public static void main(String args[]) {
        FileOutputStream foStream;
        PrintStream      pStream;

        try {
            foStream = new FileOutputStream("somefile.txt");
            pStream  = new PrintStream( foStream );
            pStream.println("This is written to a file");
            pStream.close();
        }
        catch (Exception e) {
            System.err.println ("Error writing to file "   e);
        }
    }
}
[download]

Now let's compare that to Perl (the close is implicit when the filehandle is out of scope and use you 'use fatal' to make your exceptions automatic!)

open my $fh, ">", "somefile.txt"        or die "Can't open file: $!";
print $fh "This is written to a file\n" or die "Can't print to file: $
+!";
[download]

These examples and many, many more can easily show a tremendous difference in both the length and maintainability of a "dynamic" versus "static" language (granted that those are loose terms). That's far more than just type declarations or adaptor classes.

Here's another gem:

Most DLs are interpreted rather than compiled. This means that your test/debug cycle no longer includes an explicit "compile" or "link" step which, DL weenies claim, makes for a "development cycle that is dramatically shorter than that of traditional tools." Maybe so, but how significant an impact does that have on overall development speed? You don't have to wait for the compile/link to occur, but you still have to wait for the thing to execute so you can test it, and interpreted languages are often slower to execute than compiled ones. So how much do you really gain overall? And there are other confounding factors. Perhaps the compile-time type checking of a static language serves to catch bugs that a DL won't pick up until runtime, in which case some of your test/debug cycles for a DL will be spent catching type-related problems that a static language would've detected before execution began.

He missed the boat on his first criticism. I rarely work on code which is significantly slower (for me) in a dynamic versus compiled language. So I wait an extra half-second for my CLI or Web page. That really doesn't affect what I do (though for batch processes that run repeatedly, this can add up). If my CPU performance is the limiting factor, I'm not going to be using a dynamic language in the first place!

His second point is correct that static languages often pick up bugs at compile time that dynamic languages pick up at runtime. This is certainly something which has bitten me before, but most decent programmers I know who have worked with both static and dynamic languages comment that this problem happens far less than 'static-only' proponents think. That being said, it can be a pain to track down when it does occur, but the development speed with dynamic languages seems to more than make up for this occasional issue.

He raises other points, some good, some bad, but altogether, it doesn't seem to be a terribly well-thought out essay. It's the usual "my way is better" argument but without much substance behind it.