The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
В 1974 году Лисков и Зиллес определили строго типизированный язык как такой, в котором “каждый раз, когда объект передается из вызывающей функции вызываемой функции, его тип должен быть совместим с объявленным типом в вызываемой функции.” Строгая проверка типов без сомнения снижает количество типовых ошибок, что ведет к повышению качества. Однако вопрос заключается в следующем: действительно ли нам нужны типы для строгого обеспечения типизации?
Например, это место, где мы ожидаем поступление экземпляра Java интерфейса Book:
Тип Book может выглядеть так:
Если в метод print() передается объект, который не реализует интерфейс Book, компилятор выдаст ошибку “несоответствие типов”. Программисту будет трудно допустить ошибку и передать объект типа, скажем, Car, в метод print(). Однако, это все еще будет возможно с помощью динамического приведения типов.
Этот код будет успешно скомпилирован, но при выполнении будет сгенерировано исключение ClassCastException, так как невозможно будет выполнить приведение типа Car к типу Book.
Преимущество сильной типизации заключается в том, что она предотвращает ошибки. Однако она усложняет кодирование: вам нужно сначала создавать типы, объявлять их во всех ваших функциях, выполнять приведение типов, что сложно отлаживать, и так далее. Приверженцы слабой типизации жалуются на это много и создают языки, такие как Ruby, которые вообще не имеют типов, например:
Здесь функция print() не требует, чтобы b имела какой-либо конкретный тип. Что бы ни поступило на вход - все в порядке. Позже, когда приходит время вызывать .isbn, время выполнения проверяет, имеет ли входящий b такой метод. Если да, то все работает нормально, если нет, возникает ошибка времени выполнения NoMethodError.
Однако, вот идея: а что, если мы объединим простоту и краткость динамической типизации с безопасностью сильной типизации, избавившись от типов полностью и позволив компилятору выводить информацию о типе из кода, который работает с объектами? Вот наш код еще раз:
Подумайте об этом: на этапе компиляции уже ясно, что b должен иметь как минимум один метод isbn(). Нет необходимости заставлять программистов явно определять тип Book и упоминать в сигнатуре метода print(), что только книги приветствуются: эта информация может легко быть выведена из тела метода print()! Компилятор может просмотреть все операторы в методе print() и ясно понять, что именно будет сделано с объектом b. Этой информации должно быть достаточно для визуализации “типа” входящего объекта. Нет необходимости просить программиста делать это явно и тратить еще пять строк кода в новом файле на объявление типа Book. Компилятор вместе с IDE может выполнить эту работу за нас.
Конечно, чтобы это работало, мы должны запретить любое приведение типов, что невозможно в Java, C++, C# и других псевдо-объектно-ориентированных языках. Но это возможно в EO!
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-18 at 05:26
