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.
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.
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.
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.
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.
Nice, that’s a really interesting way of looking at it! Also sort of like having conversion with the compiler.
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.
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.
Good call. I’ll update it to point out that it’s typescript
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
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.