Type Wars

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.

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.

> No, it's necessarily true. The vast majority of type errors I experience get picked up during TDD. A small minority reach production.

I'm not trying to argue against your experience (or persuade you against it, for that matter). Only making a point that it is possible for you to have type errors that go uncaught by unit tests unless (unless you run those tests against all values).

> It's very easy these days to write tests that cover an enormous range of inputs and outputs (e.g. see quickcheck).

Quickcheck takes advantage of types to narrow the inputs for generative tests, whereas dynamic languages have to content with any possible input.

>> I believe there is almost no overhead imposed by a static type system > I think that's wishful thinking.

Here's a couple ways I think you actually waste more time in dynamic languages:

1. Type checks. Sounds almost tautological, but it's true. Any time you see someone using the type() function in python, you're branching in code for something a compiler could take care of for you.

2. Redundant validation, specifically against a purely functional language that is statically typed. Since types encode facts about data and functions encode theorems, statically typed languages only require one test to verify the assumptions in a theorem. In other words, if there is one function creating values of type Foo with an integer attribute "foo" and it insures that "foo" is 0, I never need to check if foo is 0 anywhere in production code. I only need to check that in a single test of the constructor. In practice I find this means I need to write a lot less tests with a statically typed language, and generally a lot less branches in code.

3. Documentation comprehension. I can't count the number of times I've read a javascript library's documentation only to be thoroughly confused about what kinds of values can be passed to a function legally. Since the language provides no way to enforce this, it seems to encourage a culture of negligence about documenting what invariants of data are required to hold. Furthermore I rarely get a descriptive exception informing me what the issue is, rather I get a type error about a missing attribute or something.

4: Boilerplate code. Fixed data schemas mean you can generate efficiently executing code to perform tasks like serialization, client libraries, etc. Take a look at servant: https://haskell-servant.github.io/ Because haskell is statically typed, the type system makes it trivial to generate an HTTP server, a client, and a swagger API docs page all from a couple types. This can be done for certain things in dynamic languages, but since it requires introspection it will almost definitely be slower (and in some cases that may make it impractical to use).

5. Refactoring. Dynamic types are notoriously a pain for editors. Values can be changed ad hoc in ways that make it very difficult to change names without some smart regexes. Refactoring in statically typed languages is a breeze with a sufficiently smart editor/ide. Find and replace is generally two clicks away and is guaranteed to find all occurrences and replace them safely.

6. Condition checking. Pattern matching is not exclusive to statically typed languages, but it is much more common in them. Static type systems also allow for exhaustivity checks that a dynamically typed language cannot perform.

In general I think the things people claim are time consuming about statically typed languages are based on older languages that are lacking richer type system features. Things like:

1. Omnipresent type annotations. In haskell you almost never have to specify one of these (in fact you can get near 0% of these if you turn off the monomorphism restriction). The most common use of type annotations in for function signatures, which I find are nice to have for documentation purposes anyways.

2. Inability to perform generalizable code. A lot of people base this on experience with languages like Java, which is unfortunate because the state of the art is much farther ahead. There are many "dynamic feeling" generalizations you can get out of newer statically typed languages. For instance, you can easily generate a "falesy" abstraction similar to python or javascript through haskell typeclasses. Typeclasses, functors, etc. are all examples of statically typed features that allow you to write abstract code over disparate sets of types.

> Nearly every language has continued to repeat Tony Hoare's "billion dollar" mistake of allowing null to inhabit any type.

Perhaps I was unclear. I could not agree more with this assessment (see link to my blog post in sibling).

I was merely commenting on Swift's choice to do it in a (to quote the OP) "clever" way, rather than a general one like Rust or Scala.

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