Сегодня утром я наткнулся на этот пост в блоге Брента Симмонса и обнаружил, что категорически не согласен с некоторыми из того, что написал Брент, что случается нечасто.
Он говорит:
Возможно, Swift быстрее, чем Objective-C, или будет быстрее. Но это тоже не имеет значения.
Я полностью согласен.
Но производительность — это лишь часть ценности Swift. Самое большое преимущество Swift (во всяком случае, на мой взгляд) — это правильность. Мир, в котором вы могли бы доказать, что программа верна, был бы намного лучше, чем тот, в котором мы находимся сейчас. Мы далеки от этого в этой отрасли, но каждый шаг, который мы делаем в этом направлении, — это шаг в правильном направлении. Swift — один из таких шагов. Если вы пишете идиоматическую 1 программу на Swift, которая компилируется, вы гораздо более уверены в ее правильности, чем аналогичная программа на Objective-C.
Да, я понимаю, что это означало бы перенести некоторые ошибки из времени компиляции во время выполнения точно так же, как это делает сейчас Objective-C.
Но мне все равно — я бы пошел на этот компромисс каждый день недели.
Это компромисс, на который я бы очень редко пошел. Обнаружение ошибок во время компиляции — это огромный выигрыш. Теперь писать на Swift немного громоздче, чем на Python 2? Абсолютно!
Однако, по моему опыту, очень сложно поддерживать даже умеренно большой проект на Python командой людей. В большинстве нетривиальных проектов Python, которые я видел, есть смехотворное количество модульных тестов для проверки таких вещей, как безопасность типов и в любом случае допустимость значений NULL. Без этих модульных тестов легко непреднамеренно допустить ошибки и не обнаружить их. Вместо того, чтобы писать все эти модульные тесты вручную, вы могли бы немного помочь компилятору и устранить эти классы ошибок без дополнительных усилий.
в Swift мне иногда кажется, что я заполняю форму в трех экземплярах, прежде чем смогу использовать переменную, или отправляю факсы различным руководителям отделов, прежде чем смогу вызвать метод.
Я прощу гиперболу и вместо этого спрошу: Swift иногда более многословен, чем должен быть? Конечно. Однако я уверен, что со временем это будет исправлено. Однако в этом есть обратная сторона. Мы пишем на языках программирования высокого уровня, а не на ассемблере, по одной причине: мы пишем код, предназначенный для чтения другими людьми, а не только машинами. Если язык программирования может помочь более четко передать намерения исходного программиста тем, кто последует за ним, я только за. Я не мог сосчитать, сколько раз мне приходилось спрашивать себя, могу ли я безопасно установить значение None при написании Python. Каждый раз, когда я это делаю, я должен проверить это, чтобы быть уверенным. В Swift ответ на этот вопрос сразу очевиден.
Мы также отказались от простоты (предполагая, что вы знаете C, а вы должны его знать, часть «Цель» довольно мала) в пользу гораздо более сложного языка.
В этом он абсолютно прав, и с этим не поспоришь. Swift намного сложнее, чем C, и имеет гораздо большую площадь поверхности. Выучить весь Swift намного сложнее, чем весь C. Однако вам не нужно знать весь Swift, чтобы извлечь из него пользу. Например, вы можете извлечь выгоду из Swift, даже если не понимаете сопоставление с образцом, что такое PAT или как он работает. Я также надеюсь, что с лучшим образованием (как от Apple, так и от сообщества) это станет меньшей проблемой с течением времени.
Первоначально опубликовано на сайте gopalkri.com 24 апреля 2016 г.
