Hi Juan,

That is a very good question. For me personally, the answer is I use it if the cost is not significant but the benefit is. In my case (as I write subsequently in the article) I believe types can be extremely useful in program optimization, and I'm happy to declare them, provide them as necessary where such benefit may be obvious.

The other constraints that type checkers require where I don't get (or need) that benefit cause me to introduce (usually) needless injections and projections which affect both my speed of programming as well as more places to make mistakes. The irony is that of course the type checker will catch them, but then I will cuss the heck out of it because I just wasted time doing something that I didn't need to do in the first place, and now I have to spend more time fixing that! So rather than saving me time, it takes me more time to get stuff done.

I am also a rigorous tester so I test every function from the bottom up trying to get as much coverage from my tests, particularly with negative tests. I do this regardless of static typing or not. Which means that for me, the supposed compile time type checking provides almost zero benefit, but has a high cost, both in terms of development time (which I can objectively measure), and program clutter (which is somewhat subjective, but most engineers will agree upon when they see it). Hence I have given up on static typing. It's not worth the effort.