翻译自：https://dzone.com/articles/types-when-i-use-when-i-dont
注：以下纯属个人意见。
如果我做一个简单的程序，我不关心该使用强类型语言还是弱类型语言。但是如果我的程序很复杂，并且需要由多人进行维护，那么我一定会选择强类型语言。
何时用强类型语言
现在，许多现代的编程语言都支持类型推导(type inference)，因此强类型语言代码看起来和弱类型语言的代码一样简练。诸如Scala/Haskell/OCaml/Kotlin/ELM等强类型语言既简练又十分优雅。
何时用弱语言类型
我们依然需要编译代码，并且这也需要耗费时间，但是我认为编译工作是值得的。因为代码的维护和理解也需要耗费时间。相比于解决bug和阅读代码所需要耗费的数小时时间，我认为花费数秒去进行编译代码是值得的。
类型推导+强类型=>简练，可读性强的代码！
类型推导的性能瓶颈
我们为编译代码付出花费时间的代价。如之前提到的一样，我倾向于在编译时花费少量时间而不是在阅读与理解代码时花费更多的时间。
难于理解的程序编译也会很慢。
因此，如果你的代码可读性强，编译也能块很多。
参数化多态
参数化多态：定义相同子类型的容器。
译者注：参数化多态是指编码可以不指定任何特定类型，在被实例化作为参数时才去确定类型。在面向对象编程中，称之为generic programming，而在函数式编程中，则被简称为polymorphise。
定义Array[A]，我们可以有自己的实现方式并对数组进行操作和使用。
子类型多态
通过继承类来实现多种实现，但是这会导致大对象(类层次结构)的产生。我认为这会导致代码泥团。
译者注：代码泥团是指一个随意化的杂乱的结构化系统，只是代码的堆砌和拼凑，往往会导致很多错误或者缺陷。
子类型多态：代码泥团。当你遍历数组时会遇到很多数据类型。
简单类型系统
和Java一样，我们使用模具（函数做什么，程序如何构建等）有很多好处。
简单类型系统提供易用的模具。
简单类型系统提供编译器检查过的文档。
使用无类型推导语言时，你需要向编译器解释你的意图。
复杂类型系统
这里我们讨论诸如Scala/OCaml和Haskell等语言。
复杂类型系统提供简单/简洁的代码！
这听起来优点不寻常，但确实如此。例如，泛型用于扩展代码以用于不同类型的多态，也就是代码重用。返回Int还是Double，我不关心，我返回A就可以。
复杂类型系统减少bugs
谎言：需要编译的语言在减少bug方面做得更好。
我不认为这是正确的。但是很多bugs消失了：
- 空指针异常，自从使用Scala我就没碰到过。
- 函数未定义。使用ELM后可以忘记这个bug。
总结
我的结论很简单：需要由他人维护或者工作量很大的代码，使用强类型语言。简单的脚本和简短的代码片，使用弱类型语言。
