Statistics 比较静态类型代码和动态类型代码-成本和收益

无论其优点是什么，Adobe的Actionscript 3都为探索类型化语言与非类型化语言的区别提供了一个独特的机会，因为它几乎是javascript的一个严格超集，具有严格类型声明、声明式转换等的所有语法优势/开销

这使得比较两种方式编写的相同代码成为可能，同时分解出基本的语言语法

这让我想知道，是否有任何定量证据表明，在错误率、编程效率和代码量方面，强类型的真正好处，特别是在编译期间的错误检查方面；还是我们的观点完全基于猜测和猜测？还有其他语言可以同时使用吗（不包括老式的VB——无论哪种方式都不是一种受人尊敬的语言。）

---

我花了大量时间学习这两种语言，但还没有最终决定我更喜欢哪种方式，而且我不想添加轶事证据——我在寻找客观信息。

在我看来，像C#这样的强类型语言可以在编译时识别许多被忽略的错误，这些错误不会被松散类型的语言捕获，因此会在以后导致运行时错误。

---

我不认为这仅仅是一种推测，因为严格的编译可以预测在运行时可能导致错误的问题。这可能会消除您在实现过程中忽略的大多数编码错误，但编译器很容易发现并修复这些错误。

这是编程中的一场伟大的宗教战争，可能只有真正的编辑器EMACS与邪恶的撒旦vi之子之间的冲突才能超越这场战争

基本上，如果用动态语言编写的程序是正确的，那么它可以转换为静态类型的语言，并且仍然是正确的，反之亦然。真正的静态类型语言的优点是，在动态语言的运行时出现的bug可以在静态类型语言的编译时识别出来

然而，在这些情况下经常被忽略的是，静态类型的语言通常具有转义图案填充（如类型转换），而显然是动态的语言可以使用类型推理来推断显然是动态的表达式的类型，并将其视为静态类型

---

在幕后，真正重要的是程序员。如果程序员认为程序是正确的，那么它在静态或动态语言中都是正确的。我不知道有什么好的实验证据表明，在实践中，任何一个都更有效率或更容易出错。

如果你像我一样相信，除非你有测试证明某个软件是正确的，否则你不能说它是正确的，那么静态键入的价值对我来说似乎非常有限。如果您接受并实践了这一点，那么无论是在编译时还是在测试时识别bug，这在很大程度上都是无关紧要的

在这一点上，我宁愿使用这两种语言中更简洁的一种，根据我的经验，这两种语言都是动态语言

---

另一方面，静态类型只有在您不编写测试时才真正帮助您。如果是这样，静态输入可能不足以确保软件的正常运行

OP和felipecsl在谈论打字规则时，对所使用的术语感到困惑

静态类型表示在编译时检查类型（无论编译时在语言中是什么意思）。 动态类型表示在执行表达式/语句时检查类型。 例如，强类型意味着您不能将指针转换为整数。 弱类型与强类型相反

据我所知，没有“严格的打字”

---

现在让其他人来回答实际问题；-）

统计类型语言。将其变量和表达式作为固定类型，由程序员明确说明或由程序员推断。编译器正在使用此。信息，这里的类型检查将在编译时执行。虽然动态类型的lang的值是固定的，但变量和xxpressions并不是固定的。由于计算操作数时，可能会返回不同的值，然后在计算操作数之后执行类型检查。即，在计算之后但在运行时执行操作之前，弱类型需要更多的维护时间。随着程序变得越来越复杂，由于没有编译器来处理明显的问题，会出现更多的问题。不建议用于大型复杂项目。我是凭经验说的。

是的，它可以做到这一点，而且当它发生时，它是有价值的。问题在于是否有可能，是否已经进行了测量，以发现这有多大的好处，以及成本是什么。（我不知道我是否一定同意我们忽略的大多数错误都是类型检查错误）。它们也（我发现）迫使程序员有不同的思维方式。在javascript中，我更加简洁和轻量级；在Actionscript中，我更加详尽。如果我们要通过宗教战争，我希望有人，某个地方，可能真的在收集可比的统计数据。这意味着我不认为这只是个人偏好，这真的没有什么区别。应该有办法将相同的任务分配给两组随机分配的技能相似的人，一种或另一种，然后看看会发生什么。然后切换。（例如）我在理论上同意你的观点，但是做这种精心设计的实验是非常困难的，而且代价高昂。例如，你不能像你建议的那样比较各组，因为这不能说明学习的重要性