I had a look at your referenced source (https://ia-petabox.archive.org/details/the-best-software-writing-i/page/76/mode/2up https://ia-petabox.archive.org/detai

I had a look at your referenced source (https://ia-petabox.archive.org/details/the-best-software-writing-i/page/76/mode/2up https://ia-petabox.archive.org/details/the-best-software-wri...), but I didn't find statements as strong as the summary you give in your paper or blog post. Here are some quotes to convey the tone: "If your unit tests provide good code coverage, don't feel too paranoid about giving up compile-time type checking." (pp 69) "The only guarantee of correctness [...] is whether it passes all tests which define the correctness of your program." (pp 75) "To claim that static type checking constraints in C++, Java, or C# will prevent you from writing broken programs is clearly an illusion" (pp 76) The closest I could find to your quote was at the end: "a dynamically typed language could be much more productive but create programs that are just as robust as those written in statically typed languages." (pp 77) In the context of the article (see previous quote), this is presumably referring to the goal of "defining the correctness of your program", and the article in fact makes the point which I made reference to, which is that incorrect inputs and API usage could well be out of scope for this goal (and perhaps were in the programs you tested). Or, to put it another way, it doesn't make sense to talk about robustness unless you also give a context. The worst I could say about the article is that it is kind of tautological, because it's easy to no-true-Scotsman the concept of "sufficiently good" unit tests. But to be honest this also happens with type systems. I realise there's a lot of ... let's say "enthusiasm" in this particular area, but I found the article quite a bit more measured than what was implied by the blog post.