1. 8
  1. 6

    Good article. When I’m teaching refactoring, I often have people lean on the compiler when they can rather than writing tests. In some IDEs, compilation errors actually show up in test results. I use this is a talking point. The way I put it is:

    Types and tests are both ways of making assertions about code. The type system of a language is the set of tests a language designer could come up with without seeing your program.

    1. 3

      Nice, that’s a really interesting way of looking at it! Also sort of like having conversion with the compiler.

    2. 5

      Didn’t talk about it in the article, but this style also reminds me of “development by wishful thinking” that is discussed in the great SICP lectures.

      Write the functions I wish I had, with types. Making the type-checker happy helps me think through the implementation, and the API is probably/hopefully better because it’s what the user (myself, in this case, using the code that I haven’t written, yet) needed or wanted.

      1. 3

        Firstly I really enjoy the concept of this article and I agree! Some nits, I would really like to see some type definitions here and what language we’re looking at. I know for regular readers of your blog they’ll know precisely what language you’re using but for me I was confounded for several seconds before I realized we were looking at typescript.

        1. 2

          Good call. I’ll update it to point out that it’s typescript

        2. 1

          A little tongue in cheek, people approach this also from the other side as well, i.e. https://stackoverflow.com/questions/415434/can-automated-unit-testing-replace-static-type-checking

          1. 1

            Nice find, and it makes sense to me that there is overlap between testing and typing. Things like dependent types or Clojure spec blur the lines even farther.