Краткий ответ: нет, потому что эквивалентность по Тьюрингу.
Длинный ответ: этот парень тролль. Хотя системы типов «ограничивают вас подмножеством», это правда, но вещи вне этого подмножества, по определению, не работают.
Все, что вы можете сделать на любом языке программирования с полным набором Тьюринга (это язык, предназначенный для программирования общего назначения, а также множество других, которые этого не делают; это довольно низкая планка, которую можно очистить, и есть несколько примеров превращения системы в систему Тьюринга). завершить непреднамеренно) вы можете сделать на любом другом языке программирования полного Тьюринга. Это называется «эквивалентностью по Тьюрингу», и это означает только то, что говорится. Важно отметить, что это не означает, что вы можете так же легко выполнить другую вещь на другом языке - некоторые утверждают, что в этом и заключается весь смысл создания нового языка программирования: чтобы дать вам лучший способ выполнения определенных действий. вещи, которые сосут существующие языки.
Например, динамическую систему типов можно эмулировать поверх статической системы типов ОО, просто объявив все переменные, параметры и возвращаемые значения в качестве базового Object
типа, а затем используя отражение для доступа к конкретным данным внутри, поэтому, когда вы это поймете, вы видите, что буквально ничего нельзя сделать на динамическом языке, чего нельзя сделать на статическом языке. Но делать это таким образом было бы большим беспорядком, конечно.
Парень из цитаты прав, что статические типы ограничивают то, что вы можете сделать, но это важная особенность, а не проблема. Линии на дороге ограничивают то, что вы можете делать в своей машине, но считаете ли вы их ограничительными или полезными? (Я знаю, что не хотел бы ездить по оживленной, сложной дороге, где ничто не говорит машинам, едущим в противоположном направлении, чтобы держаться на своей стороне и не подходить туда, куда я еду!) Установив правила, четко определяющие, что Принимая во внимание недопустимое поведение и предотвращая его, вы значительно уменьшаете вероятность неприятного сбоя.
Кроме того, он искажает другую сторону. Дело не в том, что «все интересные программы, которые вы хотите написать, будут работать как типы», а скорее «все интересные программы, которые вы хотите написать, будут нуждаться в типах». Когда вы выходите за пределы определенного уровня сложности, становится очень трудно поддерживать базу кода без системы типов, чтобы держать вас в курсе, по двум причинам.
Во-первых, потому что код без аннотаций типов трудно читать. Рассмотрим следующий Python:
def sendData(self, value):
self.connection.send(serialize(value.someProperty))
Как вы ожидаете, как будут выглядеть данные, полученные системой на другом конце соединения? И если он получает что-то, что выглядит совершенно не так, как вы узнаете, что происходит?
Все зависит от структуры value.someProperty
. Но как это выглядит? Хороший вопрос! Что звонит sendData()
? Что это проходит? Как выглядит эта переменная? Откуда это? Если это не локально, вы должны проследить всю историю, value
чтобы отследить, что происходит. Может быть, вы передаете что-то еще, что также имеет someProperty
свойство, но оно не делает то, что вы думаете, что делает?
Теперь давайте посмотрим на это с помощью аннотаций типов, как вы могли бы видеть в языке Boo, который использует очень похожий синтаксис, но статически типизирован:
def SendData(value as MyDataType):
self.Connection.Send(Serialize(value.SomeProperty))
Если что-то идет не так, внезапно ваша работа по отладке стала на порядок проще: посмотрите определение MyDataType
! Кроме того, вероятность получить плохое поведение, потому что вы передали какой-то несовместимый тип, который также имеет свойство с тем же именем, внезапно сводится к нулю, потому что система типов не позволит вам совершить эту ошибку.
Вторая причина основана на первой: в большом и сложном проекте у вас, скорее всего, есть несколько участников. (А если нет, то вы создаете его самостоятельно в течение длительного времени, что, по сути, одно и то же. Попробуйте прочитать код, написанный 3 года назад, если не верите мне!) Это означает, что вы не знаете, что было проходя через голову человека, который написал почти любую конкретную часть кода в то время, когда они его написали, потому что вас там не было или вы не помните, был ли это ваш собственный код давным-давно. Наличие объявлений типов действительно помогает вам понять, каково было намерение кода!
Такие люди, как парень в цитате, часто неверно характеризуют преимущества статической типизации как «помощь компилятору» или «все в отношении эффективности» в мире, где почти неограниченные аппаратные ресурсы делают это все менее и менее актуальным с каждым годом. Но, как я показал, хотя эти преимущества, безусловно, существуют, основное преимущество заключается в человеческих факторах, в частности, в удобочитаемости кода и его поддержке. (Тем не менее, дополнительная эффективность, безусловно, хороший бонус!)