Don't underestimate the productivity boost provided by the little squiggly red line. The fact that your tooling will stop you from ever passing T when the expected parameter is Collection<T>, and that this "rescue" involves pretty much zero cognitive overhead, is invaluable. When I work in a statically typed language, I find that I pretty much never make "head-desk" type errors, and despair at their reappearance when writing... javascript.

Hmm...much of the disconnect might be that when people think "dynamically typed language", they think JavaScript and Python and Ruby.

I also don't make these mistakes while writing Smalltalk.

What feature of Smalltalk, but absent in Python/Ruby/JS, prevents these mistakes?

> But what about all the other tests that you still have to do?

You should do those too.

> Which typically also coincidentally check the types (if I check that a value is > 2, I am also checking that its type is number

    ~$ python -c 'print "foo" > 2'
    True

Now, on the bright side, Python 3 fixes that one:

    ~$ python3 -c 'print(2 < "foo")'
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    TypeError: unorderable types: int() < str()

But most popular dynamic languages seem to have more where that came from. And if you have a sufficiently robust type system not to, then it starts to look a lot like the type system of a static language, minus the compile-time error detection.

> what is the value of "compile time", if the all this type checking makes the compiler so slow that just compiling is slower than compiling + running unit tests in a simpler language?

To the best of my knowledge, type checking is hardly the slowest part of most compilers. Many dynamic languages have somewhat faster startup times because they don't have a compiler, or they use a JIT at runtime. In any case, for many non-trivial programs, runtime dominates. A sufficiently thorough unit test suite may take significantly longer than compilation. And even if not, someone has to write the unit tests that handle what static type checking does for free.

I'm not going to claim that static typing is universally better; for instance, it's a lot harder to provide a good REPL in a statically typed language. But personally, I like dealing with as many errors as possible up front, rather than discovering them later on.

But what about all the other tests that you still have to do? Which typically also coincidentally check the types (if I check that a value is > 2, I am also checking that its type is number (or int or whatever your particular numeric tower or non-tower says).

I see this argument from fans of dynamic typing quite a bit. Gary Bernhardt manages to defeat it better in 5 minutes than I could in a lifetime, so here you go:

https://www.destroyallsoftware.com/talks/wat

Really? OK, if you're going to base your arguments about dynamically typed languages on JavaScript, then I'm going to base my arguments about statically typed languages on C.

'asdas' > 2 <Print It> -> Message not understood "SmallInteger>>isByteString"

So what languages would you like to compare on a like-for-like basis? There are plenty of useful invariants that would be verified by the static type systems of everyday languages, but not picked up implicitly in unit tests.

On further reflection, I'm not even sure how your argument about integers is supposed to work. Implicitly testing that an input is an integer by comparing it to another one in a single unit test case wouldn't guarantee that no other code could pass a non-integer input to the same function from somewhere else in the general case, which is what a static type system would do for you.

The context where your argument does seem to have some merit is in unit testing that the outputs from a function are of the expected type. But even then, there have been plenty of related gotchas in JavaScript, Ruby, Python, PHP, Perl... I'm sure you can pick an example where your particular case (the integer test) gets picked up, and I'm sure some popular dynamic languages are getting better in this area (Python 3 has significant advances over Python 2, for example).

Basically, this feels like you're choosing an invariant and a dynamic language that conveniently support your position, while ignoring numerous other useful invariants and languages that would not. If you get to do that, it seems only fair to judge the potential of strong, static type systems using languages like Haskell or Rust, and I can't think of many unit tests I've ever written in dynamic languages that would implicitly verify that the unit under test didn't have unexpected side effects or did not allow access to resources in ways that might not be thread-safe, even in the specific case being tested rather than the general one.

>if I check that a value is > 2, I am also checking that its type is number

Surely, you're only testing that it can be coerced to a number?