@Helecta5 июн 2014 в 06:28

Знакомьтесь, Swift!

5 мин

109K

iOS * Xcode * Swift *

Из песочницы

+47

Комментарии 63

@Dreddik 5 июн 2014 в 06:42

Что значит «с памятью возиться не надо»? Как будто со времен arc надо было возиться. А ведь здесь тот же arc, и можно так же легко сделать retain cycle. Так что никогда не будьте беспечны насчёт памяти.

@imater 5 июн 2014 в 06:49

Читабельность повысилась. Ощущения — как перейти от JavaScript к CoffeeScript.

НЛО прилетело и опубликовало эту надпись здесь

@aavezel 5 июн 2014 в 08:00

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

@zserge 5 июн 2014 в 08:35

Насчет производительности кода — то кажется всех немного обманули. Согласно простейшим бенчмаркам свифт в шесть раз медленнее в самом лучшем случае при включенных оптимизациях, а без оптимизаций до 46 раз медленней по сравнению с Obj-C. www.splasmata.com/?p=2798

@codeorchestra 5 июн 2014 в 14:33

Миллион иттераций цикла и аппенд строк все же не по показатель… И ожидаемо. И все равно будут писать на Swift :)
Думаю swift — это как groovy или scala на платформе java. Лучше писать на нем какой UI и и где нет таких требований к производительности. А если нужно миллиард циклов и где-то проседает производительность то пишем пару классов на более низкоуровневом языке. Ведь можно смешивать.

@ZiGR 5 июн 2014 в 19:00

Вообще, меня слегка удивило то, что они вообще сказали, что Swift быстрее. Obj-C — компилируемый язык, а в процессе компиляции можно делать что угодно. В конечном итоге всё равно будет генерироваться код для процессора, хоть из Obj-C, хоть из Swift.

@corristo 6 июн 2014 в 05:09

twitter.com/nadavrot/status/474659423441678336

@agee 6 июн 2014 в 12:03

А вот это уже интересно. Хотя это и казалось очевидным, когда говорили о большей продуктивности. Но тут подумалось «мало ли, может в Apple знают, что делают.» Выходит, многое нужно проверять собственноручно, а не вслепую верить заявлениям.

@zserge 8 июн 2014 в 16:42

Вот еще интересный замер скорости сортировки массива: stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
или stackoverflow.com/questions/24102609/why-swift-is-100-times-slower-than-c-in-this-image-processing-test
Говорят -Ofast улучшает картину значительно, но swift тогда игнрориует множество потенциальных ошибок в коде, что тоже нехорошо.

@agee 9 июн 2014 в 10:28

Возможно, необходимо использовать сишные вставки для подобных операций? Вспоминается, как некогда вполне успешно использовались ассемблерные вставки в C/C++ коде. За несколько минут серча нашел пока только такой топик на SO: stackoverflow.com/questions/24004732/how-to-call-c-from-swift
Пока создается впечатление, что swift вообще не предназначен для хоть сколько-нибудь низкоуровневых операций. В приведенных Вами ссылках проскакивал комментарий, мол, хочешь использовать сортировку — используй встроенную. Надо бы, кстати, сравнить производительность работы с NSDictionary у Objective-C и у Swift'а. Разгребусь, будем разбираться…
П.С.: спасибо за полезные ссылочки.

@Homakov 5 июн 2014 в 17:53

Кофе компилируется в JS, и скорость та же как если бы писался JS сразу

НЛО прилетело и опубликовало эту надпись здесь

@Homakov 7 июн 2014 в 17:38

Выглядит плохо != плохо работает. Можете показать конкретные вещи которые плохо оптимизированы в этом компиляторе? Делающие Кофе существенно медленнее?

@Renius 8 июн 2014 в 07:22

Обычно в таких случаях приводят хотя бы один пример.

@norlin 5 июн 2014 в 16:39

Вот уж дело привычки! По мне так JS читабельнее и удобнее. Да, чуть больше кода иногда надо писать. Зато точно уверен, как оно будет работать.

@sidristij 5 июн 2014 в 06:49

Я не вижу includes. Их, что, я надеюсь, больше нету? =)

@silvansky 5 июн 2014 в 07:14

Да, теперь — модули. Внутри модуля инклюды не нужны.

@Helecta 5 июн 2014 в 07:14

Нету) Остался только import для подключения фреймворков:

import FrameworkName

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

@sstepashka 5 июн 2014 в 06:50

В Obj-C, чтобы сделать простую операцию конкатенацию строк, нужно было изгаляться следующим образом:
cell.text = [NSString stringWithFormat:@"Habrapost %@", indexPath.row];

Это не конкатинация, конкатинация это

NSString *string = ...;
string = [string stringByAppendingString:@"Hello"];

@ivan4th 5 июн 2014 в 07:34

Отмечу важное свойство языка: эксепшнов нет. Без полноценного GC, впрочем, от них, в зависимости от неаккуратности программиста, может быть немалый вред в связи с утечками — но, в любом случае, эту особенность стоит иметь в виду.

@sstepashka 5 июн 2014 в 07:42

На мой взгляд, при написании клиентских приложений лучше использовать поменьше исключений и ставить просто проверки на ошибки.
Для iOS-разработчиков отсутствие GC не так уж и ужасно.

P.S.: Ну и никто не запрещается отдельные куски писать на Objective-C, C, C++

@cigan 28 июл 2014 в 12:26

Если вам нравится загрязнять код и вы пишете только 100-строчные конвертеры — тогда да. Любое мало-мальски сложное приложение может выбросить мириад исключений по бог знает каким причинам, причём не везде и не всегда нужно эти причины проверять.
Скажем, если у вас сложная функция «посчитать баланс» и в ней вызывается 10 подфункций, а потом одна из них «валится», не имеет значения что там произошло — мы уже не можем посчитать баланс, поэтому ловим проблемы на уровне «посчитать баланс» и там сообщаем подробности. А теперь представьте тот суровый код, который нужно вставить как в каждую из 10 подфункций, так и в главной функции, чтобы предусмотреть ВСЕ проблемы кода!
Без «исключений» программа превращается в неуправляемый, дырявый атавизм.

@corristo 29 июл 2014 в 05:40

Optional/Either и аппликативные функторы лучше, чем исключения.

@0xGreg 5 июн 2014 в 10:33

Каким образом исключения могли бы привести к утечкам при использовании ARC (в Swift по-умолчанию)?

@corristo 5 июн 2014 в 12:24

Вот так: clang.llvm.org/docs/AutomaticReferenceCounting.html#id51

@corristo 5 июн 2014 в 12:28

не успел отредактировать, правильная ссылка: clang.llvm.org/docs/AutomaticReferenceCounting.html#exceptions

@0xGreg 5 июн 2014 в 12:33

Как интересно. Мой опыт связан в основном с Objective-C++ и я вижу отсутствие утечек связанных с возникновением исключений. А оказывается что для Objective-C++ по умолчанию включена опция "-fobjc-arc-exceptions" которая делает возможным exception-safe для ARC.

@corristo 5 июн 2014 в 12:35

В Objective-C исключения должны вести исключительно к крэшу приложения, являясь индикатором ошибки программиста. В C++ же в этом смысле полная свобода и поэтому этот флаг включен по умолчанию.

@0xGreg 5 июн 2014 в 12:40

Да, да. Я в курсе этого подхода в ObjC. Не удивительно что в Swift исключений просто нет да и миксовать Swift c С++ в одном файле нельзя.

@corristo 5 июн 2014 в 12:26

Если в дополнение к имеющемуся Optional реализовать еще и Either (система типов это позволяет), исключения становятся вообще не нужны

@Zeliret 5 июн 2014 в 08:04

Неужели это произошло… дьявольский язык уходит в прошлое? В эпоху C#, Python и Java (Scala) ObjC смотрелся как ужасный монстр, совершенно не читаемый.
Свифт выглядит симпатично, просто и понятно, но блин… очередной язык :)))

@Helecta 5 июн 2014 в 09:03

@Webius 5 июн 2014 в 08:41

Я когда-то хотел написать свой язык ~~с блекджеком и..~~ До сих пор пишу на видуманом синтактисе разние программы) Я наверное сумашедший

@leMar 5 июн 2014 в 09:33

Да нет, вы просто не битый всякими «я создам такое же, но лучше», программист )
Каждый программист, в какой-то момент хочет написать свои CMS \ браузер \ язык

Пишите. Через месяц другой отпустит )

@ChapayHabr 5 июн 2014 в 14:47

Если вас что-то не устраивает в текущих языках и есть иде как это можно улучшить, то почему бы не попробовать ))
lua, python, c, c++ Насколько я помню эти языки разрабатывались или одиночками или небольшими группами энтузиастов

Так что удачи )

@gigimon 5 июн 2014 в 09:17

А программы написаные им можно будет запускать на более старых версиях ios и os x? Или ios8+ и 10.10+?

@Helecta 5 июн 2014 в 10:11

Только, что залила приложение на ios 7, работает нормально.
Нашла ответ инженера, который занимается разработкой Swift:

iOS 7, Mavericks, and later.

@pleax 5 июн 2014 в 12:30

Да, можно. Важен deployment target, конечно. Но это вопрос не компилятора.
Например, приложение WWDC написано на Swift. На iOS7 работает. За более ранние на скажу.

@AddAloner 5 июн 2014 в 09:34

В XCode 6 в ступор поставило переработанное окошко New, в котором больше нет раздела Cocoa. Не понятно куда идти чтобы создать протоколы/категории

@0xGreg 5 июн 2014 в 10:28

Честно говоря я и в Xcode 5 не пользовался этим. Просто добавлял новый файл и писал код.

@mopsicus 5 июн 2014 в 10:13

Не стоит забывать, что вся эта красота ещё не вышла из беты, так что многие косяки уберут к моменту релиза

@DnV 5 июн 2014 в 12:15

Кстати, если тип известен, то можно опустить имя структуры/класса:

cell.detailTextLabel.textColor = .purpleColor()

Правда пока так автоподстановка не работает.

@garbuz 5 июн 2014 в 12:56

@formatus 5 июн 2014 в 13:06

Автодополнение работает пока очень странно…

@Dreddik 6 июн 2014 в 12:10

По-моему, оно для всего в XCode 6 немного странно работает

@formatus 5 июн 2014 в 13:10

Столкнулся с двумя ошибками, в только что созданном проекте:

SetAppThreadPriority: setpriority failed with error 45
Unknown class SelectorVC in Interface Builder file.

Stackoverflow молчит. Кто нибудь знает как поправить?

@Ku6ep 5 июн 2014 в 16:33

По первым впечатлениям — язык очень компактный и достаточно удобный.
Многие вещи находятся интуитивно при наличиии опыта в Objective-C.
Пока что много странных глюков и некоторые вещи не работают как хотелось бы (тот же code suggestion к примеру) но бетта же, так что остается подождать.
Начал учить и ковырять. Текущий проект буду стараться переводить сразу на Swift, потому что Apple, как правило, не презентует то, что не будет использоваться как основной инструмент, в самом ближайшем будущем.
И спасибо за статью. Ничего сложного, но лишний мотиватор для попробовать.

@m4rr 6 июн 2014 в 19:04

В одной из сессий WWDC, кстати, говорили, что ObjC останется «first-class citizen».

@agee 9 июн 2014 в 10:37

Интересно, до каких пор? В этой статье, например, в заголовке написано, что их цель — замена. appleinsider.com/articles/14/06/04/apples-top-secret-swift-language-grew-from-work-to-sustain-objective-c-which-it-now-aims-to-replace Хотя, может, и чушь написали.

@0xGreg 6 июн 2014 в 03:28

Objective-C девелоперы устарели. Пожалуйста, относитесь к ним с уважением.

@Yuketsu 6 июн 2014 в 06:31

Для сравнения, написал одно и тоже приложение на двух языках Obj-C и Swift.
В результате на Swift кода получилось в два раза меньше и файлов тоже в два раза меньше.
Быстродействие не увеличилось, а возможно даже немного уменьшилось. Кстати, Swift хорошо проявляет себя при работе с Metal, там он действительно показывает скорость повыше чем Obj-C.
И конечно, не обошлось без пары забавных моментов, основанных как раз на том, что он не ловит эксепшены.

Например: Если взять список треков с iPod Player и периодически совершать skipToNextItem();, то при достижении границы массива, Obj-C останавливает воспроизведение, а Swift вылетает с fatal error.

Но я уверен, что к публичному релизу все такие моменты будут исправлены ;)

@0xGreg 6 июн 2014 в 06:48

Что-то точно исправят, однако напрягает отсутствие модификаторов доступа. Обещают конечно добавить со временем. Будем ждать.

@corristo 6 июн 2014 в 08:01

Семантически исключения в Objective-C как раз должны ронять программу без вопросов, нельзя их просто глушить через try/catch

@sansay 7 июн 2014 в 19:56

понятно что файлов в 2 раза — .h +.m -> .swift… но по сути за счет чего в два раза то кода меньше стало? ведь поменялся синтаксис, но все вызовы методов uikit, делегаты и тд и тп тоже самое. Реально в 2 раза?

@scumware 6 июн 2014 в 21:57

Как документацию почитать?
Предложило поставить iTunes — поставил, но нажатие кнопки «view in iTunes» к нужному результату всё равно не приводит.

@DevAndrew 7 июн 2014 в 19:27

Вот ссылка на документацию в формате html.

@sansay 7 июн 2014 в 19:51

obj-c очень даже читабелен (для читабельности язык не обязан быть схож с java, c или python)… не знаю, как люди в этом языке увеличенную читабельность увидели, как по мне после obj-c просто вырви глаз… к примеру убоги эти разрывы внутри скобок (didFinishLaunchingWithOptions):
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: NSDictionary?) -> Bool
намного читабельней эта строка
— (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions

@mibori 8 июн 2014 в 23:08

первое, за что я полюбил objc, так это за именование методов (сообщений).

такой способ мне нравятся за то, что самодокументируют код.

— (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
означает [delegate application:app didFinishLaunchingWithOptions:dict]
означает «делегату — приложение app закончило запуск с опциями dict»
довольно читабельно, на мой взгляд.