От переводчика: C пятницей, дорогие хабровчане! Хочу поделиться сегодня с вами переводом статьи из небольшого блога об опыте работы с языком Swift. Вряд ли она претендует на лавры серьезного и скрупулезного анализа, но, думаю, будет интересна всем, кто задумывался: «а не пора ли отправить на свалку истории этот Objective-C?».

Когда Apple представила нам Swift — это было круто! Наконец-то мы получили next-gen (т. е. модный-скриптоподобный) язык для разработки под яблочные девайсы (но без поддержки приватных членов класса, хм....). Теперь этот [языкДинозавр квадратноскобочный] может отправиться в музей, а мы начнем тыкать эти новые блестящие фичи языка. Безусловно, наивно предполагать, что язык, которому менее года, будет без тараканов. Очевидно, некоторое время нужно дать ему на избавление от детских болячек. Именно поэтому я не бросился переписывать все мои проекты на Swift сразу после анонса.


Заметили, что птица падает вниз?


Через год после выпуска, я наконец решил выучить язык. Для этого я стал писать игрушку про самую ужасную вещь в мире (в мире Windows 3.1, окей) — монстра из игры SkiFree. Вы можете прочесть об этом здесь

Дисклеймер: я пишу о годовалом свифте. Уверен, ребята из Apple починят все эти проблемы, и язык станет очень элегантным инструментом. Ну либо же неповоротливым бегемотом вслед за XCode 7.

Вернемся к Swift. Одна ночь с книгой «The swift programming language» и я готов к свершениям. Язык очаровал меня простотой, прозрачностью конструкций и скрытой мощью, позволяющей писать безопасный код (и да, они добавили приватные члены классов). Я начал писать SripteKit игрушку и…

image

Это что серьезно? Мой проект на Objective-C в 60 тысяч строк собирается всего лишь в два раза дольше, чем мой 600-строчный Hello World на Swift. Внезапно мне вспомнились те славные времена (вообще-то всего несколько месяцев назад это было), когда я работал над огромным проектом, и картинка ниже прекрасно описывала некоторые рабочие дни:



Эта недокумментированная фича языка была мне очень неприятна: я разрабатывал небольшую игрушку и часто менял некоторые захардкоженые значения с небольшими кусками логики довольно часто. И каждое небольшое изменение требовало пересборки проекта. Да, мне известно, что эту проблему можно решить множеством способов, например, вынесением констант в конфиги или созданием внутриигрового отладочного меню. Но все эти подходы требовали дополнительных усилий, и я бы предпочел сфокусироваться на основной моей задаче: создание небольшой забавной игры.

В конце концов человек может привыкнуть к чему угодно. Но компилятор снова меня поразил:



Эээ… Не может сложить два float'а… хорошо…

Для тех из вас, кто уже точит свои ножи, чтобы отучить это обезьяну-кодера от работы с захардкоженными значениями и использования одновременного float и double типов в коде хочу сказать: во-первых, CGFloat ко мне пришли из UIKit, а double из стороннего кода. Так что это не слишком экзотическая ситуация, когда вам придется миксовать эти два типа. А вынос захардкоженых значений в константы помог бы коду стать более толковым, но едва ли это спасет от удивительного кульбита, которым нас порадовал компилятор. Кончено, этот мерзавец может сложить два float'а — дело-то в том, что он укрывает от меня настоящую проблему!

Знаете, я всегда воспринимал компилятор как что-то вроде старого мудрого Гендальфа, который обьясняет глупым хоббитам, как мир на самом деле устроен.



Иногда сложно понять, что этот старикан несет. Но если вдуматься, то он действительно указывает на проблему. Продолжая метафору, компилятор Swift'а, рассказывающий мне о проблеме с суммированием двух float'ов, мне больше напоминает этого торчка из фильма Хоббит.



Черный ритуал над кодом, и, наконец, он заработал. Вот зачиненный вариант:



Я не запоминал каждый такой казус в течении разработки, но этих, думаю, достаточно для иллюстрации моей идеи.

Еще одна проблема, связанная с первой — низкая скорость статического анализа в сравнении с Objective-C. Было время, когда я отключал подсветку синтаксических ошибок в ХСode в реальном времени, так как я писал код гораздо быстрее, чем XCode успевал его анализировать (человек против машины: 1:0, хо-хо). Подлагивающие подсказки только раздражали меня. С покупкой нового мака анализ стал почти мгновенным — и я с огромным удовольствием стал использовать эту фичу. Но со Swift я снова встретил ту же проблему (2:1. человек побеждает).

Ну и наконец жемчужина моей коллекции:



Я многое повидал в жизни…
Я видел оптимизации компилятора, рушившие производительность из-за вставленного 'if (0) {… }' выражения
Я видел чудовищные баги, связанные с пропущенным 'volatile' ключевым словом
Я видел, какие жуткие разрушения может привнести неопределенное поведение языка

Но никогда я еще не видел, что бы компилятор жаловался на свою тяжелую жизнь.

Это сообщение было бы очень полезным, будь оно warning'ом. Но это критическая ошибка. Так что да, вам придется упрощать это выражение. Я бы понял эту ситуацию, если бы эта ошибка вылезла для очень длинной конструкции. Но мое выражение было менее чем 120 символов длинной. Для некоторых разработчиков такая ситуация может показаться нормальной, но я был взращен с волками языков C/C++ и x86 ассемблером. Так что для меня это выглядит странно.

Что же в сухом остатке? Мы получили язык, похожий на модные Python/Go/Ruby. Но есть ли причина начинать большой проект на нем?

Дженерики? Да, это очень хорошо, но и в Objective-C теперь есть поддержка дженериков (да, уродливая, но есть). А ребята из Go вообще говорят, что им без дженериков нормально.

Опциональные типы? По моему мнению, это очень спорная концепция. Она очень удобна, если мы обсуждаем передачу аргументов в функциях, но может оказаться болезненной, когда дело касается членов класса, которые могут быть долгое время неинициализированными (например в случае ленивой инициализации).

Передача обьектов по значению? Если вам нужна производительность — то C/C++ к вашим услугам. Если же вы хотите еще и при этом использовать опциональные значения, то, безусловно, на C/C++ это будет выглядеть несколько уродливо, но, тем не менее, возможно.

Так что эпл. Ну серьезно, выглядит так, будто вы создали язык только потому, что над вами смеялись из-за квадратных скобочек (!(«Пишите код, будто на разговорном английском», хехех) и YES/NO в Boolean. А какова цена? Теперь у нас язык с тормознутой сборкой и, порой, очень странным поведением компилятора.

Итак, старик сказал все, что хотел. Но вы, любители модных-скриптоподобных языков, не должны принимать мои слова слишком близко к сердцу: по сути Swift это хороший язык с неплохим дизайном. Все пробелмы, что я описал, могут быть зачинены без существенных изменений в языке, так что однажды они уйдут. Свифт — прекрасный язык для написания Hello World, но крупные проекты я пока не советую начинать на нем.

Комментарии (54)


  1. Ununtrium
    06.11.2015 13:11
    +7

    Проверьте пожалуйста текст спеллчекером, очень много опечаток. А так забавный текст для пятницы.


    1. aobondar
      06.11.2015 17:12

      Спасибо за замечание! Действительно вышло грязновато — постарался исправить.


  1. magmoro
    06.11.2015 13:39
    -2

    раньше действительно медленно работало автодополнение, подсветка глючила, но в последних версия все гораздо быстрее и меньше глюков, хотя иногда бывают


  1. Stepanow
    06.11.2015 14:26
    -2

    Ну если это все проблемы, то лучшую рекламу языку придумать сложно. Тот-же обратный эффект (может так и задумывалось), как от поста в защиту Go.


    1. NeoCode
      06.11.2015 14:41
      +2

      Читать такие статьи в любом случае интересно. Свежий взгляд реального программиста, попытавшегося что-то сделать на новом языке, лучше всего выявляет потенциальные недостатки этого языка, и вообще позволяет задуматься и подискутировать на многие интересные темы.


    1. aobondar
      06.11.2015 18:08
      +8

      От себя могу сказать, что все те грандиозные фичи революционного языка, из-за которых стоит бросить Objective-C и начинать работать со Swift пока не несут на деле каких то революций — по сути у нас тот же Objective-C с небольшими приятностями, вроде чуть более прозрачного синтаксиса, дженериков, безопасности работы с памятью (за которую придется заплатить if let obtainedRef = ref {} на каждый чих для нуллабл референсов). И вот эти прекрасные дифирамбы производительности на абстрактных бенчмарках — да это интересно. Но чаще всего нам придется работать со все тем же Cocoa фреймворками, и эта разница с Objective-C не будет уже такой внушительной. И так со всеми фичами — вроде и здорово и классно, но с подводными камнями и легким ощущением обмена шила на мыло при внимательном рассмотрении. А платим мы за это производительностью и тем, что приходится работать с сыроватым компилятором. Видимо это больше проблема восприятия — эпл в привычной для себя манере обещает нечто грандиозное, а показало нам неплохой язык, но после изучения действительно свежих концепций привнесенных теми же Go/Rust и иже с ними, он кажется опоздавшим к празднику жизни.


  1. PapaBubaDiop
    06.11.2015 15:24
    +2

    Птичий язык не может быть хорошим. Сделал пару проектов на Свифте, плюнул и вернулся родное лоно Obj-C. Как козу продал…


    1. NeoCode
      06.11.2015 15:53
      +3

      «Птичий» по названию :), или таки есть интересные аргументы, которыми можно поделиться с сообществом?


      1. PapaBubaDiop
        06.11.2015 16:03
        +7

        Интересных нет, все обычно.
        1) Не компилируется код после возвращения к проекту через полгода.
        2) Нельзя вольно обращаться с типами данных.

        И не надо меня клевать, птички). Свифт очень очень очень хороший язык, но лучше на нем работать года через джва).


        1. salas
          07.11.2015 04:19

          А можете подкинуть какие-нибудь примеры про типы? ObjC не знаю, может, пропускаю чего?


          1. olegi
            09.11.2015 13:52

            возможно, имелось ввиду традиционное С\C++ приведение типов?


  1. M4rkK1d
    06.11.2015 15:36
    -3

    Эээ… Не может сложить два float'а… хорошо…

    Не два Float, а два CGFloat. Если пишешь на Swift, то будь добр пиши на Swift. Т.е. используй родной Float, а не CGFloat, который перекочевал из ObjC и поддерживается просто для совместимости со старым кодом.

    Между прочим, я проверил этот код в Swift 2.0 и он работает без проблем:

    let width = 100.0
    let angle = 45.0
    let rad = width / 2 - 32
    let ptX = CGFloat(width / 2) + CGFloat(cos(angle) * rad) // ptX = 59.45579579871914
    


    Скорость компиляции постоянно растет. А скорость вашего кода может быть улучшена на несколько порядков если следовать простым правилам Optimizing Swift Performance.

    На счет Expression is too complex to be solved at reasonable time... я без понятия. Никогда не встречал. Подозреваю, что это крайне редкий случай. Мог бы показать, что у него там такое монструозное.

    И всё нечего больше сказать?


    1. aobondar
      07.11.2015 00:22
      +2

      А вы присмотритесь чуть внимательнее — в тексте width — это не double, а CGFloat, пришедший к нам из недр SpriteKit. Именно поэтому ваш код собрался без проблем — по умолчанию Swift константу 100.0 сделает double. Многие бы и рады писать на чистом Swift, да внезапно вся махина Cocoa стала с точки зрений новых концепций языка легаси, а без нее Swift не самодостаточен. Именно в этом проблема, на мой взгляд, большинства дифирамб языку — они рассматривают прекрасный свифт в вакууме (а он действительно хорош), а не в связке с великим и ужасным Cocoa.


      1. M4rkK1d
        07.11.2015 04:43

        Странно, а я тут переписал чтобы width был CGFloat, и всё равно работает…

        let widthDouble = 100.0 // Double by default
        let angleDouble = 45.0 // Double by default
        
        let width = CGFloat(100.0)
        let angle = CGFloat(45.0)
        let rad = width / 2 - 32
        let ptX = CGFloat(width / 2) + CGFloat(cos(angle) * rad)
        


        Вы на основе чего строите предположения, что Swift плохо работает с Cocoa?
        Я вот пишу уже много месяцев на Swift и любые проблемы решаются в считанные минуты…


        1. aobondar
          07.11.2015 11:36
          +1

          Значит нужно взглянуть еще внимательнее: делаете let angle = 45.0, и код не соберется. Кстати, обновив XCode (чего я делать конечно не хотел из-за его все большей тормознутости с каждым релизом. Но эксперименты — дело святое), я тоже проверил и к чести ребят из эпла теперь на этом примере ошибка выдается правильная. С другой стороны, я встречал и другие очень похожие проблемы с сокрытием ошибки приведения типа выражения внутренней конструкции внешней, так что не берусь утверждать, что проблема разрешена совсем.

          Проиллюстрировать хотя бы одну из проблем с Cocoa могу вашими же словами:

          Если пишешь на Swift, то будь добр пиши на Swift. Т.е. используй родной Float, а не CGFloat, который перекочевал из ObjC и поддерживается просто для совместимости со старым кодом.

          Правильную вещь ведь говорите, только куда нам деваться, если UIKit стоит двумя ногами на Foundation, а там свои типы, пусть и в красивых оберточках, но это не double из Swift


  1. slutsker
    06.11.2015 17:48

    Для меня появление Swift было очень важным «за» в пользу начать писать приложения под iOS. Пробы на Objective-C меня сильно оттолкнули.
    Конечно, Swift сейчас еще зеленый, да и выход Swift 2 не дает собрать уже имеющиеся приложения без большого числа правок, но хочется верить, что дальше все будет только лучше — мы точно нащупали дно)


    1. semenyakinVS
      06.11.2015 18:44
      -1

      А в чём киллер-фича свифта?


      1. slutsker
        06.11.2015 18:46
        +2

        Не знаю как для других, но для меня это был именно простой синтаксис.


        1. BOOMik
          07.11.2015 00:01
          +1

          Согласен, тоже начал писать под iOS с появлением Swift.
          Конечно после Java & .NET видно что язык еще очень молодой и сырой, точнее 2.0 уже более-менее, год назад была хуже ситуация.
          С ObjC связываться не хотелось, уж больно мне не нравится его синтаксис, а тут хотя бы более-менее привычный и перейти на него проще.


      1. PapaBubaDiop
        06.11.2015 20:14

        Точек с запятой нет, как в ФОРТРАНе, это бесценно.


      1. DmitrySpb79
        06.11.2015 21:30

        Ну как в чем… Работодатели требуют :)

        Когда количество контор где требуют Swift, перевалило (по ощущениям) за 30%, я понял что пора.


      1. vitalybaev
        06.11.2015 21:39
        +3

        Ну, хотя бы писать

        if(string == "somestring")
        

        намного приятнее, чем
        if([string isEqualToString:@"somestring"])
        

        Плюс эти знаки собаки постоянные у строк. Простой синтаксис — это не так уж и мало в разработке. Однако ниже я написал неприятный момент со Swift из-зак которого продакшн-проекты я продолжу писать на Objective-C


        1. hippeistudio
          07.11.2015 13:32
          +1

          Еще так можно :)

          if string == "somestring"
          


  1. nepx
    06.11.2015 17:56
    -2

    Бред какой-то, не портите мне пятницу!


  1. vitalybaev
    06.11.2015 21:31
    +4

    Есть еще один не очень приятный момент. Начал я как-то переписывать свой проект на 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-й ли год на дворе.


    1. semenyakinVS
      06.11.2015 22:48

      Хм… По поводу вкомпиливания рантайма в бинарник — интересно зачем? Чего нельзя сделать динамическую библиотеку в качестве временного решения (потом, как я понимаю, часть рантайма свифта как-то перетечёт в либы маковских осей… или я не правильно понимаю?).


      1. creker
        06.11.2015 23:07

        Подозреваю, что свифт слишком молод и сильно меняется, ломая совместимость. Засунуть либы в ось это значит отказаться от обновлений частых и залочить все API — обновления не должны ломать ничего в приложениях, которые скомпилены для старых версий. А с этим у свитф не очень.

        Как доживет до стабильно состояния, так и залочат. Тем более сами это говорят.


    1. aobondar
      07.11.2015 11:54

      Это действительно печально, учитывая, что и сами эпловцы понимают важность проблемы толстых бандлов (в презентации On Demand Resources на WWDC вполне разумно расписали). Но тут наджеда на то, что язык устаканется действительно более-менее быстро.


    1. hippeistudio
      07.11.2015 13:44

      Приложение на Swift 1.2 из 7ю вью контролерами (еще пару Navigation и Tab Bar) занимает 26 мегабайт, но там еще ресурсы (немаленькие изображения) занимают 8 мегабайт.


    1. kachora
      10.11.2015 11:22
      +1

      Статья от SEP 29TH, 2014, будем надеятся, что во 2ой версии, пофиксили эту «фичу».


      1. vitalybaev
        10.11.2015 12:57

        В любом случае, для совместимости с iOS 7-8 рантайм должен будет продолжать поставляться с приложением


  1. creker
    06.11.2015 23:10
    +2

    До сих пор не могут заставить себя перейти на него и даже начать баловаться с ним. Преимуществ самого языка — для меня их нет, objc прекрасно читается и пишется после долгого опыта работы с ним, а фичи меня ничем не подкупают — они ничего не меняют, а отчасти заставят лишь спотыкаться по первости. Все эти дженерики, ноннулаб переменные, хитрые энумы и прочие фенечки — все это забавно скорее для тех, кто начинает со свифта. Ну и конечно для меня ставит крест на любом применение факт нестабильности самого языка и общей глючности всего со свифтом связанного и тот факт, что он до сих пор требует тащить с собой тонну библиотек.


  1. stepanp
    07.11.2015 02:08
    -4

    Swith без поддержки приватных членов класса, хм....

    Какой ужас, как же без них жить то?


    1. semenyakinVS
      07.11.2015 02:27
      +1

      Если это был сарказм, то спрошу: инкапсуляция это по-вашему пустое слово, никак не связанно с ООП?


      1. stepanp
        07.11.2015 03:09
        -1

        Инкапсуляция это не только модификаторы доступа. А их значение сильно преувеличено, по крайней мере когда речь заходит о скриптовых и скрипто-подобных языках.


        1. semenyakinVS
          07.11.2015 09:31
          +1

          А чем скриптовые и скрипто-подобные языки принципиально отличаются от любых других в смысле использования модификаторов доступа? Модификаторы доступа позволяют управлять вниманием читающего код программиста, указывают на то, какие переменные могут меняться в контексте определённого поведения… Да, это можно эмулировать другими средствами, но и ООП можно эмулировать в рамках функционального подхода. Зачем это делать прямо специально?

          Единственные две видимые для меня причины, по которым модификаторы доступа не включаются в язык — это ускорение разбора кода программы и упрощение языка с точки зрения его изучения (только изучения грамматики — не написания кода). Если первую причину я ещё могу понять, то вторая — упрощение ради упрощения, чтобы программисту меньше слов языка учить нужно было — мне не очень ясна. Тогда нужно braindfuck учить — всего четыре, кажется, слова, вообще отличный язык.
          Утрирую, конечно, но меня всегда удивляло отсутствие модификаторов доступа в некоторых серьёзных языках — в том же objective-C, например, в котором приходилось имитировать модификаторы, разбивая поля на те, что в m-файле (приватные) и те, что в хедере (публичные).


          1. creker
            07.11.2015 15:08

            Справедливости ради, переход на приватные поля классов только в m файлах для меня только плюсы несет. А публичные поля только через свойства. Это и сокрытие реализации, и очистка интерфейса от деталей реализации. Естественно, рантайм все равно позволит получить все поля класса, где бы они не были.


      1. Deepwalker
        11.11.2015 11:42

        Swift не ООП язык. А классы, мне кажется это временная штука, и с какого-то момента писать их станет моветон.


        1. semenyakinVS
          11.11.2015 23:10

          А что придёт на смену ООП? Что-то вроде прототипного подхода?


          1. Deepwalker
            12.11.2015 11:30

            Протоколы — developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Protocols.html

            Такая же тема как в Go, Rust etc. Я не знаю как в общем этот подход называется, к сожалению, но он гораздо гибче чем ООП наследование.


            1. creker
              12.11.2015 12:58

              Обычные такие интерфейсы как в том же C# с поддержкой множественного их наследования — действительно удобно и, в общем-то, это ООП как оно есть. Собственно, протоколы это фича, пришедшая из Obj-C — он тоже не ООП теперь? Фишка Go не в том, что там интерфейсы есть, а то, что не нужна их явная реализация. Есть методы — значит реализовал.

              Классы никуда не делись и в Go. Там просто нет наследования, но есть встраивание как костыль на замену. Структура с методами и интерфейсами — чем не класс. Никуда классы не денутся и из swift — это обычный мультипарадигменный язык, в том числе ООП, которое там обычное и всем привычное.


              1. Deepwalker
                12.11.2015 13:16

                Обычные такие интерфейсы :) Структура не класс — можно например наследовать структуру?

                Явная или неявная реализация это дело то десятое. Например в Go легко с этой неявной фигней попасть в проблемы, так что это не фишка, это беда, мое мнение. Но классов в Go нет. Нет, структуры это не классы. Нет, даже то что там где-то можно объявить нечто похожее на методы, не делает структуры ООП классами.

                Протоколы это не фича из objc, это современный тренд, который повсюду. Просмотрите все языки которые в тренде — там везде так или иначе используется эта фишка вместо наследования. Вместо, не вместе.

                Смотрел доклад по свифт эппловский — там основной упор на то как делать без классов. Так что классы это временное явление, чтобы голову сразу не ломать людям. Вам же скажи что ООП всё, ой что начнется. А тут все прилично — вот вам ООП, это прям практически привычный вам язык, видите, классы. Ничего страшного, вперед, это просто красивый objc, новенький, но такой же. Ой смотрите, а тут еще вот так можно, и нужно кстати, но вы пока не нервничайте, ООП тут, да, пока.

                Одни только страдания народа за private явно это демонстрируют — нельзя вот так сразу сделать ООП всё, нельзя. Хотя всем уже стало понятно, что он всё, но будем это доносить постепенно. Apple умные, знают же что вот там сразу если вывалить истину, язык не полетит.


                1. creker
                  12.11.2015 14:10

                  Это все какие-то гадания на кофейной гуще. ООП никуда нигде не делось. То, что модные языки немного по-другому его делают, ничего особенно не меняет. Swift в первую очередь мультипарадигменный язык, а что использовать будет пользователь уже его дело, а не Apple. Они просто перенесли все из ObjC и это именно его фишка, а не тренд, потому что им надо вообще сохранять обратную совместимость с их огромным ООП Cocoa. Никто это менять не станет, а значит и из языка это не исчезнет.

                  Что до Go, то единственная проблема там отсутствие наследования привычного — вместо наследования реализации используется наследование интерфейсов, что тоже вполне обычная вещь. Но все остальные атрибуты на месте в привычном виде — инкапсуляция, полиморфизм, абстракции. Даже можно заключить, что все является объектом, потому что интерфейсы можно реализовать даже для int.


    1. Mixim333
      07.11.2015 09:29
      +1

      Swift не пробовал, но в своем коде на C# я без protected\private жить не могу — позволяют скрывать от самого же себя детали реализации и мишуру (стараюсь не писать методы больше 100 строк кода, поэтому нередко на 10-20 публичных методов у меня создается 50-70 служебных приватных)


      1. andrejlazarev
        10.11.2015 11:32

        В ObjectiveC этот момент классно решается разбиением кода на интерфейс и реализацию.


        1. semenyakinVS
          10.11.2015 11:56

          На самом деле, такое разделение в objective-С мне всегда казалось неудобным. Прежде всего из-за того, что приходится бегать по двум файлами — ведь как публичные так и приватные поля и методы могут использоваться в как публичных так и приватных методах.

          Впрочем, при корректном проектировании кода такая проблема, скорее всего, не возникает.


      1. andrejlazarev
        10.11.2015 11:38
        +1

        Сплошной код класса на Swift после этого несколько дезориентирует. Может IDE как-то должна активно помогать в навигации по всему этому, но пока в XCode не больно много инструментов для этого. Переходы по методам/полям + //MARK:.


    1. hippeistudio
      07.11.2015 14:05
      +1

      У свифта есть поддержка приватных членов класса


  1. hippeistudio
    07.11.2015 13:24
    +2

    Эсли честно то статья немного опоздала, так как в Swift 2.0(Xcode 7) а то и в Swift 1.2 большинство проблем уже исправлено. Опциональные типы для членов класса удобная и безопасная вещь так как ты «точно» знаешь что может быть nil а что нет. Сначала немого непонятно было как с ними работать после Java 7(Android) но сейчас их очень не хватает когда пишу на Java 7. Насчет тормознутости Xcode 6.4 при работе со Swift 1.2 — есть немного, но Xcode 7 работает намного шустрее. Так же было бы интересно узнать как обстоят дела в AppCode при работе со Swift.


    1. kachora
      10.11.2015 11:17

      Да, хотелось бы узнать у автора, использовал ли он старый 1.2 или свежий 2.1?
      И что публика скажет по поводу Appcode от JetBrains если использовать ее как IDE для серьезных проектов.
      Сам только встал на этот тернистый путь изучения, ios разработки, года 4 назад был момент начать obj-c, но испугался и бросил, здесь же в swift, как показалось (после js) все чуть проще.
      Думаю, для приложений аля заметки и напоминалку с красивым интерфейсом, он будет самое то.


    1. aobondar
      11.11.2015 13:45

      Судя по моим экспериментам и опыту работы со Swift, действительно это о Swift 1.2. На данный момент это и правда больше историческая заметка о молодых (читай лихих) годах свифта. Но честно говоря, субъективно и Swift 2 часто вызывает лично у меня ощущение, что компилятор играет против тебя — хотя здесь очень сложно оценить, где кончаются проблемы языка и начинаются проблемы восприятия разработчиком.


  1. cypok
    10.11.2015 12:10

    Пишу профессионально на Scala, писал пару недель на ObjC пять лет назад, на досуге почитываю Haskell и вот пару недель назад решил попробовать выучить Swift и написать чего-нибудь под iOS.
    Так вот, лично мне очень понравились функциональные фичи языка: алгебраические типы данных (enum), map/filter/reduce, лямбды и др. И все это достаточно неплохо сделано, что позволяет вытворить всякие вещи, типа Swiftx/Swiftz.


    1. andrejlazarev
      11.11.2015 12:15

      А вот кстати интересный пример. В Swiftz есть операторы которые вообще не понятно как с клавиатуры вводить: •, ?, ?. По моему вменяемые разработчики должны такого избегать. Зачем это вообще в язык добавили? Чтобы кто-нибудь мог brainfuck.swift реализовать? :)


      1. cypok
        11.11.2015 13:32

        Эти операторы мне конечно тоже не нравятся, но всегда либо есть альтернативное написание, либо его можно самому добавить.

        Зачем это вообще в язык добавили? Чтобы кто-нибудь мог brainfuck.swift реализовать?
        А причем здесь язык? Это разработчики Swiftz выпендриваются. Сама возможность называть операторы/методы/классы с использованием всего многообразия юникода сейчас доступна во многих языках, это не есть проблема.