Ideally, the best way to approach a problem is going to be to find the right type to express it. However, sometimes problems in the real world can only be type

Ideally, the best way to approach a problem is going to be to find the right type to express it. However, sometimes problems in the real world can only be typed with types that are so complicated that you end up with no confidence that you're doing the right thing. Sure it checks at compile time, but you're not convinced that the program is doing the right thing. In these instances you might as well create a dynamically typed system and see what happens when it meets real life. Yeah it might fail, but the static version was going to fail too. You can save time by not having to worry about what the "proper" type is. The other side of this is: What do we really want our types to do for us? This isn't always the same thing for everyone. I've created DSLs in a dynamic system that failed in weird places and when I tracked down the reason it was because I was using two functions together that did not agree on the "type" they were passing between themselves. In this instance, type theory wasn't going to help solve my problem, but a quick "typecheck" of the code would have pointed me in the right direction to find a silly mistake. On the other hand, sometimes you can use types to solve your problem. I know it's a bit cliche, but rust is a good example of this. If you want to avoid GC but still want high level programming features and no memory corruption then linear types is one way to achieve that.