Я не очень поняла ваше замечание. От 0.5 к 0.6 — это больше или меньше 1.2 от 2.0? Но, если по делу, то переходить очень легко — работает автоматическая миграция от Swift 1.2 к Swift 2.0 и работает очень хорошо, даже для больших проектов — все попробовала. Остаются только мелочи, которые легко поправить, если знаешь, как это должно быть.
Ну, это вы загнули насчет #available. Если вы писали приложения, то наверно, знаете, что первое, что вы указываете при создании проекта, это либо приложение на iOS, либо на OS, либо tvOS, либо watchOS.
Так что они никогда не перемешаются.
Да, сейчас можно писать на Swift 2.1. Посмотрите мои Задания для стэнфордских курсов на Swift здесь. Есть очень не простые.
Единственное, где Objective-C выигрывает, — это вставка C кода напрямую в Objective-C. Но они над этим работают.
Сейчас адаптирую стэнфордские курсы на русском языке на Objective-C для iOS 9, и хотя API абсолютно одинаковые для Swift и Objective-C, несопоставимо легче писать на Swift.
До Swift 2, как в Objective-C, так и в Swift 1.x, протоколы содержали только декларацию методов (это то, о чем вы говорите).
С расширениями протокола (Protocol extensions) в Swift 2, протоколы теперь могут содержать наряду с декларацией, реализацию методов по умолчанию.
Часто некоторую функциональность необходимо добавить всем типам, которые подтверждают определенный протокол (интерфейс). Например, все коллекции (протокола CollectionType) могут поддерживать концепцию создания новой коллекции на основе преобразований своих элементов.
Если в расширении протокола CollectionType реализовать эту функциональность, то все типы, которые подтверждают протокол CollectionType, автоматически получат эту функциональность совершенно бесплатно.
Расширения протоколов лежат в основе нового подхода к конструированию программного обеспечения, заявленного Apple как Протокол-Ориентированное Программирование (ПОП), существующее в Swift 2 наряду с традиционным Объектно-Ориентированное Программированием ( ООП) и элементами Функционального Программирования (ФП). Оно должно преодолеть такие проблемы ООП, как «хрупкий базовый класс» и жесткость наследования (rigidity and fragility of inheritance), «проблему ромба» (“diamond problem”), неявное разделение ссылок на объекты, необходимость частого использования «кастинга» вниз (downcasting) в переопределенных методах.
Это сплошная деза. Зачем же это делать? Это какая-то статья-провокация.
Сегодняшний Swift не имеет ничего общего с тем, что написано в этой статье.
Да, год с небольшим назад, когда Apple объявила о Swift, некоторые, конечно, решили, что им дают готовый, как всегда очень качественный продукт. Но Apple оказалась хитрее, ни для каких больших проектов Swift 1.0 никто и не предлагал.
Она заставила весь мир работать над отладкой языка Swift и очень оперативно реагировала на все хорошие предложения.
Долго сопротивлялась, но сделала очень красивую обработку ошибок в Swift. Одни операторы guard и defer чего стоят. Сейчас язык в очень хорошей форме и действительно c многими парадигмами: хочешь ООП, хочешь элементы ФП, а сейчас еще и протокол-ориентированное программирование. Он отличается от того самого первого варианта 1,5 годичной давности как мобильные телефоны 90-х годов прошлого столетия величиной с портфель от iPhone.
То что автор статьи поскулил немного 1,5 года назад еще понять можно. Но то, что переводчик выложил это сейчас можно объяснить только тем, что целый год переводил, перевел и выбрасывать жалко.
Objective-C здесь вообще не причем. Apple его очень любовно сопровождает, API фреймворков и для Swift, и для Objective-C абсолютно одинаковые. Программируйте на чем хотите.
Но программировать на Swift приятно — всем советую попробовать и есть замечательные фишки типа if #available(iOS 9, *) без которых уже трудно обходиться.
А вот кстати интересный пример. В Swiftz есть операторы которые вообще не понятно как с клавиатуры вводить: •, ∪, ∩. По моему вменяемые разработчики должны такого избегать. Зачем это вообще в язык добавили? Чтобы кто-нибудь мог brainfuck.swift реализовать? :)
Пишу профессионально на Scala, писал пару недель на ObjC пять лет назад, на досуге почитываю Haskell и вот пару недель назад решил попробовать выучить Swift и написать чего-нибудь под iOS.
Так вот, лично мне очень понравились функциональные фичи языка: алгебраические типы данных (enum), map/filter/reduce, лямбды и др. И все это достаточно неплохо сделано, что позволяет вытворить всякие вещи, типа Swiftx/Swiftz.
Судя по моим экспериментам и опыту работы со Swift, действительно это о Swift 1.2. На данный момент это и правда больше историческая заметка о молодых (читай лихих) годах свифта. Но честно говоря, субъективно и Swift 2 часто вызывает лично у меня ощущение, что компилятор играет против тебя — хотя здесь очень сложно оценить, где кончаются проблемы языка и начинаются проблемы восприятия разработчиком.
А чем скриптовые и скрипто-подобные языки принципиально отличаются от любых других в смысле использования модификаторов доступа? Модификаторы доступа позволяют управлять вниманием читающего код программиста, указывают на то, какие переменные могут меняться в контексте определённого поведения… Да, это можно эмулировать другими средствами, но и ООП можно эмулировать в рамках функционального подхода. Зачем это делать прямо специально?
Единственные две видимые для меня причины, по которым модификаторы доступа не включаются в язык — это ускорение разбора кода программы и упрощение языка с точки зрения его изучения (только изучения грамматики — не написания кода). Если первую причину я ещё могу понять, то вторая — упрощение ради упрощения, чтобы программисту меньше слов языка учить нужно было — мне не очень ясна. Тогда нужно braindfuck учить — всего четыре, кажется, слова, вообще отличный язык.
Утрирую, конечно, но меня всегда удивляло отсутствие модификаторов доступа в некоторых серьёзных языках — в том же objective-C, например, в котором приходилось имитировать модификаторы, разбивая поля на те, что в m-файле (приватные) и те, что в хедере (публичные).
Есть еще один не очень приятный момент. Начал я как-то переписывать свой проект на Swift. После недели, в целом, комфортной разработки я заметил что билд долго грузится в TestFlight. Оказалось, что обычное приложение с 5ю вью контроллерами весит порядка 60 мегабайт. Поискав информацию в интернете, оказалось:
For the time being, Swift itself lives in the binary of each application built with it. This may change when Swift reaches a release that Apple is comfortable bundling with iOS, but for now it's just something we have to live with. This behavior is the reason you can build an iOS 7/8 application in Swift 1.0/1.1/1.2 and it just works when you build and run.
Для игр это еще более менее оправданно, а вот выпускать обычное приложение, которое разрастется до почти 100 мегабайт как-то не очень хорошо.
P.S. Expression was too complex to be solved in reasonable time меня, конечно, тоже сильно улыбнуло, на всякий случай посмотрел в календарь, не 58-й ли год на дворе.
Плюс эти знаки собаки постоянные у строк. Простой синтаксис — это не так уж и мало в разработке. Однако ниже я написал неприятный момент со Swift из-зак которого продакшн-проекты я продолжу писать на Objective-C
От себя могу сказать, что все те грандиозные фичи революционного языка, из-за которых стоит бросить Objective-C и начинать работать со Swift пока не несут на деле каких то революций — по сути у нас тот же Objective-C с небольшими приятностями, вроде чуть более прозрачного синтаксиса, дженериков, безопасности работы с памятью (за которую придется заплатить if let obtainedRef = ref {} на каждый чих для нуллабл референсов). И вот эти прекрасные дифирамбы производительности на абстрактных бенчмарках — да это интересно. Но чаще всего нам придется работать со все тем же Cocoa фреймворками, и эта разница с Objective-C не будет уже такой внушительной. И так со всеми фичами — вроде и здорово и классно, но с подводными камнями и легким ощущением обмена шила на мыло при внимательном рассмотрении. А платим мы за это производительностью и тем, что приходится работать с сыроватым компилятором. Видимо это больше проблема восприятия — эпл в привычной для себя манере обещает нечто грандиозное, а показало нам неплохой язык, но после изучения действительно свежих концепций привнесенных теми же Go/Rust и иже с ними, он кажется опоздавшим к празднику жизни.
Почему постоянно появляются статьи «Почему vim круче чем все остальное», и почему нет статей про наоборот? Почему апологеты vim так напоминают мне религиозных проповедников, которые звонят вам в дверь и предлагают «поговорить о Боге», или хватают вас за рукав на улице и обещают, что стоит обратиться к истинной вере и вы получите сразу отпущение грехов, вечную жизнь в раю и все земные блага как дополнительный бонус? Откуда эта постоянная жажда доказывать другим, что выбранно ТОБОЙ решение самое лучшее и лучше быть не может НИЧЕГО и НИКОГДА?
Потому, что это в крови у многих людей. Помните «поставил Linux, напиши на хабр»? Так же и с Vim. Преодолел кривую обучения, напиши какой ты крутой!
По-моему появление «мультикурсора» в IDE окончательно свело на нет преимущества vi-подобных. Если вдруг надо поработать с кодом как с тупо текстом, произведя повторяемые операции – да пожалуйста, Alt+тык-тык-тык или хоткей «довыделить подобное». И то подобные вещи нужны довольно редко, большинство вещей решается высокоуровневыми командами рефакторинга и генерации (часть из которых даже вызывать не надо, они сами).
Тут недавно был эпизод как один из коллег, пользующийся вимом, жаловался, что вот дескать, неудобно, что у вас столько use надо писать. Не все даже вопрос поняли, я последний раз use руками писал не помню когда, кто-то вообще забыл что use автоматически в шапку файла добавляется.
В статье не упомянули, что рассвет VI пришелся на то время, когда связь была мееедленная, и VI позволял элементарно работать с файлами больших размеров, с идеальной точностью.
Поясню — если интерфейс тормозит, то работа мышкой приводит к постоянным промахам и ожиданиям — кликнул куда-то мышкой, и обязательно нужно дождаться, пока курсор туда переместится, чтобы что-то сделать. Начал что-то выделять стрелочками — и нужно дождаться, пока все выделится.
В VI этой проблемы не было в принципе — ты мог нажать 10-20 клавиш, четко «запрограммировав действия», и пока они дойдут на удаленный сервер, уже закрыть VI. В то время ни один редактор так четко не мог.
Кроме того, IMHO vi это не IDE — это редактор, который крайне полезен сисадмину, потому что для правки текстовых файлов (быстро исправить конфиг) — он идеален. Маленький, мгновенно открывается, отличная навигация, огромные возможности для автоматизации действий. VI и SED — и все будет хорошо.
То, что VI пролез в программирование — ну наверное на фоне популярности среди переучившихся админов.
P.S. Вдобавок vi есть сходу во всех *nix, это как notepad, только сразу почти notepad++
Меня не команды напрягают, а режимы, то есть, состояния редактора. Я считаю, что чем меньше режимов, тем лучше. Чем меньше модальности, тем лучше. Чем меньше функций висит на каждой конкретной кнопке, тем лучше. Чем меньше, тем лучше. Идеал — когда ничего нельзя убрать.
И, про запоминание команд и привыкание к нему: вот с этим я полностью солидарен. Не стоит овчинка выделки. Да и про то, что вы, давно использующий и хорошо знающий vim реально получили ускорение хотя бы работы с текстом тоже бабка надвое сказала.
На мой взгляд, вим стал жертвой прогресса. Я не знаю достоверно каков был рынок средств разработки в 91 году, но предположу что не было кроссплатформенных, расширяемых универсальных IDE. Были редакторы и средства вроде Borland C++. И тогда это был реальный шаг вперед. Редактор который умел больше чем обычный (опять же, оговорюсь — не знаю что он умел).
Но сейчас средства разделились на редакторы (набрать текст) и IDE (работать с проектом). Вим получается посередине, как утка. Но это уже не нужно. Если я хочу набрать текст — мне не нужен редактор который осваивать дольше чем IDE, мне нужен ee/nano. А если мне нужна работа с проектом — мне нужна нормальная IDE с большими возможностями и низким порогом вхождения, а не школа белого нидзя по освоению навороченного текстового редактора.
Давайте не будет рассматривать сферический редактор IDE в вакууме.
Когда vi используют для программирования (т.е. как замену IDE), то vi проигрывает. Автор статьи этого не понимает.
Когда IDE используют в качестве простого редактора текста (т.е. никогда по сути), то vim возможно в чем-то выигрывает.
>Хотя, если честно, для языков с динамической типизацией нет большой разницы между использованием IDE или vim с кучкой плагинов.
Нет, это не так.
1) Для того же php (самый динамический язык) всё это есть: и рефакторинг, и переименования классов, и подсветка и т.д.
2) Знать кучу плагинов и, что еще хуже, знать все эти 100500 комбинаций клавиш для каждого из этих плагинов — это же адъ. Не надо это сравнивать с IDE, где из коробки идет 99% функционала, а остальное включается нажатием галочки.
> Или продолжайте использовать никудышный редактор кода своей IDE. Но, в любом случае, никогда больше не заявляйте, что пользователи vi придурки.
Вы меня простите, но автор явно не пробовал продукты от JetBrains.
Где можно одной кнопкой сделать extract method большого куска говнокода, и он правильно поймет, какие переменные должны быть на входе, какие на выходе.
Где можно переименовать класс сразу во всем проекте
Где можно выполнять sql-запросы прям из ide, а также автокомплит SQL-запросов прямо внутри строки.
Где можно нажать ctrl-клик и перейти к месту, где определен метод/класс.
Где можно найти все использования метода в проекте (find usages)
Где весь проект индексируется, и поиск по нему занимает около 0 сек.
Где можно переименовать переменную сразу во всех местах метода, где она встречется
Где IDE заботливо подсказывает, какие аргументы нужны конструктору / методу.
Где IDE подсвечивает места, где ему что-то не нравится в коде, например неиспользованную переменную (успешная борьба с опечатками)
Где есть еще 100500 этих «где» и нет необходимости запоминать всякий бред типа c% ctrl-r минус
Назвать IDE такого класса «некудышными» может только придурок.
чем продуктивнее инструмент, тем более высок порог входа и кривая обучения
Obvious false.
Резко повысить продуктивность фотографирования позволил автофокус, а позже — возможность немедленно видеть результат. И первое, и особенно второе снизило порог входа и кривую обучения в фотографирование.
Так что они никогда не перемешаются.
Да, сейчас можно писать на Swift 2.1. Посмотрите мои Задания для стэнфордских курсов на Swift здесь. Есть очень не простые.
Единственное, где Objective-C выигрывает, — это вставка C кода напрямую в Objective-C. Но они над этим работают.
Сейчас адаптирую стэнфордские курсы на русском языке на Objective-C для iOS 9, и хотя API абсолютно одинаковые для Swift и Objective-C, несопоставимо легче писать на Swift.
С расширениями протокола (Protocol extensions) в Swift 2, протоколы теперь могут содержать наряду с декларацией, реализацию методов по умолчанию.
Часто некоторую функциональность необходимо добавить всем типам, которые подтверждают определенный протокол (интерфейс). Например, все коллекции (протокола CollectionType) могут поддерживать концепцию создания новой коллекции на основе преобразований своих элементов.
Если в расширении протокола CollectionType реализовать эту функциональность, то все типы, которые подтверждают протокол CollectionType, автоматически получат эту функциональность совершенно бесплатно.
Расширения протоколов лежат в основе нового подхода к конструированию программного обеспечения, заявленного Apple как Протокол-Ориентированное Программирование (ПОП), существующее в Swift 2 наряду с традиционным Объектно-Ориентированное Программированием ( ООП) и элементами Функционального Программирования (ФП). Оно должно преодолеть такие проблемы ООП, как «хрупкий базовый класс» и жесткость наследования (rigidity and fragility of inheritance), «проблему ромба» (“diamond problem”), неявное разделение ссылок на объекты, необходимость частого использования «кастинга» вниз (downcasting) в переопределенных методах.
Сегодняшний Swift не имеет ничего общего с тем, что написано в этой статье.
Да, год с небольшим назад, когда Apple объявила о Swift, некоторые, конечно, решили, что им дают готовый, как всегда очень качественный продукт. Но Apple оказалась хитрее, ни для каких больших проектов Swift 1.0 никто и не предлагал.
Она заставила весь мир работать над отладкой языка Swift и очень оперативно реагировала на все хорошие предложения.
Долго сопротивлялась, но сделала очень красивую обработку ошибок в Swift. Одни операторы
guardиdeferчего стоят. Сейчас язык в очень хорошей форме и действительно c многими парадигмами: хочешь ООП, хочешь элементы ФП, а сейчас еще и протокол-ориентированное программирование. Он отличается от того самого первого варианта 1,5 годичной давности как мобильные телефоны 90-х годов прошлого столетия величиной с портфель от iPhone.То что автор статьи поскулил немного 1,5 года назад еще понять можно. Но то, что переводчик выложил это сейчас можно объяснить только тем, что целый год переводил, перевел и выбрасывать жалко.
Objective-C здесь вообще не причем. Apple его очень любовно сопровождает, API фреймворков и для Swift, и для Objective-C абсолютно одинаковые. Программируйте на чем хотите.
Но программировать на Swift приятно — всем советую попробовать и есть замечательные фишки типа
if #available(iOS 9, *)без которых уже трудно обходиться.Так вот, лично мне очень понравились функциональные фичи языка: алгебраические типы данных (enum), map/filter/reduce, лямбды и др. И все это достаточно неплохо сделано, что позволяет вытворить всякие вещи, типа Swiftx/Swiftz.
Единственные две видимые для меня причины, по которым модификаторы доступа не включаются в язык — это ускорение разбора кода программы и упрощение языка с точки зрения его изучения (только изучения грамматики — не написания кода). Если первую причину я ещё могу понять, то вторая — упрощение ради упрощения, чтобы программисту меньше слов языка учить нужно было — мне не очень ясна. Тогда нужно braindfuck учить — всего четыре, кажется, слова, вообще отличный язык.
Утрирую, конечно, но меня всегда удивляло отсутствие модификаторов доступа в некоторых серьёзных языках — в том же objective-C, например, в котором приходилось имитировать модификаторы, разбивая поля на те, что в m-файле (приватные) и те, что в хедере (публичные).
Больше информации.
Для игр это еще более менее оправданно, а вот выпускать обычное приложение, которое разрастется до почти 100 мегабайт как-то не очень хорошо.
P.S. Expression was too complex to be solved in reasonable time меня, конечно, тоже сильно улыбнуло, на всякий случай посмотрел в календарь, не 58-й ли год на дворе.
намного приятнее, чем
Плюс эти знаки собаки постоянные у строк. Простой синтаксис — это не так уж и мало в разработке. Однако ниже я написал неприятный момент со Swift из-зак которого продакшн-проекты я продолжу писать на Objective-C
Потому, что это в крови у многих людей. Помните «поставил Linux, напиши на хабр»? Так же и с Vim. Преодолел кривую обучения, напиши какой ты крутой!
Тут недавно был эпизод как один из коллег, пользующийся вимом, жаловался, что вот дескать, неудобно, что у вас столько use надо писать. Не все даже вопрос поняли, я последний раз use руками писал не помню когда, кто-то вообще забыл что use автоматически в шапку файла добавляется.
Поясню — если интерфейс тормозит, то работа мышкой приводит к постоянным промахам и ожиданиям — кликнул куда-то мышкой, и обязательно нужно дождаться, пока курсор туда переместится, чтобы что-то сделать. Начал что-то выделять стрелочками — и нужно дождаться, пока все выделится.
В VI этой проблемы не было в принципе — ты мог нажать 10-20 клавиш, четко «запрограммировав действия», и пока они дойдут на удаленный сервер, уже закрыть VI. В то время ни один редактор так четко не мог.
Кроме того, IMHO vi это не IDE — это редактор, который крайне полезен сисадмину, потому что для правки текстовых файлов (быстро исправить конфиг) — он идеален. Маленький, мгновенно открывается, отличная навигация, огромные возможности для автоматизации действий. VI и SED — и все будет хорошо.
То, что VI пролез в программирование — ну наверное на фоне популярности среди переучившихся админов.
P.S. Вдобавок vi есть сходу во всех *nix, это как notepad, только сразу почти notepad++
Меня не команды напрягают, а режимы, то есть, состояния редактора. Я считаю, что чем меньше режимов, тем лучше. Чем меньше модальности, тем лучше. Чем меньше функций висит на каждой конкретной кнопке, тем лучше. Чем меньше, тем лучше. Идеал — когда ничего нельзя убрать.
И, про запоминание команд и привыкание к нему: вот с этим я полностью солидарен. Не стоит овчинка выделки. Да и про то, что вы, давно использующий и хорошо знающий vim реально получили ускорение хотя бы работы с текстом тоже бабка надвое сказала.
Но сейчас средства разделились на редакторы (набрать текст) и IDE (работать с проектом). Вим получается посередине, как утка. Но это уже не нужно. Если я хочу набрать текст — мне не нужен редактор который осваивать дольше чем IDE, мне нужен ee/nano. А если мне нужна работа с проектом — мне нужна нормальная IDE с большими возможностями и низким порогом вхождения, а не школа белого нидзя по освоению навороченного текстового редактора.
Когда vi используют для программирования (т.е. как замену IDE), то vi проигрывает. Автор статьи этого не понимает.
Когда IDE используют в качестве простого редактора текста (т.е. никогда по сути), то vim возможно в чем-то выигрывает.
>Хотя, если честно, для языков с динамической типизацией нет большой разницы между использованием IDE или vim с кучкой плагинов.
Нет, это не так.
1) Для того же php (самый динамический язык) всё это есть: и рефакторинг, и переименования классов, и подсветка и т.д.
2) Знать кучу плагинов и, что еще хуже, знать все эти 100500 комбинаций клавиш для каждого из этих плагинов — это же адъ. Не надо это сравнивать с IDE, где из коробки идет 99% функционала, а остальное включается нажатием галочки.
Вы меня простите, но автор явно не пробовал продукты от JetBrains.
Где можно одной кнопкой сделать extract method большого куска говнокода, и он правильно поймет, какие переменные должны быть на входе, какие на выходе.
Где можно переименовать класс сразу во всем проекте
Где можно выполнять sql-запросы прям из ide, а также автокомплит SQL-запросов прямо внутри строки.
Где можно нажать ctrl-клик и перейти к месту, где определен метод/класс.
Где можно найти все использования метода в проекте (find usages)
Где весь проект индексируется, и поиск по нему занимает около 0 сек.
Где можно переименовать переменную сразу во всех местах метода, где она встречется
Где IDE заботливо подсказывает, какие аргументы нужны конструктору / методу.
Где IDE подсвечивает места, где ему что-то не нравится в коде, например неиспользованную переменную (успешная борьба с опечатками)
Где есть еще 100500 этих «где» и нет необходимости запоминать всякий бред типа c% ctrl-r минус
Назвать IDE такого класса «некудышными» может только придурок.
Obvious false.
Резко повысить продуктивность фотографирования позволил автофокус, а позже — возможность немедленно видеть результат. И первое, и особенно второе снизило порог входа и кривую обучения в фотографирование.