LINUX.ORG.RU

Swift — новый язык программирования от Apple

 , ,


0

1

Только что на своей ежегодной конференции для разработчиков WWDC'14 крупнейшая IT-корпорация мира Apple анонсировала новый язык программирования — Swift, призванный заменить Objective-C, являющийся основным в операционных системах компании последние двадцать лет.

Swift — объектно-ориентированный язык, компилирующийся в нативный код. Вместе с тем он включает в себя многие фичи, присущие функциональным языкам, в том числе:

  • сопоставление с образцом (pattern matching);
  • вывод типов (type inference);
  • замыкания (closures);
  • кортежи (tuples);
  • REPL.

Однако в новый язык не попали многие низкоуровневые вещи, обеспечивающие обратную совместимость Objective-C и C. Несмотря на это, заявляется, что по производительности Swift существенно обгоняет Objective-C.

Также сообщается, что Xcode — интегрированная среда разработки от Apple — уже обеспечивает полную поддержку нового языка, включая интерактивный playground.

Подробнее на Apple Developer Center

>>> Руководство по языку

★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 2)
Ответ на: комментарий от Legioner

Выделять под 8 байтов (длина+адрес) отдельный кусок в heap?

Я думаю можно и в стеке

Выбранный подход разумней с моей точки зрения.

b[0] = 0;
a = b;
a[0] = 1;
print b[0]; //1
push(b, 2);
a[0] = 3;
print b[0]; //1
Очень разумно

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от Legioner

если статический анализатор видит что массив 99% модифицируется в функции то сразу копирает. Иначе у нас есть 2 бранча одной и той же функции. Одна работает с копией другая в r/o с проверками (читай копированием + jump на тоже место в бранче где работают с копией). В той где сразу копия никаких проверок очевидно нет. Можно не плодить бранчи а например иметь функцию с проверками и по копирование все проверки менять на nop ы с обратным воостановением по выходу, но насколько я знаю, llvm пока самомодифицирующий код не позволяет.

bga_ ★★★★
()
Ответ на: комментарий от Legioner

вообще если массивы делать как хеши int -> object то все гораздо проще. В хешах заранее заложен мехнизм наслоений те любая модификая это старый хеш + дифф (список удаленных ключей, хеш измененных ключей) который по мере надобности мержится чтобы не искать значение на 100 оригинальных хешей вниз. Транзакционная память в чистом виде но такой массов хоть и остается формально O(1) но это явно не 1 mov eax, [ebx + edx * 4]

bga_ ★★★★
()
Ответ на: комментарий от vvvictor

Тем не менее почему то отсылка с апплового сайта к параллельному свифту идет...

Отсылка для тех, кто искал parallel swift, а гугл его вывел на яблочный сайт.

Legioner ★★★★★
()
Ответ на: комментарий от goingUp

Я думаю можно и в стеке

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

Очень разумно

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

Legioner ★★★★★
()

За каждое компилирование будет сниматься с карточки 0.99$

Xegai ★★
()
Ответ на: комментарий от anonymous

Чем это они накачанные?

Не «чем», а «куда».

anonymous
()
Ответ на: комментарий от Legioner

Отсылка для тех, кто искал parallel swift, а гугл его вывел на яблочный сайт.

Думал про это... «Looking» - немного сбил с толку... Ну да и ладно...

vvvictor
()
Ответ на: комментарий от bga_

если статический анализатор видит что массив 99% модифицируется в функции то сразу копирает.

Что за 99%? Откуда статический анализатор может знать что-либо про рантайм? Может у меня 99% кода это обработка ошибки, которая случается раз в месяц, а всё остальное время работает одна строчка, которая ничего не модифицирует.

Иначе у нас есть 2 бранча одной и той же функции. Одна работает с копией другая в r/o с проверками (читай копированием + jump на тоже место в бранче где работают с копией). В той где сразу копия никаких проверок очевидно нет.

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

Можно не плодить бранчи а например иметь функцию с проверками и по копирование все проверки менять на nop ы с обратным воостановением по выходу, но насколько я знаю, llvm пока самомодифицирующий код не позволяет.

И как это будет работать при многопоточности или при рекурсии?

Legioner ★★★★★
()
Ответ на: комментарий от bga_

вообще если массивы делать как хеши int -> object то все гораздо проще. В хешах заранее заложен мехнизм наслоений те любая модификая это старый хеш + дифф (список удаленных ключей, хеш измененных ключей) который по мере надобности мержится чтобы не искать значение на 100 оригинальных хешей вниз. Транзакционная память в чистом виде но такой массов хоть и остается формально O(1) но это явно не 1 mov eax, [ebx + edx * 4]

Это огромный удар по производительности. Для какой-нибудь clojure или scala подойдёт, но для основной структуры данных практически системного языка программирования - нет. Ну и interop с C нельзя забывать, там массивы часто встречаются.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

его никакая вызванная функция где-нибудь не сохранит?

Это возможно только если в языке будут указатели. А по ссылке написано memory is managed automatically.

goingUp ★★★★★
()
Ответ на: комментарий от EXL

ObjC никуда не девается, даже при желании его так просто не выкинешь.

mono ★★★★★
()

О, теперь ещё и гей-язык. Фу.

anonymous
()
Ответ на: комментарий от webushka

Это другой язык Swift :) С копирайтом года этак от 2007.

Уже разобрались :)

vvvictor
()

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

unsigned ★★★★
()
Ответ на: комментарий от Bioreactor

Зачем мне нужен телефон или планшет, в котором я не могу расширить память, просто купив карточку, аки в «Ведроиде»?

Гугл смотрит на тебя, как на г..но.

«ябблЪ» теряет рынок.

Дада, уже лет 10 как теряет, если верить онолитегам на лоре, и вот уже 140 миллиардов «понатерял», скоро можно будет мелкие страны скупать. MS там как, тоже уже разорилась? А то 15 лет как вендекапец обещают красноглазики.

ptarh ★★★★★
()
Ответ на: комментарий от makoven

Скорее Java, какой она должна быть изначально. До нормального языка не дотягивает. Нет прямого доступа к памяти, и снова этот $%&$%ый сборщик мусора, будь он не ладен. Зато хоть динамическое петушение не ввели, и на том спасибо

Там НЕТ сборщика мусора.

kkk ★★
()
Ответ на: комментарий от dannie

у создателей свифта есть чувство прекрасного

Годно. Значит не будут заморачиваться с неудачными именами, а сразу изменят всё, что надо.

Legioner ★★★★★
()
Ответ на: комментарий от wayland_systemd

Чем оно лучше Rust'а

самый большой недостаток Rust в том что разработчики запрещают его использовать :) [ну или используйте на свой страх и риск, но мы вас предупредили!]..

даже если Rust чудесен и невероятен — то тот факт что его нельзя использовать — ну как минимум должен расстраивать :-) ..

хотя [на данный момент] ситуация с AppleSwift — ещё хуже..

так как Rust то можно на свой страх-и-риск хотябы, а вот AppleSwift вообще только лишь наобещан и не более.. :-)

user_id_68054 ★★★★★
()
Ответ на: комментарий от user_id_68054

так как Rust то можно на свой страх-и-риск хотябы, а вот AppleSwift вообще только лишь наобещан и не более.. :-)

Он уже доступен в ранней бета-версии XCode 6, которую я бы не стал ставить, памятуя негативный опыт с их Developer Preview версиями. Но осенью уже выйдет стабильная версия, чего нельзя сказать про rust.

kkk ★★
()
Ответ на: комментарий от user_id_68054

Ну Rust постепенно стабилизируют. Он еще довольно молод. ) Плюс в том, что сейчас его более-менее отладят, в том числе на больших проектах типа компилятора и Servo, и когда выйдет 1.0 можно будет не боясь тянуть в продакшен.

А Swift... Посмотрим.

wayland_systemd
()
Ответ на: комментарий от wayland_systemd

А Swift... Посмотрим.

А чо «посмотрим»? Сейчас аппл выпустит брошюру/пресс релиз/презентацию, в которой предаст все остальные языки для разработки на яблоках анафеме. толпы яблофанатов начнут переучиваться и потихоньку говнокодить. Ведь писать на чем-то кроме, уже не мейнстрим, да, вчерашний век, да, а как истинные адепты секты имени жобса, они не могут себе такого позволить. Будь не как все, будь как разработчики эппла, think different.

anonymous
()
Ответ на: комментарий от kkk

А когда надо иметь дело с большими буферами (например, обработка каждого кадра с камеры) - уповать на то, что, компилятор расставит malloc/free в правильных местах

makoven ★★★★★
()

This book is available for download with iBooks on your Mac or iOS device, and with iTunes on your computer. Books can be read with iBooks on your Mac or iOS device.

Для меня это уж слишком different.

Ахах. Да, меня тоже смутила эта фраза. Это тоже самое если бы доки по Android SDK были бы только в магазине (oh shi!) Google Play который бы открывался только из Android девайсов.

Hope ★★
()
Ответ на: комментарий от anonymous

Тут я не сомневаюсь. Короче, скорее всего новый objective-c, т.е. нормальным людям, возможно, не нужно.

wayland_systemd
()
Ответ на: комментарий от Apple-ch

Синтаксически — винегрет из сишарпа, го, хаскела и остального понемножку.

Синтаксические винегреты не нужны. Взяли бы просто лисп (один-два - не принципиально) и пилили на его синтаксисе свои фичи.

naryl ★★★★★
()

Я считаю, что новый язык от Apple не нужен. Хорошие языки всегда создавались академическими, а не коммерческими структурами.

Deleted
()

Я просто должен оставить это здесь:

I started my career at Apple in the developer tools group in Cupertino. But after a couple of years I decided to move east, and transfered to the Cambridge office to work on the Dylan project. In April 1995, we were notified that the project would be cancelled and we would all be laid off. But we were not to be laid off immediately. Apple wanted us to stay for 6 months so Dylan could be released as an experimental «technology release». This was apparently done to avoid embarrasment at WWDC the following month. Dylan was announced and hyped heavily at the previous WWDC, and it would look bad if it disappeared the month before the WWDC the following year.

We were offered an incentive bonus to stay until October. It was strange to be given 6 months notice. We all had plenty of time to find new jobs, but it was not much fun to go down with the ship

tailgunner ★★★★★
()
Ответ на: комментарий от makoven

А когда надо иметь дело с большими буферами (например, обработка каждого кадра с камеры) - уповать на то, что, компилятор расставит malloc/free в правильных местах

В Obj-C для этого надо обнулить указатель на объект, думаю тут аналогично сделано.

kkk ★★
()
Ответ на: комментарий от user_id_68054

а как его установить — есть инструкция? (я про XCode)

Для начала надо его скачать. Чтобы его скачать нужна оплаченная учётная запись разработчика. Когда скачал, устанавливаешь как обычно.

kkk ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.