在他的岗了这个想法，静态(或强)类型语言不会给你带来太多，因为无论如何你都应该用测试来验证你的程序，这些测试也会检查类型——不需要编译器这样做(特别是当它使你对语言的生产力降低的时候)。
虽然这看起来是一个非常好的观点，但我有一些反对意见。
首先，他的术语不是普遍认同的术语态类型(在编译时检查类型)与强类型(没有或很少隐式类型转换)之间的区别。为了澄清本文中使用的语言——Python是动态的强类型语言。
但是我们不要对术语吹毛求疵。我反对静态类型只是给你一些额外的测试，无论如何你都应该写。
在一个用动态语言写的项目中，你能看到一个方法的调用者吗？在他的例子中谁调用了speak方法？你会去搜查吗？嗯，如果你有很多同名的方法(iterator(), calculate(), handle(), execute())?也许你会给它们起不同的名字？并且确保你永远不会在整个项目中重复使用一个方法名。就生产力而言，快速浏览大项目代码的能力是最重要的能力之一。这并不是说带有优秀插件的vim不允许你浏览类和搜索方法——只是不可能在动态语言中做到像在静态语言中那样精确。
然后我想知道在给定的对象上可以调用什么。在我写代码的时候做API“发现”。在一个大项目中，你有多少次绝对确定要对第一次看到的类的对象调用哪个方法？去那个班？哦，是哪一个，因为你只知道它有calculate()方法(当前方法中调用的方法)？编写一个测试来验证您是否可以调用一个给定的方法是可以的，但是不能让您发现在那个时候您有什么选择——什么方法最适合您。下面是自动完成内联文档。这不是为了节省击键次数，而是为了知道在代码的这一点上什么是允许的。我猜不断地打开API文档页面或其他类定义是可行的，但这很乏味。
然后是重构。是的，你知道我会提起的。但这是我们编写的测试让我们能够使用的最重要的特性。我们有所有的测试，这样我们可以保证当我们改变一些东西时，代码将继续正确工作。然而，只有在静态类型语言中，才有可能进行全功能的重构。向一个方法添加参数，将一个方法移动到另一个类，甚至重新命名一个方法，而没有附带的损害。是的，在Ruby或Python中，有多种试探法可以让重构变得可能(JetBrains正在尝试)，但从定义上来说，它不可能那么好。有关系吗？即使它不会自动发生，测试也会发现，对吗？如果你有100%的保险，他们会的。但这并不意味着做改变需要更少的时间。与静态语言的几次击键相反。
那些“神话般的大项目”是什么，上面的所有特性都是游戏规则的改变者？嗯，根据我的经验，大多数项目的生命周期超过6个月。
所以，不，静态类型不是关于类型检查的。它是关于你能够更快地理解一个庞大的、不熟悉的(或被遗忘的)代码库，并且有更高的确定性，以你的方式理解它，并且更安全更快速地改变它。不过，类型检查是一个便利的好处。我不会采用“静态类型语言运行时间更快”的论点。(尽管我非常喜欢静态和强类型，但我并不打算放弃动态类型语言)
然后人们可能会说“你的花哨工具和ide试图弥补语言的不足”。一点也不——我的奇特工具是建立在语言效率之上的。如果语言没有让工具存在成为可能，工具就不会存在。在我看来，允许构建强大工具的语言就是强大的语言，这就是静态类型语言的优势。
标签：调用,语言,检查,静态,测试,类型,方法 来源： https://www.cnblogs.com/aisinila/p/16251888.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。