Думаю, на статью это не потянет, но напишу комментом. Некоторых людей Свифт отпугивает потому что на WWDC Apple заявляла, что он полностью готов, с полной поддержкой Икскодом и что работает быстрее. Но на практике пока немного иначе.
Цитата одного знакомого:
Почему они не сказали, что они разрабатывают новый язык разработки с крутыми плюшками, с которыми можно уже поиграться, но работы еще ведутся. А плейграунд вообще какая-то чепуха для тех, кто любит программировать методом подбора, пальцем в небо писать код пока не получится так, как нужно. Повалит теперь куча народу, для джунов учить будет просто, а «бывалым» придется отвыкать от обджектива! Больше народу — меньше рейт.
А как быть с C/C++ либами, писать эти чертовы враперы. И вообще, все эти нововведения можно было бы вынести в Objective-C 3.0, а не писать новый язык!"
Если вам показалось, что статья предназначена сказать, что «свифт плохой», то это не так. Он действительно мощный. Некоторые мои знакомые решили уйти из iOS разработки в другие сферы, я же буду переходить на свифт. И статья наверное даже призвана показать, что свифт не готов пока, но все проблемы вышеперечисленные обязательно решаться.
Я понял, что Вы — фанат Swift. И я тоже, в принципе, вижу в нем мощный инструмент для разработки iOS приложений. Много раз сталкивался с людьми (сейлз менеджерами, проджект менеджерами или студентами, которые только начинают путь программиста и пытаются понять с чего начать) которые думали, что все, теперь все пишут только на свифте.
Статья рассчитана на подавляющую массу людей, которые немного знакомы с программированием или с IT в целом, но не знаю тонкостей.
Я вижу, что Вы на Хабре 6 лет, а в IT наверное еще дольше, и имеете большой опыт! Но нельзя писать статьи только для людей такого же уровня, как и Вы. Поверьте, я был по этой ссылке, которую вы скинули, я видел эти результаты, я повторял эти тесты у себя, но я не хотел делать идентичный пост тому комментарию на stackoverflow, который был по ссылке.
И да, график, как мне кажется, вполне дает понять, что он показывает скорость загрузки контроллера (или для не знающего человека просто «скорость загрузки чего-то») написанного на Objective-C и на Swift. Видно, что «синяя полоска ниже», значит в Objective-C это «что-то» (контроллер) пока грузится быстрее, к тому же между перезапусками она меньше варьируется, чем на Swift. И я думаю, что каждый, кто зашел на Хабр и ему показалось интересной статья на столько, что он дочитал до момента с графиком, то он понял, что я хотел показать этим графиком. И я не призываю «гнобить» Swift, я призываю его учить, но понимать, что он и Xcode пока не совершенны.
А чуть худшая скорость запуска приложения с нуля до отображения вьюшки вызвана как минимум необходимостью проинициализировать еще и стандартную библиотеку Swift.
Цитата из статьи:
Время будем засекать с момента полной загрузки приложения до момента отображения первого контроллера.
т.е. время на загрузку фреймворков, библиотек и т.д. не учитывается, засекается время загрузки контроллера
Написали только о проблемах.
Но эти проблемы настолько очевидны, что их можно было бы и не рассматривать. Ведь язык только появился, и IDE с компилятором еще в бете.
В чем посыл статьи? В том, что swift еще нельзя использовать для написания продакшн кода?
Это и так понятно для любого, кто даже попробует просто поиграться со Swift.
Да, на то статья и называется «Swift: проблемы и перспективы». Мы уточнили, что большинство этих проблем носят временный характер и будут устранены. И сделали заключение о том, что переход на Swift будет длится года 2.
Лучше бы написали о новых фичах (кортежи, дженерики, IBInspectable/IBDesignable, ...)
Напишем, в будущем, к тому же IBInspectable/IBDesignable являются нововведениями не языка, а среды разработки Xcode и работают как с использованием Swift, так и c Objective-C.
Ну и тесты некорректны так как не описаны флаги компиляции (см. stackoverflow.com/questions/24101718/swift-performance-sorting-arrays)
Флаги компиляции -Ofast в обеих случаях (Objective-C и Swift). Не приведены они, потому что в части, где анализируется проблема инкремента в Swift, мы не сравниваем его с Objective-C, т.к. в первом случае мы работаем со структурой (в Swift даже Int — структура ), а во втором — с простым типом.
А тест на скоростью загрузки контроллера не «нагромождаем» дополнительными деталями, чтобы проиллюстрировать лишь обобщенную информацию в ситуации, приближенной к реальной. В данном случае мы не гонимся за скоростью выполнения циклов, сортировок и т.д., а просто показываем в удобном для человека виде (графиком) информацию.
Полноценное сравнение производительности вполне потянет на отдельную статью. Мы же хотели написать кратко, причем в стиле, который будет понятным даже не очень техническому человеку, например, потенциальному заказчику. И хотели показать, что на деле Swift еще сыроват, потому что уже поступают предложения от клиентов писать на Swift.
А почему у вас примеры кода то картинками, то текстом?
Некоторые блоки кода сделаны картинкой, чтобы в точности передать стиль кода такой, каким его можно видеть в Xcode, с учетом всех отступов, табуляций, подсветки т.д. К тому же, Хабр пока не умеет подсвечивать Swift.
Разве ж это необходимо? Всегда думал, что это лишь для удобства программиста и IDE — разделение между публичными и приватными свойствами и методами класса заключаются не в расширении файла, а определяются соответствующими ключевыми словами (interface, interface (), @implementation), и писать можно как хочешь, хоть весь проект в один файл с любым расширением.
Вы правы, можно хоть в один файл, но «по фен-шую» необходимо разделять на *.h и *.m
Допустим, Вы далеете фреймворк, защищенный авторскими правами, и пишите реализацию класса в хедер файле. Логично ли это?
Поэтому, говоря о необходимости создавать файлы *.h и *.m с интерфейсом и реализацией соответственно, имеется ввиду не отсутствие возможности сделать иначе, а подразумевается, что так делать правильно.
Статья рассчитана на подавляющую массу людей, которые немного знакомы с программированием или с IT в целом, но не знаю тонкостей.
Я вижу, что Вы на Хабре 6 лет, а в IT наверное еще дольше, и имеете большой опыт! Но нельзя писать статьи только для людей такого же уровня, как и Вы. Поверьте, я был по этой ссылке, которую вы скинули, я видел эти результаты, я повторял эти тесты у себя, но я не хотел делать идентичный пост тому комментарию на stackoverflow, который был по ссылке.
И да, график, как мне кажется, вполне дает понять, что он показывает скорость загрузки контроллера (или для не знающего человека просто «скорость загрузки чего-то») написанного на Objective-C и на Swift. Видно, что «синяя полоска ниже», значит в Objective-C это «что-то» (контроллер) пока грузится быстрее, к тому же между перезапусками она меньше варьируется, чем на Swift. И я думаю, что каждый, кто зашел на Хабр и ему показалось интересной статья на столько, что он дочитал до момента с графиком, то он понял, что я хотел показать этим графиком. И я не призываю «гнобить» Swift, я призываю его учить, но понимать, что он и Xcode пока не совершенны.
Цитата из статьи:
т.е. время на загрузку фреймворков, библиотек и т.д. не учитывается, засекается время загрузки контроллера
По ошибке…
Да, на то статья и называется «Swift: проблемы и перспективы». Мы уточнили, что большинство этих проблем носят временный характер и будут устранены. И сделали заключение о том, что переход на Swift будет длится года 2.
Напишем, в будущем, к тому же IBInspectable/IBDesignable являются нововведениями не языка, а среды разработки Xcode и работают как с использованием Swift, так и c Objective-C.
Флаги компиляции -Ofast в обеих случаях (Objective-C и Swift). Не приведены они, потому что в части, где анализируется проблема инкремента в Swift, мы не сравниваем его с Objective-C, т.к. в первом случае мы работаем со структурой (в Swift даже Int — структура ), а во втором — с простым типом.
А тест на скоростью загрузки контроллера не «нагромождаем» дополнительными деталями, чтобы проиллюстрировать лишь обобщенную информацию в ситуации, приближенной к реальной. В данном случае мы не гонимся за скоростью выполнения циклов, сортировок и т.д., а просто показываем в удобном для человека виде (графиком) информацию.
Полноценное сравнение производительности вполне потянет на отдельную статью. Мы же хотели написать кратко, причем в стиле, который будет понятным даже не очень техническому человеку, например, потенциальному заказчику. И хотели показать, что на деле Swift еще сыроват, потому что уже поступают предложения от клиентов писать на Swift.
Некоторые блоки кода сделаны картинкой, чтобы в точности передать стиль кода такой, каким его можно видеть в Xcode, с учетом всех отступов, табуляций, подсветки т.д. К тому же, Хабр пока не умеет подсвечивать Swift.
Вы правы, можно хоть в один файл, но «по фен-шую» необходимо разделять на *.h и *.m
Допустим, Вы далеете фреймворк, защищенный авторскими правами, и пишите реализацию класса в хедер файле. Логично ли это?
Поэтому, говоря о необходимости создавать файлы *.h и *.m с интерфейсом и реализацией соответственно, имеется ввиду не отсутствие возможности сделать иначе, а подразумевается, что так делать правильно.