The Unreasonable Effectiveness of Dynamic Typing for Practical Programs [video]
This is just rehashing the same tired and fallacious argument that most errors aren&#x27;t type errors. And it is pure fallacy because different languages have different ideas as to what constitutes a type, and therefore have completely different ideas as to what a type error is. If I write `Object.new.foo` in Ruby, I get a NoMethodError. Not a type error, right? But that&#x27;s the thing, that would be a type error in almost all statically typed languages.<p>And it doesn&#x27;t even come close to stopping there...there are hundreds of examples of errors that are not Type Errors in your dynamic language that <i>are</i> type errors in some other language. NullPointerException? That&#x27;s a type error that is entirely prevented by <i>many</i> type systems. If you accidentally multiply your time and distance instead of divide to get your velocity, that would be a Type Error in F# using their units of measure types. If you accidentally pop an empty stack, that might be an EmptyStackException even in many statically typed languages, but would absolutely be a Type Error in a language with dependent types like ATS or Idris.<p>In the end, dynamic typing is just a way to make runtimes slow and building correct programs slower, in exchange for some entirely subjective aesthetic or ergonomic quality. And sure, most type systems in practical languages aren&#x27;t &quot;complete&quot; enough to eliminate the need for tests. But don&#x27;t tell me that because you don&#x27;t eliminate tests that you don&#x27;t need types. That&#x27;s bullshit. Statically enforced types eliminate errors, and every check that you defer to runtime is an error waiting to happen. If you&#x27;re willing to make that tradeoff, by all means do so...but don&#x27;t lie to me.