Comments 40
Пожалуй останусь на OBJ-C. Хоть и синтаксис упорот. Но по крайней мере:
— Стабильно
— Без «плюшек» ввиде багов с ооочень долгим компиляцией массива, в котором ты запилил еще OPTIONAL переменную…
Ну и разумеется AppCode отвратительно работает, что очень удурчяет.
Вообщем поживём, увидим :).
— Стабильно
— Без «плюшек» ввиде багов с ооочень долгим компиляцией массива, в котором ты запилил еще OPTIONAL переменную…
Ну и разумеется AppCode отвратительно работает, что очень удурчяет.
Вообщем поживём, увидим :).
ввиде багов с ооочень долгим компиляцией массива
Это далеко не самый страшный баг свифта) но вернуться на обж-си я уже не могу, глаза вытекают…
Расскажите плиз про страшные баги свифта.
https://bugs.swift.org/browse/SR-1502 вот, например. Страшный.
О, вот прям с утра от знакомых еще один прилетел:
http://openradar.appspot.com/radar?id=4971716266688512
http://openradar.appspot.com/radar?id=4971716266688512
Я бы сказал, что у свифта синтаксис не менее упорот
По моему это хорошо, что они так легко рефакторят API стандартной библиотеки без оглядки на обратную совместимость. Пока язык молодой, они могут себе это позволить без особой боли. Потом будет сложнее.
Не факт, что будет сложнее. Я так понимаю к каждой версии выходит codemode-tool, который приводит весь старый код к новому виду. Если такое делать постоянно, но обратная совместимость имхо не так важна. Подобного не хватает в других технологиях.
Не понятно зачем они это называют 3.0, а не 0.3.
В последнее время вообще наблюдается тенденция использовать мажорные номера версий. Возможно, какой-то психологический трюк. Наверное, людям приятнее смотреть на версию 3.0 или 3.1, чем на 0.3.11 или что-нибудь в таком роде. С быстрым ростом версии кажется, что проект быстрее развивается, а его вес в глазах сообщества растёт. :)
При этом правило «стабилизируем API на версии 1.0» в этом случае уже не работает.
При этом правило «стабилизируем API на версии 1.0» в этом случае уже не работает.
Мне более импонирует использование semver + плюс оговорки для major == 0, чем такой популизм.
Тот же rust пошёл по пути постепенного развития, но базовые вещи зафиксированы с версии 1.0.0. А то, что ещё не зафиксировано и развивается — недоступно в stable. Т. е. новые api в libstd и libcore появляются только после их обкатки и в финальном виде. Что, несмотря на довольно высокий темп релизов (раз в 6 недель) позволяет выдавать продуманное стабильное API
На 0.3 совсем мало бы кто перешел, а им нужно как можно больше пользователей:
во-первых, это более массовое тестирование, а значит меньше укромных уголков для крупных дефектов;
во-вторых, после набора определенной критической массы поддержка Obj-C может быть сильно ограничена с высвобождением средств разработки.
Но разделяю вашу фрустрацию.
во-первых, это более массовое тестирование, а значит меньше укромных уголков для крупных дефектов;
во-вторых, после набора определенной критической массы поддержка Obj-C может быть сильно ограничена с высвобождением средств разработки.
Но разделяю вашу фрустрацию.
UFO just landed and posted this here
Собственно, если перейти по вашей ссылке, то там написано следующее:
Это примерно соответствует тому, на какой стадии сейчас находиться разработка Swift, учитывая то, с какой легкостью они позволяют себе переименовывать базовые методы в стандартной библиотеке языка. Я не хочу сказать что это само по себе плохо, просто в таком случае было бы честно говорить, что текущая версия языка – 0.3.
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Это примерно соответствует тому, на какой стадии сейчас находиться разработка Swift, учитывая то, с какой легкостью они позволяют себе переименовывать базовые методы в стандартной библиотеке языка. Я не хочу сказать что это само по себе плохо, просто в таком случае было бы честно говорить, что текущая версия языка – 0.3.
Изменения пролоббированы авторами учебников начального уровня: Lynda, Udemy и т.д.?
Это говорит о том, что либа, собраная на Swift 2.0 уже не будет резолвиться с 2.2 версией языка. Коллеги из стабильных языков:
В C++, насколько я знаю, стандартизации ABI нет до сих пор (я знаю только про пропозал Саттера: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf, но за его судьбой не следил). Ну и интересно узнать про языки вне платформ JVM и .NET, у которых есть стандартизованные ABI интерфейсы.
Разница серьёзнее, чем между Python2 и Python3. При этом на Python3 народ уже много лет переходить из-за этого не хочет. В основном, программы не переходят потому, что библиотеки остались на втором, а библиотеки не переходят потому, что использующие их программы остались на втором.
Посмотрим что тут получится. Так сказать, сравнение развития ситуации при инъекции бабла.
Посмотрим что тут получится. Так сказать, сравнение развития ситуации при инъекции бабла.
С кейсами для enum как-то неоднозначно.
Одно из самых заметных отличий второго свифта от третьего это то, что сейчас нужно обязательно указывать первый агрумент функции по полному имени.
Swift 2:
Swift 3:
или
Переименование функций, например, из «3.0».componentsSeparatedByString(".") в «3.0».components(separatedBy: ".") могли быть следствием этого.
Swift 2:
func square(a:Int) -> Int { return a * a }
print(square(10))
Swift 3:
func square(a:Int) -> Int { return a * a }
print(square(a:10))
или
func square(_ a:Int) -> Int { return a * a }
print(square(10))
Переименование функций, например, из «3.0».componentsSeparatedByString(".") в «3.0».components(separatedBy: ".") могли быть следствием этого.
Вот честно просто не могу себе представить, ЗАЧЕМ?
Видимо, для более явного именования аргументов функции, у которых есть внутреннее и внешнее имя. Единообразие, видимо, в объявлении аргументов. Если не хочешь извне указывать имя аргумента явно — в объявлении функции используешь _ и пишешь square(10)
Благо, что думать в Swift не надо :) а по каждому решению есть точное описание. По этому изменению вот:
https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md
В данном случае речь идет о единообразии и чистоте языка. Теперь функции единообразны с инициализаторами, где требовалось указывать первый параметр обязательно, а если ты не хочешь, то надо было ставить "_". А в других функциях требовалось наоборот дважды указывать название первой переменной, чтобы мочь ее указывать в вызове. Это могло быть confusing для людей, изучающих язык. Теперь все сделано единообразно.
ЗЫ как человек, который «волею судеб» год писал приложение в продакшене только на Swift каждый день, скажу, что язык мне нравится. Очень дисциплинирует. Иногда, когда возвращался на 5 минут в Obj-С, глаза действительно кровоточили от синтаксиса. Также, привыкнув к Optionals, порой было страшно в Obj-C, что передам nil в какой-то метод, которые его не принимает. Но на днях прям плотненько вернулся в старый проект на Obj-C и оказалось, что это как ездить на велосипеде, руки то помнят :))) и можно писать точно также хорошо.
https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md
В данном случае речь идет о единообразии и чистоте языка. Теперь функции единообразны с инициализаторами, где требовалось указывать первый параметр обязательно, а если ты не хочешь, то надо было ставить "_". А в других функциях требовалось наоборот дважды указывать название первой переменной, чтобы мочь ее указывать в вызове. Это могло быть confusing для людей, изучающих язык. Теперь все сделано единообразно.
ЗЫ как человек, который «волею судеб» год писал приложение в продакшене только на Swift каждый день, скажу, что язык мне нравится. Очень дисциплинирует. Иногда, когда возвращался на 5 минут в Obj-С, глаза действительно кровоточили от синтаксиса. Также, привыкнув к Optionals, порой было страшно в Obj-C, что передам nil в какой-то метод, которые его не принимает. Но на днях прям плотненько вернулся в старый проект на Obj-C и оказалось, что это как ездить на велосипеде, руки то помнят :))) и можно писать точно также хорошо.
Планируется, что Swift будет работать на многих платформах, включая FreeBSD, Raspberry Pi, Android, Windows.
Захотел тут попробовать что-то для Linux сделать на Swift — упёрся в то, что ничего для работы с сетью пока не реализовано. Когда хотят реализовать — планов не нашёл, только «not implemented yet», то есть сделать на сервере какой-то запрос к какому-то другому REST API надо какими-нибудь обёртками на, например, сишным CURL (так делают IBM). Но хочется как-то из коробки
Можно посмотреть на это с другой стороны. В Swift очень удобно подключаются библиотеки на C. Недавно безо всяких проблем удалось подключить OpenGL.
Ещё потихоньку портируют Foundation Framework из Obj C. Здесь сказано, что NSURLRequest доступен и для Swift тоже.
В кроссплатформенный Swift ещё перенесли не все возможности Foundation Framework, но это одна из главных целей, поставленная для Swift 3.0:
Источник
Сейчас Foundation собирается довольно сложно, но к релизу должны поправить.
Ещё потихоньку портируют Foundation Framework из Obj C. Здесь сказано, что NSURLRequest доступен и для Swift тоже.
В кроссплатформенный Swift ещё перенесли не все возможности Foundation Framework, но это одна из главных целей, поставленная для Swift 3.0:
Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift 3 goal of portability.
Источник
Сейчас Foundation собирается довольно сложно, но к релизу должны поправить.
Здесь сказано, что NSURLRequest доступен и для Swift тоже
Так это документация для макоси, никаких проблем для iOS / tvOS / OX X нет, там бриджинг на все фреймворки из Objective-C из коробки.
В Linux то нужно опенсорсный Swift тащить и опенсорсный Foundation (тот что swift-corelibs-foundation), а там, к сожалению, написано:
NSURLSession and related classes are not yet implemented.
В любом случае, к выходу Swift 3, обещают реализовать всё.
Возможно какая-то часть уже сделана. Файл по ссылке не обновлялся уже пять месяцев, что для проекта у которого первый коммит сделан шесть месяцев назад — значительный срок.
Возможно какая-то часть уже сделана. Файл по ссылке не обновлялся уже пять месяцев, что для проекта у которого первый коммит сделан шесть месяцев назад — значительный срок.
А если сравнивать Swift с C#, что выглядит перспективней для мобильной разработки?
Насколько я понимаю, по уровню и наличию синтаксических плюшек вроде лямбда-выражений/nullable-переменных языки сопоставимы. Об IDE судить не берусь. Но на C# уже можно писать и для Android, и для iOS, а Swift только на пути к этому (да и с этой самой ABI-совместимостью у .NET получше)?..
Насколько я понимаю, по уровню и наличию синтаксических плюшек вроде лямбда-выражений/nullable-переменных языки сопоставимы. Об IDE судить не берусь. Но на C# уже можно писать и для Android, и для iOS, а Swift только на пути к этому (да и с этой самой ABI-совместимостью у .NET получше)?..
Ну окей, постараемся отбросить все предрассудки и посмотрим на вещи как они есть на самом деле.
Если есть желание писать под все мобильные платформы (iOS, Android, и, возможно, Windows Phone) на C#, то вероятно речь идет о silver bullet в лице Xamarin. Говорить о нем можно бесконечно, при этом как хваля его, так и презирая. Объективно, чтобы создать приложение, нужно:
1. Какая-то IDE для проектирования интерфейса;
2. Знание жизненного цикла приложения на мобильной ос;
3. Знание нативных библиотек;
«Мираж» Xamarin в том, что для того чтобы написать что-то на C#, вам, хотите вы или нет, придется разобраться в пунктах 1, 2 и 3. При этом на май 2016 года ни Xamarin Studio, ни Visual Studio нет нормального дизайнера.
— Для iOS вам придется использовать XCode Interface Builder, так как Storyboard формируются криво, а работа с Constraints начинает утомлять неточностью;
— Для Android вам придется использовать Android Studio и линковать xml-файлы обратно в Xamarin Studio, так как «IntelliSense» работает не очень хорошо, а для ресурсных xml не работает вовсе. Если конечно вы не ниндзя и пишете без подсказок в коде.
Далее вам будет необходимо использовать стандартные функции фреймворка или даже наследоваться:
— Из мира iOS вас теплыми объятиями встретит именование Objective-C функций, binding'а, интересные конструкторы с указателями;
— Из мира Android вас повстречает обязательное наследование от Java.Lang.Object и увлекательное жонглирование интерфейсами;
Ну и вишенка конечно — вопросы многопоточности, работы с сетью и хранения данных. Тут вы быстро попытаетесь спрятаться в уютном .NET домике. Он будет настолько теплым, что вы начнете выстраивать в нем свою параллельную вселенную, которая действительно будет работать.
Потратив значительное время на изучение нативных инструментов разработки, зазубривание нативного API и библиотек, а также переиначивая их на C#-лад, вы сделаете свое первое мобильное приложение, которое будет работать как надо. И будет выглядеть как нативное.
Но в этот момент *гифка где Гендальф-Белый плачет на фоне Хельмовой Пади, дождавшись помощи Эомера с войском рохирримов* — вы оглянетесь и скажете «я сделал это!», но встретившись глазами со своим боевым конем Xamarin'ом проскользнет секундная неловкость, и вы скажете: «Спасибо друг, дальше я сам», и нативная разработка станет для вас не такой страшной и более привлекательной.
Вытерев скупую мужскую слезу с мужественной щеки и, оценив перспективы C#, понимаешь, что он имеет крайне нишевое применение в мобильной разработке. Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. Вероятно это случится к 5 или 6 версии Swift года через два-три. И новые программисты вряд ли будут выбирать C# для этой связки.
Мое субъективное мнение — Swift на текущий момент слишком дорого обходится в промышленном использовании. Перепиливание проекта после каждой новой версии требует вливание человека-часов, конвертируемых в $. Тот же Xamarin стабильнее.
Objective-C не такой страшный как кажется на первый взгляд, и не такой «динозавр» как можно подумать. Если понимать как он работает внутри, то у него много общего с тем же C#.
C# отличный язык, мой любимый. И я фанат Miguel de Icaza. Но я понимаю, что доля C# в мобильной разработке даже в среднесрочной перспективе имеет форму дули. Но, тем не менее, Xamarin — это фантастическая штука, через которую я бы советовал пройти каждому C#/.NET программисту, который хочет приоткрыть для себя дивный мир мобильной разработки.
Если есть желание писать под все мобильные платформы (iOS, Android, и, возможно, Windows Phone) на C#, то вероятно речь идет о silver bullet в лице Xamarin. Говорить о нем можно бесконечно, при этом как хваля его, так и презирая. Объективно, чтобы создать приложение, нужно:
1. Какая-то IDE для проектирования интерфейса;
2. Знание жизненного цикла приложения на мобильной ос;
3. Знание нативных библиотек;
«Мираж» Xamarin в том, что для того чтобы написать что-то на C#, вам, хотите вы или нет, придется разобраться в пунктах 1, 2 и 3. При этом на май 2016 года ни Xamarin Studio, ни Visual Studio нет нормального дизайнера.
— Для iOS вам придется использовать XCode Interface Builder, так как Storyboard формируются криво, а работа с Constraints начинает утомлять неточностью;
— Для Android вам придется использовать Android Studio и линковать xml-файлы обратно в Xamarin Studio, так как «IntelliSense» работает не очень хорошо, а для ресурсных xml не работает вовсе. Если конечно вы не ниндзя и пишете без подсказок в коде.
Далее вам будет необходимо использовать стандартные функции фреймворка или даже наследоваться:
— Из мира iOS вас теплыми объятиями встретит именование Objective-C функций, binding'а, интересные конструкторы с указателями;
— Из мира Android вас повстречает обязательное наследование от Java.Lang.Object и увлекательное жонглирование интерфейсами;
Ну и вишенка конечно — вопросы многопоточности, работы с сетью и хранения данных. Тут вы быстро попытаетесь спрятаться в уютном .NET домике. Он будет настолько теплым, что вы начнете выстраивать в нем свою параллельную вселенную, которая действительно будет работать.
Потратив значительное время на изучение нативных инструментов разработки, зазубривание нативного API и библиотек, а также переиначивая их на C#-лад, вы сделаете свое первое мобильное приложение, которое будет работать как надо. И будет выглядеть как нативное.
Но в этот момент *гифка где Гендальф-Белый плачет на фоне Хельмовой Пади, дождавшись помощи Эомера с войском рохирримов* — вы оглянетесь и скажете «я сделал это!», но встретившись глазами со своим боевым конем Xamarin'ом проскользнет секундная неловкость, и вы скажете: «Спасибо друг, дальше я сам», и нативная разработка станет для вас не такой страшной и более привлекательной.
Вытерев скупую мужскую слезу с мужественной щеки и, оценив перспективы C#, понимаешь, что он имеет крайне нишевое применение в мобильной разработке. Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. Вероятно это случится к 5 или 6 версии Swift года через два-три. И новые программисты вряд ли будут выбирать C# для этой связки.
Мое субъективное мнение — Swift на текущий момент слишком дорого обходится в промышленном использовании. Перепиливание проекта после каждой новой версии требует вливание человека-часов, конвертируемых в $. Тот же Xamarin стабильнее.
Objective-C не такой страшный как кажется на первый взгляд, и не такой «динозавр» как можно подумать. Если понимать как он работает внутри, то у него много общего с тем же C#.
C# отличный язык, мой любимый. И я фанат Miguel de Icaza. Но я понимаю, что доля C# в мобильной разработке даже в среднесрочной перспективе имеет форму дули. Но, тем не менее, Xamarin — это фантастическая штука, через которую я бы советовал пройти каждому C#/.NET программисту, который хочет приоткрыть для себя дивный мир мобильной разработки.
Спасибо за содержательный ответ. Давно хотел понять, в чём подводные камни сочетания C# + Xamarin. Которое, вроде бы, призвано стать панацеей для мобильной разработки, но пока явно не становится. )
А насчёт
«Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. » Вероятно это случится к 5 или 6 версии Swift года через два-три."
мне кажется, за 2 — 3 года и Xamarin может обзавестись стоящей обёрткой для нативных библиотек + инструментами разработки интерфейса. Впрочем, не знаю, насколько это вероятно — просто тоже нравится C#. )
А насчёт
«Учитывая планы Google по использованию Swift в качестве ключевого языка для Android вывод становится очевидным — доминирование Swift в мобильной разработке лишь вопрос времени. » Вероятно это случится к 5 или 6 версии Swift года через два-три."
мне кажется, за 2 — 3 года и Xamarin может обзавестись стоящей обёрткой для нативных библиотек + инструментами разработки интерфейса. Впрочем, не знаю, насколько это вероятно — просто тоже нравится C#. )
за 2 — 3 года и Xamarin может обзавестись стоящей обёрткой для нативных библиотек + инструментами разработки интерфейса.
К тому моменту для большинства может встать один единственный, и страшный вопрос: «а зачем, если есть Swift?»
C# никуда не денется, как и Xamarin, но может стать своеобразным «шахматным клубом».
А на данный момент можно расслабиться, Google от слов к делу пока не перешел. Так что сейчас Xamarin, это «Уникальное предложение… Только сейчас… Вы сможете без труда… и т.д.» :-)
Оставлю этот комментарий про поддержку Windows.
Sign up to leave a comment.
Swift 3.0, много шума, а что на деле?