The Haskell / Snap ecosystem is as productive (or more) than Ruby/Rails.

The bit where dynamic languages get really complicated is that they allow for you to use types that hadn't been taken into consideration when the language was designed. For example, in Python you can write code using duck typing and it will Just Work(TM) but if you want to do something equivalent in Haskell you would need tell GHC to use one of those weird language extensions just to have the program typecheck. The monkeypatching you mention goes more along this line, I think.

And your logic is definitely faulty. I've never used the word "good"

What I said is "more productive" (what the author claims) can only be measured in actual PRODUCTION.

That is, the important thing is not:

(a) "If I were to use X framework/language, how productive would I be over Y framework/language?",

but:

(b) "In an actual empirical observation, what framework/language is actually responsible for the largest volume of production?"

The author talks about (a), and advocates Haskell. But that is not an empirical, scientific, measurable observation, it's just his personal opinions, feelings and anecdotes. Only (b) gives an actual overall metric of the productivity of two frameworks/languages combos.

Even having the same person doing the exact same project with both X and Y framework/languages and comparing the speed with which each was done, would tell us very little. Maybe someone he was more comfortable with one or the other, maybe that particular project fitted especially X over Y, maybe it didn't need to communicate with legacy stuff with neither X nor Y do well, etc.

The only way to tell what generally was for production for the majority of people, is to, DUH, see what the majority of people have used for their productions.

I kind of agree with your second sentiment - but I did want to point out that it's entirely possible to write a dynamically typed compiled language too.

It boils down to type systems: weak/strong, and dynamic/static. C, for instance, is weak/static: you define types, but you can basically pass around whatever you want to:

    #include

    int main(int argc, char* argv[]) {
        int result = add(1, 2); 
        printf("%d", result);
        return 0;
    }

    int add(int a, char b[]){ 
        return a + b;
    }

Inside that method though, I do something entirely braindead: I add the integer and character array as if that were an operation that makes sense. Then I call "add" with two integers anyway, and let it do what it wants. It actually does return 3: rather than throwing a runtime error to say "hey, this is stupid, I should have a String here and you can't add a String to an integer!", it just trundles merrily along. A strong type system wouldn't let you compile or run this: it'd tell you off for trying to call a function with invalid arguments, then (hopefully) tell you off for using "+" in a nonsensical way.

FWIW, the following also works:

    #include

    int main(int argc, char* argv[]) {
        int result;
        char aString[] = {'h', 'e', 'l', 'l', 'o'};
        result = add(1, aString);
        printf("%d", result);
        return 0;
    }

    int add(int a, char b[]){
        return a + b;
    }

At the other end of the spectrum, Python and Ruby are strong/dynamic: you can pass whatever types around you want, but the interpreter will crash if you try to do something the type system doesn't allow. You can't do 1 + "test": it makes no sense. It won't even try to run it and return something nonsensical, it just won't run.

All that said: I don't know if there are any strong/static languages without a compiler. I can't seem to think of an application of such a language: the best way to exploit a strong/static type system is to have it tell you, up-front, that you've made a mistake (and, of course, have your compiler optimize the pants off your code for runtime).

I also don't know of any languages which are compiled, but fully dynamically typed (Scala, maybe? Although it allows static typing too). Considering the benefits you can gain from type analysis during compilation, again, the concept seems a bad fit. Although (same as in the previous example), you could happily write a language that is!

So, yes, compiling the code is what enables you to perform those checks - but a strong type system is a part of compilation in its own right :).