3 ms·
I've used a variety of languages in my career, both statically-typed and dynamically-typed[0]. I generally like both. Here's my take against static typing: 1.
by yen223 6y ago
I've used a variety of languages in my career, both statically-typed and dynamically-typed[0]. I generally like both. Here's my take against static typing:
1. Static type checkers increase compile times. This is an acceptable tradeoff if they can catch bugs at compile time, but not if they still still allow bugs to occur at runtime.
2. If you're building a system which has to interact with other systems a lot, static types can be a hindrance if your static type system and their type system don't agree on fundamental things like how data should be modelled. This manifests itself as things like the Object-Relational Impedance Mismatch[1]. You would end up writing a lot (A LOT) of code to bridge the two, and in general, more code = more bugs.
3. Static type checkers can have bugs or quirky behaviour. This can lead to a lot of wasted time, and/or inelegant workarounds that makes your code less understandable (and therefore, more likely to have bugs in the future). This is one that I encountered recently: https://typelevel.org/blog/2018/05/09/product-with-serializable.html https://typelevel.org/blog/2018/05/09/product-with-serializa...
4. It's surprisingly hard to find any research that can demonstrate that static type checkers actually lead to fewer bugs.
[0] Python, Clojure for dynamically-typed languages, Typescript and Scala for statically-typed languages
[1] https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe...
- rualca 6y ago> 1. Static type checkers increase compile times. It should be noted that this potential impact on compile times amount to a few seconds. > 2. If you're building a system which has to interact with other systems a lot, static types can be a hindrance if your static type system and their type system don't agree on fundamental things like how data should be modelled. I fail to understand how failing to comply with a contract is a type checking problem, and one which goes away if you no longer perform validations. > 3. Static type checkers can have bugs or quirky behaviour. This can lead to a lot of wasted time, and/or inelegant workarounds that makes your code less understandable (and therefore, more likely to have bugs in the future). I'm not sure if your example is valid, as in your blog you quite openly state that the root cause of your bug was your failure to specify the right return type. You can't really fault a system by complying with the definition you've provided. > 4. It's surprisingly hard to find any research that can demonstrate that static type checkers actually lead to fewer bugs. A quick search in Google Scholar for "static type bugs" popped about 4k search hits, the first of which is an article on quantifying detectable bugs on javascript which states that switching to typescript allowed 15% of public bugs to be detected.