The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
1974年，Liskov和Zilles将一种强类型语言定义为”每当一个对象从调用函数传递给被调用函数时，其类型必须与被调用函数中声明的类型兼容”。毫无疑问，强类型检查减少了类型错误的数量，从而提高了质量。然而，问题是：为了强制执行类型，我们真的需要类型吗？
例如，这是一个我们期望接收Java 接口 Book实例的地方：
类型Book可能看起来像这样：
如果将一个不实现Book接口的对象传递给print()方法，编译器将报告“类型不匹配”错误。程序员很难犯一个错误，将一个类型为Car的对象传递给print()方法。然而，通过动态类型转换仍然是可能的。
这段代码在编译时不会有问题，但在运行时会抛出 ClassCastException，因为无法将 Car 强制转换为 Book。
强类型的美妙之处在于它可以防止错误。然而，它增加了代码的复杂性：你需要首先创建类型，需要在所有函数中声明它们，需要类型转换，这很难调试，等等。弱类型的支持者对此有很多抱怨，并创建了像 Ruby 这样根本没有类型的语言。
在这里，函数print()不期望b具有任何特定类型。无论输入什么都可以。稍后，在调用.isbn的时候，运行时会检查传入的b是否有这样的方法。如果有，一切都正常，如果没有，则会引发运行时错误NoMethodError。
然而，这里的想法是：如果我们将动态类型的简洁和简洁性与强类型的安全性相结合，通过完全摒弃类型并让编译器从与对象一起使用的代码中推断类型信息，会怎么样？再次展示我们的代码：
思考一下：在编译时，很明显b必须至少有一个isbn()方法。无需强制程序员明确定义类型Book并在print()方法的签名中提到只接受书籍：这个知识可以轻松从print()方法的主体中推断出来！编译器可以查看print()方法中的所有语句，并清楚地理解将使用对象b来做什么。这些信息应该足以可视化传入对象的“类型”。无需要求程序员显式执行此操作，并在新文件中再花费五行代码声明类型Book。编译器和集成开发环境可以为我们完成这项工作。
当然，为了使这个工作起效，我们必须禁止任何类型的类型转换，这在Java、C++、C#和其他伪面向对象的语言中是不可能的。但在EO中是可能的！
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-18 at 05:25
