静态类型不是用于类型检查的

在他的岗了这个想法，静态(或强)类型语言不会给你带来太多，因为无论如何你都应该用测试来验证你的程序，这些测试也会检查类型——不需要编译器这样做(特别是当它使你对语言的生产力降低的时候)。

虽然这看起来是一个非常好的观点，但我有一些反对意见。

首先，他的术语不是普遍认同的术语态类型(在编译时检查类型)与强类型(没有或很少隐式类型转换)之间的区别。为了澄清本文中使用的语言——Python是动态的强类型语言。

但是我们不要对术语吹毛求疵。我反对静态类型只是给你一些额外的测试，无论如何你都应该写。

在一个用动态语言写的项目中，你能看到一个方法的调用者吗？在他的例子中谁调用了speak方法？你会去搜查吗？嗯，如果你有很多同名的方法(iterator(), calculate(), handle(), execute())?也许你会给它们起不同的名字？并且确保你永远不会在整个项目中重复使用一个方法名。就生产力而言，快速浏览大项目代码的能力是最重要的能力之一。这并不是说带有优秀插件的vim不允许你浏览类和搜索方法——只是不可能在动态语言中做到像在静态语言中那样精确。

然后我想知道在给定的对象上可以调用什么。在我写代码的时候做API“发现”。在一个大项目中，你有多少次绝对确定要对第一次看到的类的对象调用哪个方法？去那个班？哦，是哪一个，因为你只知道它有calculate()方法(当前方法中调用的方法)？编写一个测试来验证您是否可以调用一个给定的方法是可以的，但是不能让您发现在那个时候您有什么选择——什么方法最适合您。下面是自动完成内联文档。这不是为了节省击键次数，而是为了知道在代码的这一点上什么是允许的。我猜不断地打开API文档页面或其他类定义是可行的，但这很乏味。

然后是重构。是的，你知道我会提起的。但这是我们编写的测试让我们能够使用的最重要的特性。我们有所有的测试，这样我们可以保证当我们改变一些东西时，代码将继续正确工作。然而，只有在静态类型语言中，才有可能进行全功能的重构。向一个方法添加参数，将一个方法移动到另一个类，甚至重新命名一个方法，而没有附带的损害。是的，在Ruby或Python中，有多种试探法可以让重构变得可能(JetBrains正在尝试)，但从定义上来说，它不可能那么好。有关系吗？即使它不会自动发生，测试也会发现，对吗？如果你有100%的保险，他们会的。但这并不意味着做改变需要更少的时间。与静态语言的几次击键相反。

那些“神话般的大项目”是什么，上面的所有特性都是游戏规则的改变者？嗯，根据我的经验，大多数项目的生命周期超过6个月。

所以，不，静态类型不是关于类型检查的。它是关于你能够更快地理解一个庞大的、不熟悉的(或被遗忘的)代码库，并且有更高的确定性，以你的方式理解它，并且更安全更快速地改变它。不过，类型检查是一个便利的好处。我不会采用“静态类型语言运行时间更快”的论点。(尽管我非常喜欢静态和强类型，但我并不打算放弃动态类型语言)

然后人们可能会说“你的花哨工具和ide试图弥补语言的不足”。一点也不——我的奇特工具是建立在语言效率之上的。如果语言没有让工具存在成为可能，工具就不会存在。在我看来，允许构建强大工具的语言就是强大的语言，这就是静态类型语言的优势。