Yes, it's this flexibility that allows you to experiment. Static typing proponents often say, since a type-error means that the code doesn't make sense, why wo

Yes, it's this flexibility that allows you to experiment. Static typing proponents often say, since a type-error means that the code doesn't make sense, why would you ever want to run code that doesn't typecheck? But I find that when I'm experimenting, I want to do this all the time. I ran into this recently when I was working with Rust. And don't get me wrong; I love Rust. But I was experimenting with a new way of doing things in my codebase and was adding a new kind of statistical analysis, and I wanted to run a test case to see what the result was... However, I couldn't because the compiler's typechecking refused to even compile my code, when I knew for a fact that the type errors had nothing to do with the code path of my test case. I get that that's the whole point of static checking. I can change a large codebase and know exactly when/where I've broken something even if I'm not familiar with all the code, and it will barf at me. But the fact that I can outsmart it, even some of the time, leads me to believe that there will always be a place for dynamic languages. If 99% of my code has type errors, but there is one code path that is true, who is the compiler to say that that isn't the one code path that I want to take? When experimenting, I build my code dozens of times. The vast majority of the time, I am the only one who consumes the build result. Once in a rare while, I will reach a steady state and build a release. It's really only then that I want the compiler to barf at me and refuse a broken build. I must not be the only person on the planet who wants to do this sort of thing.