Комментарии 86
А пока что статья тянет на жалобу+опрос.
Начнем с того, что буквально два года назад мобильная разработка под iOS приобрела свой неповторимый вкус, и это связано с появлением такого языка как Swift
Два года назад? Автор статьи новичок или опытный???
В текущей ситуации можно разве что спрашивать еще и по Objective-C. Если новичок потратил время на немодный, но лежащий в основе, язык, то скорее всего он чуть больше чем формошлепер.
Open-source Swift can be used on Linux to build Swift libraries and applications. The open-source binary builds provide the Swift compiler and standard library, Swift REPL and debugger (LLDB), and the core libraries, so one can jump right in to Swift development.
Просто на остальных платформах языку приходится конкурировать с очень сильными языками (напр. Rust).
Под изоляцией я имею ввиду скорее скудность учебного материала. Есть ряд простых задач (отправить запрос на сервер, сохранить в базу, отобразить), есть уроки как это сделать. Пояснений как работают запросы/БД/UI нет. Нет банды четырех или чистого когда на Swift. Соответственно новичок посмотрит пару уроков и решит что язык он знает, можно идти загребать деньги лопатой.
Я бы разделил вопрос на 2 части:
- как писать хороший код на Swift?
- как работает Foundation и UIKit?
На второй вопрос можно получить достаточно много ответов, если не пугаться того же самого ObjC (см. старые публикации на objc.io). Вдобавок тот же самый AppCoda начал недавно серию публикаций по нетривиальным аспектам разработки под iOS.
Если под "чистым кодом" мы понимаем одно и то же, то есть VIP, VIPER, Clean Swift и пр.
Не стал об этом писать отдельный комментарий — видимо зря. Абсолютно согласен на счет "даже если знания присутствуют". Все кроме POP — это далеко не уникальные особенности Swift и соискатель может спокойно выехать на своих знаниях из JavaScript, C/C++ и прочих ЯП.
Хотя и для POP более грамотные коллеги наверняка смогут привести аналогии из других ЯП.
В целом конечно хочется, чтобы на Хабре были качественные статьи по Swift (хотя бы уровня objc.io).
Из ObjC нам достались такие легаси как NSObject
, NSString
, CoreData
и @objc
. К сожалению, писать на чистом Swift под iOS — это фантастика.
Пример: автогенерация классов для CoreData принуждает работать с NSSet
для one-to-many связей. Можно ли использовать при ручном описании классов Set
вместо NSSet
? Что делать если мы хотим получить ordered set? Какова вычислительная сложность при преобразовании NSSet
и Set
между собой?
Если бы МС или Оракл позволяли себе такие breaking changes их бы извиняюсь за выражение с г… ном сожрали, а эпл бои это прощают эплу раз за разом.
Стокгольмский синдром? вот и вы их оправдываете, а меж тем язык ломается каждый год, рефакторинг в IDE не работал до 4 версии, горбатое полуживое IDE у которого отваливается кодокомплит, горбатый debugger который не всегда выводил обьекты (ну к 4 версии вроде научился), баги которые не правятся годами(нет нет да напарываюсь на радары 3-4 летней давности) и тд.
Я понимаю что если формокнопошлепить цветастые морды к API наверное вы не столкнетесь с этим, но уверяю вас как платформа это горящая куча мусора.
любой из существующих уже языков(от Go до C#) и официально 'портировать'
Портировать языки со сборщиком мусора на мобильные платформы? Получился бы ещё один тормозной андроид.
эпл бои это прощают эплу раз за разом
Эмм, ну как-бы сразу предупреждали, что до определённой версии язык ещё в разработке. Это лучше, чем вставлять костыли, да и ObjC есть — для тех, кому нужна стабильность.
Xcode 4й версии
Кстати уже с тех пор 8 лет прошло — вы что критикуете-то?))
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Ад и израиль что в 2к18 мы должны помогать тупенькому компилятору от никому не известной фирмы с купертино — компилировать код.
github.com/apple/swift-evolution/tree/master/proposals
Что вам мешает просто не писать на Swift? Вас держат в застенках и заставляют кодить под iOS? Подмигните, скиньте адрес — мы вызовем полицию для вас.
ObjC отличный язык, но он избыточный на данный момент. Он существует как очень стабильное легаси и это хорошо.
Кто хочет "новых проблем" тот выбирает для себя Swift.
Убер говорит что у них половина iOS девов заняты тем что симплифицируют код чтобы ускорить компиляцию.
Половина из скольки? Почему они это делают?
Авито публикуют доклады где они сливают вместе все класс екстешны чтобы снова ускорить компиляцию.
Авито молодцы — очень интересно изучать как они прошлись по всем этим граблям и нарисовали относительно безопасную карту для остальных.
Почему Apple не взяли чужой ЯП? По той же самой причине по которой появились процессоры А*, почему появился Metal и все прочее — тотальный контроль за экосистемой.
Вспомните времена IE и JScript — оно вам нужно?
Половина из скольки? Почему они это делают?
Половина из примерно сотни девелоперов, делают это для ускорения процесса сборки они провайдят сотни билдов ежедневно, почему они так делают я не в курсе.
тотальный контроль за экосистемой.
Вспомните времена IE и JScript — оно вам нужно?
у вас сбитая логическая база, в мире эпл мы УЖЕ как раз и имеем такую же огороженность как во времена раннего IE.
Вот именно тот доклад убера www.skilled.io/u/swiftsummit/swift-with-a-hundred-engineers — радуют еще их сказки про 99.99% креш фри после переписывания на свифт, откуда такие сказки если креш/ассерт можно словить просто просто в глубинах фаундейшна не зависимо от языка, как на одной иос бетке я ловил креш потому что internal iOS логгер процессил мои объекты для своих каких то внутренних целей (видимо сбор статистики), и крешился на этом.
Если же свифт помог им добиться такого креш-фри то это было просто сборище смуззихлёбов не умеющих в обжект с его nil безопасной семантикой.
полностью безотказный nil в objc — это явная недоработка старого языка
это в общем то специально сделанная фича если изучить рантайм который заботливо выделяет именно столько места на стеке сколько ожидается от выражения например
someStruct zero = [nil structValue];
Работающий и необработанный nil — unexpected behaviour.
да я понял что вы любите крашится и писать guard let'ы обильно и много
Авито молодцы — очень интересно изучать как они прошлись по всем этим граблям и нарисовали относительно безопасную карту для остальных.
непонятно почему вообще компилятор настолько убогий, я не видел подобных решений для java или c#, косвенно это также говорит о качестве компилятора и его разработчиках.
Костыли и подпорки потому что маленькая никому не известная купертиновская компания не может разработать вменяемые инструменты разработки.
ну то есть к пятой
версии мы по хорошему получаем функционал 1.0
Из вики:
Swift: first appeared in 2014
Go: first appeared in 2009
Go как-бы пилят уже в два раза дольше, в 2013 о нём вообще мало кто слышал. Вы хотите, чтобы в Swift было всё и сразу? Кстати проблемы со временем компиляции до сих пор не преодолели даже в таком молодом и малоизвестном языке, как C++.
я не видел подобных решений для java или c#
Да, давайте теперь ещё сравним компиляцию в нейтив-код и компиляцию в байт-код.
По поводу Go, а не подскажите сколько там было breaking changes?
Может сравним размер и капитализацию компаний разработчиков?
Или может сравним число девелоперов в командах?
Или вы просто уклонитесь от этих неудобных вопросов и будете дальше фанбоить по эплу?:)
Ну и попробуйте найти статьи(от крупных компаний) по ускорению времени компиляции в плюсах(да черт возьми, даю вам фору — на вообще ЛЮБОМ языке кроме свифта) связанные тупо с симплификацией обычного кода(не с темплейтами).
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
Отличия байт-кода LLVM от байт-кода JVM или MS IL себе представляем? Ну это так, вопрос на общую адекватность.
а не подскажите сколько там было breaking changes
Не подскажу. До первой версии явно были.
сравним размер и капитализацию компаний разработчиков
Дело не в капитализации, а выделенном бюджете. У вас есть такие данные? Да и задачи там стояли разные: что-то Google даже не попытался вписать Go в инфраструктуру Android, просто разработал очередной язык в вакууме даже без UI библиотек.
Возможно для вас будет новостью, но C++ ускорению компиляции не очень-то и поддаётся by design.
толпы фанбоев без бекграунда — пытаются разрабатывать софт
Все так начинали.
Отличия байт-кода LLVM от байт-кода JVM или MS IL себе представляем?
интересно а вы представляете? и как вы думаете во что интересно сложнее компилить если имеется такой замечательный инструмет как GraalVM ;)
Не подскажу. До первой версии явно были.
ДО первой версии, не так ли? не между КАЖДОЙ, не так ли?
Возможно для вас будет новостью, но C++ ускорению компиляции не очень-то и поддаётся by design.
не будет, но для меня будет новостью если вы найдете статьи по ускорению компиляции плюсов симплифицированием кода. Да бог с ними с плюсами — на ЛЮБОМ другом языке кроме свифта. Сможете же? Или проигнорите во второй раз?
Все так начинали.
нормальные начинания начинались в академической среде а не среди смуззихлебов которые написать компилятор пятый год не могут.
По поводу breaking changes тоже много шуму на ровном месте — было сильно больше изменение между первой и второй версией языка, дальше — никаких проблем. Хватало 1 рабочего дня и 1 разработчика перевести большой проект на свифт 3, потом тот же проект на 4ю версию был переведен за час. Больше проблем доставляют не изменения языка, а изменения SDK, просто получается что язык и сдк обновляются в один момент (релиз новой оси). К следующей версии сделают ABI к тому же.
Кстати, не понимаю проблемы с версиями, у C++ например вообще по годам выпуска версии.
Проблемы «симплификации» как ее тут назвали преувеличены.
'проблема' в том что это вообще существует, все эти статьи и доклады по настройками компилятора (sic) и тому как смержить все файлы в кучу чтобы немощный компилятор быстрее проанализировал один большой файл чем кучку маленьких.
дальше — никаких проблем.
у ВАС не было, у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проект, а потом кому то приходится засучив рукава работать после таких 'работников'.
К следующей версии сделают ABI к тому же.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышу ;) вот от вас снова услышал — посмеялся и то хорошо
у C++ например вообще по годам выпуска версии
да и там точно такие же ломки апи? ;)
'проблема' в том что это вообще существуетТолько в тех статьях, а не в реальной жизни. Написать долго компилирующийся код можно на чем угодно ведь. Тот же Kotlin часто ставили в сравнение к Свифту, только вот на андроиде он сейчас хуже Свифта первых версий в плане скорости компиляции. А сливать все в один файл — ну так и в других языках можно, что бы линковщику облегчать работу, тоже станет быстро компайлится. А вообще все их проблемы только потому что надо раз в 2 минуты компилировать и запускать проект, потому что… а черт их знает почему они так делают. И это печально, конечно.
у меня были даже между 2.0(последняя 7) и 2.0.1(первая 8) потому что смуззихлебы понаписали подов а другие смуззихлебы понадобавляли их в проектБыла такая же проблема, в подах чего только не было, когда увидели — были в шоке, за месяц подчистили и перевели. Но давайте будем честными, проблема тут изначально не в том что поменяли что-то в новой версии языка (потому что так же само могло все повалиться с новой SDK, будь у Вас Obj-C проект), а в том что накидали pods без разбору и с этим приходится жить.
я эту байку слышал уже 4 раза, собственно говоря каждый год ее слышуЯ не слухи рассказываю все же, а что происходит в swift-evolution. Они за все время ни разу не обещали что вот прям в следующей версии все будет идеально, они определяли приоритеты и реализовывали, у них с этим все довольно строго. И изначально сказали когда речь пошла про ABI что они два года будут это делать, чем, собственно, и занимаются. Для них это тоже довольно важная вещь и не только потому что ченджи ломают все. Сейчас уже, кстати, можно в 4-м Свифте 3.2 использовать.
да и там точно такие же ломки апи? ;Я это упомянул не в плане изменений в С++ (за коим уже давно не слежу и статьи здесь на хабре про новшества нового стандарта честно говоря выглядят жутко в плане кол-ва изменений и нововведений), а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
а в том плане что еще с первой версии все ругались что это не 1.0, а 0.1 скорее.
так и я про это же, представьте какой бы вой был бы если бы оракл или мс опубликовали язык такой же степени сырости, с… вном их бы мешали все кому не лень. А в мире эплфанбоев это жрут и добавки просят. И заботливо мостырят скриптиками костыли и подпорочки чтобы этот треш хоть как то работал.
дело ж не только в компиляции тормозной (хотя и в ней тоже), дело в убогой бажной иде, дебаггере, плейграунде, в общем такое ощущение что им абсолютно начихать на своих девелоперов, все равно утрутся и дальше будуто хлебать.
Под Swift есть несколько книг и статей от Apple + целая гора материалов по отдельным библиотекам на сайте Apple для разработчиков. По андроиду приходится искать сторонние книги и туториалы и надеяться, что автор разобрался в теме.
Но данный язык отстал от современных методов разработки, Apple его не развивает, а также он отличается наличием большого количества устаревших правил, таких как отсылка сообщений nil-объектам и динамическая система типов.
Уважаемый, жгите еще про отсталость динамической системы типов и безопасность встроенного nil.
а вообще кордата и kvo работает за счет isa swizzling, динамизм скорее благо чем зло.
а про нил безопастность по вашему надо крешиться? или как в свифте лепить guard let в рядок?
Конечно, крешиться
fail fast — хорошо девелоперу и очень очень плохо юзеру
Protocol Oriented Programming — вполне про это(динамизм), не важно кто(инстанс какого класса) и каким образом имплементирует протокол, как примеры дефолтная имплементация протокола в свифте или targetForSelector в обжективе.
Я не программист, но увлекаюсь разработкой под андроид. Вот вопросы же элементарные. Я не знаю swift, но на все вопросы можно ответить, просто зная парадигму любого языка. Интерфейсы просто с другим названием, ну или передача по ссылке и по значению, ну вот везде это описано. В любой книге, по любому языку программирования, только с небольшими отличиями. Вот что это за кандидаты, что лажают в таких местах и на собеседованиях в такую крупную компанию. Ладно там резюме в интернете скачал, но у вас же должны быть HR со списком готовых вопросов/ответов, которые просто должны отсеять эту аудиторию по телефону. Просто представляю, сидит тимлид, работающий команде разработки под iOS, и к нему на собеседование приходит ЭТО.
На деле замыкание — это reference typeи
отсюда появляются известные конструкции [weak self] in
Имелось в виду то, что self сильно держит замыкание, и для избежания retain cycle внутри замыкания self держится слабо?
"Строго говоря, в случае с value type работает принцип copy-on-write." — Не совсем так, механизм copy-on-write применен только для определенных типов Swift Standard library, для которых копирование при присвоении может вызвать проблемы с производительностью. Если Вы создаете свою структуру вам придется самому реализовывать эту механику(https://stackoverflow.com/questions/45253202/which-value-types-in-swift-supports-copy-on-write). В своей практике уже несколько раз сталкивался с тем, что люди пишут на Swift, не используя главные фичи языка(например расширения протоколов), хотя вроде сейчас много материалов на эту тему.
Реалии таковы что 'рынок' заполнен смуззихлебами ради которых эпл уже в wwdc начинает вставлять статьи по алгоритмам лишь бы они хоть что то учили.
В принципе и эта статья говорит про это же, толпы фанбоев без бекграунда — пытаются разрабатывать софт и конечно им свифт после js или php роднее. А там глядишь и видосики wwdc посмотрят и научаться плодить квадратичной сложности решения вместо кубической и убер ускорит свое приложение:)
Расскажите, почему вы считаете, что код на бумажке писать полезно?
Добрый день!
А можете прокомментировать результаты по заданию с падающим приложением?
Первый пул-реквестер просто удалил требование наследоваться от UITableViewCell
. На мой взгляд, можно было решить задачу лучше.
Немного поискав, я нашел, что проблема относится к багу в компиляторе Swift, и самое оптимальное решение — указать директиву наследования от class
или AnyObject
.
Данное решение оставляет требование наследоваться от UITableViewCell и решает вопрос падения приложения, единственная проблема — появляется warning, который тоже является багом компилятора, который должны будут исправить в будущем.
Ну и чтобы два раза не вставать, подскажите, кандидатов не писавших на Objective C, но понимающих код, и пишуших на Swift вы рассматриваете? Если да, то по поводу трудоустройства вам куда лучше писать, откликаться на hh.ru?
Новичок или опытный? Как нанять мобильного разработчика под iOS, который что-то действительно умеет