Also, how does full unit (!) test coverage prevent a situation where unit A passes some type to unit B that unit B doesn't expect but happily runs with, but with different semantics?

Documentation of interfaces in dynamic languages usually always specify the types of arguments and return values, and the code very often looks like this:

    def foo(arg)
      raise TypeError, "Integer argument expected" unless arg.kind_of?(Integer)
      # ...
    end

Yup. That saved me a lot of typing (no pun intended) compared to

    void foo(int arg) {
       // ...
    }

Reading (and writing) code in dynamic languages (including the tests!) always seems to me to disprove all of their purported benefits and underlines the need for a strong type system.

Yup, the right tool for the job. Type systems are really good at enforcing inter-unit contracts, while tests (especially property tests) are very good at making sure that the implementation is correct for at least a subset of inputs.

This reminds me of a talk from StrangeLoop 2012 by Paul Snively and Amanda Laucher "Types vs Tests". Well worth the watch.

https://www.infoq.com/presentations/Types-Tests

Exactly. Types are a class of tests, checked by the compiler at compile time.

Right. They are one class of tests that happens to be checked at compile time. 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).

And 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? What if it catches 10% of errors (optimistic estimate) but due to constraints in reusability makes my code 20% bigger (conservative estimate)? Likely around 10% more bugs.

Don't get me wrong: I like static typing (to some degree). I just get antsy when it gets oversold.

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?

I whole heartedly agree with this sentimate