Comments 83
Swift быстр (скорость реализации некоторых алгоритмов в 3,9 раза больше, чем на Python)
Почему здесь приведено сравнение скорости с питоном, а не С, objective-C или хотя бы с Java? Питон же интепретируемый. Или Swift не настолько быстрый, чтобы сравнивать с компилируемыми языками?
time go build -o test-go go/test.go
0.55 real 0.57 user 0.12 sys
time swiftc -O -o test-swift swift/test.swift
0.35 real 0.30 user 0.03 sys
time c++ -O3 -o test-c cplusplus/test.cc
0.56 real 0.51 user 0.04 sys
time ghc -O3 -o test-hask haskell/test.hs
Linking test-hask ...
0.46 real 0.34 user 0.10 sys
Например, «swift script.swift»
По-моему это все равно что: «Русский язык быстр (скорость говорения некоторых предложений в 3,9 раза больше, чем на английском)».
Давайте по-честному: единственная причина успеха и вообще существования Swift — это необходимость иметь обратную совместимость с неимоверно вырвиглазным и отсталым Objective-C (см. ваш же скриншот из начала статьи). Если бы не жёсткие рамки обратной совместимости вкупе с ущербностью Objective-C, никакого Swift не было бы. Был бы Objectve-C нормальным — никто бы с него не переходил из-за смутных плюсов; не было бы обратной совместимости — никто не стал бы выкидывать тонны написанного кода. Просто Swift дал возможность огромному числу программистов писать на нормальном языке.
Вот когда Swift кому-то понадобится за рамками яблочных платформ, можете начинать заливать про революционность, стимулы и далее по списку и сравнивать с Java, которая отжала огромный кусок от C++ именно за счёт новых подходов; ну или хотя бы с C#, который как Java, только нормальнее. Пока же этот Swift со всеми своими "стимулами" никому не нужен за рамками яблочных платформ.
Скорость с питоном они сравнивают, ох...
Про кросслпатофрменность сейчас явно кто-нибудь вам ответит что Hello world можно запустить на андроиде! и на Windows через новый встроенный линукс. Про сравнение с питоном — чуть чай не пролил от смеха :-).
Нет.
хотя какие комменты можно ожидать от работника Xamarin… :) боитесь потенциального конкурента.
Ну когда свифт на андроиде сможет легко интеропаться с кучей уже написанных 3rd party на джаве, включая UI контролы и дизайнер (т.е. предоставит красивый языковой враппер) и когда IDE будет поддерживать такие же возможности рефакторинга как idea/android studio тогда поговорим :-). И я молчу уже о Windows и UI фраемворках для него.
Ничего не понял — как это решает проблему "подключить быстро любую нативную 3rd party на java в мой Android Swift проект".
Ну ок, репозиторий с 4 звездочками, вижу действительно нужно.
Ждем от вас что-нибудь кроме helloworld и упреков в боязни конкурентов.
Google is said to be considering Swift as a ‘first class’ language for Android
About the time Swift was going open source, representatives for three major brands — Google, Facebook and Uber — were at a meeting in London discussing the new language. Sources tell The Next Web that Google is considering making Swift a “first class” language for Android, while Facebook and Uber are also looking to make Swift more central to their operations.
http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swift/
.net-у такое и не снилось :)
.net по идее мог быть из коробки в Андроиде ;-) Есть историческое гугловое письмо на это туему. Ну а swift first class это не более чем слух, тем более после того, как суд недавно отказал Ораклу гуглу вообще не имеет смысл вводить новый язык забивая на огромную тучу существующего кода комьюнити.
http://www.fosspatents.com/2011/07/judge-orders-overhaul-of-oracles.html
One of the most interesting passages in today's order quotes from an October 2005 email by Google's Android boss Andy Rubin:
"If Sun doesn't want to work with us, we have two options: 1) Abandon our work and adopt MSFT CLR VM and C# language — or — 2) Do Java anyway and defend our decision, perhaps making enemies along the way"
Это как-то опровергает мою мысль? Я не ругаю свифт, мне он нравится :) Вон недавно сказали что введут async/await в него в 4ой версии. Но на андроиде написано огромное количество библиотек, костылей и т.п. На это нельзя забить и сделать язык со своим гуёвым фраемворком или кривым интеропом. PS: ой, я подумал вы из ветки про андроид.
Киллер-фича свифта — обратная совместимость с обж-с. К сожалению, это приводит к некоторым странным фичам: повсеместное позднее связывание, странная логика попадания имён аргументов в сигнатуры, многословные названия методов… И эти странности идут в компании с ломанием обратной совместимости (во второй версии просто взяли и поменяли смысл ключевого слова), сыростью компилятора (припоминаю статью с экспоненциальным ростом времени компиляции при использовании литералов словаря), кросс-платформенности как таковой нет… За рамками яблок смысла в свифте примерно ноль. Свифт пытается догнать современные языки, а не совершает революции.
И что такого особенного в Swift для обратной совместимости с ним? Чем это мешает языку?
А свифт выглядит как снтаксический сахар для Obj-C из-за вот таких моментов:
let cell = tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as UITableViewCell
Для примера, тот же код на C#
var cell = tableView.DequeueReusableCellWithIdentifier("Cell", indexPath);
Из-за совместимости с Obj-C в плане семантики методов, которой несколько пожертвовали в Xamarin, язык получился многословный.
Это что было сделано для удобства? Ох уж эти смалталки…
По Swift — если вы про именованный аргумент, то я ниже ответил.
Под вложенностью я имел ввиду результат вызова метода, передаваемый как параметр для вызова другого метода. Что-то вроде:
[view animateWithDuration: [obj2 gimmeDuration] animation:[obj2 gimmeAnimation]] Что лично для меня не читается труднее чем: view.animateWithDuration(obj2.gimmeDuration(), obj2.gimmeAnimation())
в случае языка с пропертями, на которые похожи ваши геттеры это было бы
view.animateWithDuration(obj2.gimmeDuration, obj2.gimmeAnimation)
по-моему, разница тут существенная в восприятии
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:urlString]];
UIApplication.SharedApplication(new NSUrl(urlString));
Это еще для NSUrl не надо делать [[NSUrl alloc] init]
UIApplication.SharedApplication.OpenUrl(new NSUrl(urlString));
Опять-таки, лично для меня код на ObjC читается легко и приятно. Не хуже чем нижний пример, во всяком случае. А вот если нужно [[NSUrl alloc] init] делать, тогда конструкцию пора разбивать на две строки. Читаемость только выиграет, кстати.
Все, кто постоянно пишет на Obj-C «легко» читают его. Более того, я даже лисп легко читал, когда писал на нем. Но трудно передать тот кайф, когда я с Obj-C вернулся на C#. Не единственной, но довольно значимой причиной этого кайфа было отсутствие необходимости постоянно считать скобки.
Но писать надо по-другому, что есть, то есть. Выше вы написали, что ObjC провоцирует вложенность. По-моему, наоборот. Провоцирует выносить в отдельные переменные, особенно конструкции типа [[Class alloc] init] Код длиннее получается, зато каждая отдельная строка — проще.
Почему в c# "WithIdentifier" является частью метода, а не называется просто "GetDequeueReusableCell"?
Не синтаксис (он действительно вырвиглазный), а именно семантика. Возможность отправлять сообщения вместо вызова методов, динамика, рефлексия, возможность отправлять сообщения null-у. Всего этого мне очень не хватало в C++.
А Swift… он конечно аккуратный такой, но меня пугает, что в последней редакции они выкинули из языка даже такие основы основ как операции инкремента и декремента (++ и --). И не то чтобы сложно написать i=i+1, но вот для кого это было сделано? Как будто не для программеров, а для каких-то домохозяек, которых пугают непонятные символы.
Ну почему, вариент i += 1 еще доступен :)
Что до Swift и изъятия ++ и --, это неоднозначное на первый взгляд решение. Разработчики в результате обсуждения решили убрать по нескольким причинам.
1) Реальной пользы мало, i += 1 не намного длиннее, так что конструкция была добавлена скорее по привычке
2) Наиболее частое использование — увеличение индекса при итерации коллекций. Итерация в Swift делается другими, более безопасными и изящными способами.
3) Часто использовались в запутанных конструкциях, усложняющих понимание кода.
там и другие аргументы были, но менее убедительные, на мой взгляд.
такой уж и бонус. Придумывать название для каждого аргумента.
В js, кстати, можно что-то аналогичное делать теперь:
function fnc({a, b, c, d}) {
return a + b - c + d
}
let rr = fnc({a: 1, b: 2, c: 3, d: 4})
Ещё одно важное нововведение — это возможность писать код и видеть результаты в режиме реального времени.
Вы имеете ввиду playgrounds?
Или скорее тогда ничего кроме С/С++ не было, и тут новый язык. Сейчас-то есть и C#, и Go, и Rust, и скриптовых немеряно.
Помню, когда я впервые прочитал про Java, первая реакция была — ну С++ без указателей, ну и что? :) К C# помню был какой-то интерес, потому что там появилась новая концепция «атрибутов», сразу «вау, что-то новенькое, интересно что же это».
1. В первую очередь потому-что я его не изучал!
2. Есть Kotlin со всеми своим блекджеком и Java инфраструктурой.
3. Хочешь LLVM, есть GO в 100500 раз лучше Swift.
4. И, как не печально это осознавать, но ни какой новый язык не исправит убогое iOS SDK.
5. Если ты хочешь зарабатывать бабло на приложениях с максимальной выгодой ReactNative + Objective-C наше все!!!
Ну все а я пойду подожду что из этого всего выйдет и на сколько я на шутил про Swift правды.
А что котлин можно в iOS? :-)
Ну Вы прям хотите, чтоб я Вас добил шутками что ли? Ну ловите )
История языков программирования: от Objective C к Swift