Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 264
Стало более читабельно, как мне кажется.
Очень странный комментарий. Как впрочем и сама статья. Создаётся такое впечатление, что вышла новая версия Objective-C, в то время как на самом деле родился принципиально новый язык.
По набору фич, позиционированию и т.п. он больше всего напоминает язык D, из которого выпилили метапрограммирование (одна из главных фич D кстати), исключения и поддержку многопоточности. Ну и плюс добавили несколько мелких вкусностей типа pattern matching и extensions. И всё это в оригинальном и довольно лаконичном синтаксисе.
Естественно это далеко не идеал, но в любом случае вышел отличный язык, поинтереснее тех же Java и C#. А уж на фоне такого дикого ужаса, как Objective-C, Swift должен казаться просто манной небесной.
P.S. Я сам мягко говоря не поклонники компании Apple. Но в данном случае нельзя не признать, что у них вышел очень интересный и нужный продукт.
По набору фич, позиционированию и т.п. он больше всего напоминает язык D, из которого выпилили метапрограммирование (одна из главных фич D кстати), исключения и поддержку многопоточности. Ну и плюс добавили несколько мелких вкусностей типа pattern matching и extensions. И всё это в оригинальном и довольно лаконичном синтаксисе.
Естественно это далеко не идеал, но в любом случае вышел отличный язык, поинтереснее тех же Java и C#. А уж на фоне такого дикого ужаса, как Objective-C, Swift должен казаться просто манной небесной.
P.S. Я сам мягко говоря не поклонники компании Apple. Но в данном случае нельзя не признать, что у них вышел очень интересный и нужный продукт.
Apple сделали более современную замену ObjC, но не более.
Swift по куче признаков не претендует ни на какие ниши, кроме разработки UI под iOS:
Для серверного кода — нет GC, нет управляемого рантайма, нет метапрограммирования.
Для игрушек — нет (и скорее всего не будет) нормальной кросс-платформенности, да и недостаточно он низкоуровневый.
Ядро ОС и драйвера писать — опять же недостаточно низкоуровневый
Как скрипт-язык — недостаточно гибок, и заточен под компиляцию
Остаются десктоп-приложения под iOS и OS X. И для этого он с виду весьма неплох, особенно учитывая насколько страшен ObjC по сравнению.
Короче радоваться и плясать стоит тем, кто пишет UI под маки. Остальным — просто порадоваться за коллег, и идти мимо.
Swift по куче признаков не претендует ни на какие ниши, кроме разработки UI под iOS:
Для серверного кода — нет GC, нет управляемого рантайма, нет метапрограммирования.
Для игрушек — нет (и скорее всего не будет) нормальной кросс-платформенности, да и недостаточно он низкоуровневый.
Ядро ОС и драйвера писать — опять же недостаточно низкоуровневый
Как скрипт-язык — недостаточно гибок, и заточен под компиляцию
Остаются десктоп-приложения под iOS и OS X. И для этого он с виду весьма неплох, особенно учитывая насколько страшен ObjC по сравнению.
Короче радоваться и плясать стоит тем, кто пишет UI под маки. Остальным — просто порадоваться за коллег, и идти мимо.
Согласен с разбором по нишам, но не согласен с начальными тезисами
1. Да, это замена Obj-C, но весьма существенная. Т.к. если раньше убогий Obj-C вызвал лишь усмешку у народа с других платформ, то теперь данный язык вполне может оказаться поприятнее базовых инструментов на других платформах. А это существенно меняет расклад.
2. Не понял как это у вас из логичного «десктоп-приложения под iOS и OS X» (с чем я согласен в общем то) вышло " разработки UI под iOS" — это как бы совсем разные вещи.
3. Область «большая часть приложений под OS X и iOS» — это мягко говоря не маленький кусочек рынка. О таких объёмах код для ядра ос/драйверов или даже серверный код может только мечтать.
А с итогом опять же согласен — лично я тоже просто прохожу мимо.
1. Да, это замена Obj-C, но весьма существенная. Т.к. если раньше убогий Obj-C вызвал лишь усмешку у народа с других платформ, то теперь данный язык вполне может оказаться поприятнее базовых инструментов на других платформах. А это существенно меняет расклад.
2. Не понял как это у вас из логичного «десктоп-приложения под iOS и OS X» (с чем я согласен в общем то) вышло " разработки UI под iOS" — это как бы совсем разные вещи.
3. Область «большая часть приложений под OS X и iOS» — это мягко говоря не маленький кусочек рынка. О таких объёмах код для ядра ос/драйверов или даже серверный код может только мечтать.
А с итогом опять же согласен — лично я тоже просто прохожу мимо.
нет GC
Есть значительно лучший ARC
нет управляемого рантайма
Как нет??
да и недостаточно он низкоуровневый.
Компилируется в LLVM же. Куда ещё низкоуровнее?
Прозрачно линкуется с Си, чего ещё желать?
нормальной кросс-платформенности
Зарелизят открытый компилятор ведь — куда кроссплатформенней то?
Ядро ОС и драйвера писать — опять же недостаточно низкоуровневый
Прозрачно линкуется с Си и плюсами, что мешает писать и драйвера и ядро?
Как скрипт-язык — недостаточно гибок, и заточен под компиляцию
Показали же лайв-кодинг, что ещё гибкого надо?
учитывая насколько страшен ObjC
Сугубо субъективеное мнение. Сколько лет на ObjC работали?
Я так и не понял как в свифте обрабатываются ошибки, там исключения? В книге которую выпустили сразу после релиза я что-то ничего по этой теме не нашел.
Exceptions? В Obj-C исключения не используются для flow-control приложения, как, например, в Java. Этому есть множество причин, которые описаны в документации. Соответственно практически нигде try catch не должен использоваться. Могли и выпилить, по причине «ибо нефиг» — сам видел, что приходящие из других языков программисты начинают с этими try-catch лепить. Но как-то это очень уж дерзко с их стороны.
Способ, насаждаемый Apple для обработки ошибок — передавать указатель на NSError.
Способ, обычно используемый — возвращаем nil.
Способ, насаждаемый Apple для обработки ошибок — передавать указатель на NSError.
Способ, обычно используемый — возвращаем nil.
Я думаю отсутствие исключений объясняется проще — библиотеки будут старые, а они на это не заточены.
То что исключения гораздо удобнее возврата null из методов — известный и проверенный факт. Просто в данном случае — не судьба.
То что исключения гораздо удобнее возврата null из методов — известный и проверенный факт. Просто в данном случае — не судьба.
Хм? Старые библиотеки сыплют исключения.
Просто в Obj-C так принято, что если у нас «исключение» — то мы падаем, а не ловим: выход за пределы массива, вызов несуществующего метода… Таких вещей быть не должно. А те ситуации, которые к падению не приводят — не кидаем ексепшн, а возвращаем нил и дальше он спокойно гуляет по системе, которая изначально спроектирована с учетом, что практически все может оказаться nil'ом. Не Obj-Cшники как-то такой подход принимают во штыки.
Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.
If you have an existing body of code (such as third-party library) that uses exceptions to handle error conditions, you may use the code as-is in your Cocoa application. But you should ensure that any expected runtime exceptions do not escape from these subsystems and end up in the caller’s code. For example, a parsing library might use exceptions internally to indicate problems and enable a quick exit from a parsing state that could be deeply recursive; however, you should take care to catch such exceptions at the top level of the library and translate them into an appropriate return code or state.
Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications. For further information, see Error Handling Programming Guide.
И чего минусуют, писали бы. Наверное те самые «приходящие из других языков».
Просто в Obj-C так принято, что если у нас «исключение» — то мы падаем, а не ловим: выход за пределы массива, вызов несуществующего метода… Таких вещей быть не должно. А те ситуации, которые к падению не приводят — не кидаем ексепшн, а возвращаем нил и дальше он спокойно гуляет по системе, которая изначально спроектирована с учетом, что практически все может оказаться nil'ом. Не Obj-Cшники как-то такой подход принимают во штыки.
Important: You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.
If you have an existing body of code (such as third-party library) that uses exceptions to handle error conditions, you may use the code as-is in your Cocoa application. But you should ensure that any expected runtime exceptions do not escape from these subsystems and end up in the caller’s code. For example, a parsing library might use exceptions internally to indicate problems and enable a quick exit from a parsing state that could be deeply recursive; however, you should take care to catch such exceptions at the top level of the library and translate them into an appropriate return code or state.
Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications. For further information, see Error Handling Programming Guide.
И чего минусуют, писали бы. Наверное те самые «приходящие из других языков».
Сочетание tuple, pattern matching и optional в принципе может дать удобную картину… Хотя одна возможность исключений (автоматическое перекидывание сообщение об ошибке через длинный стек вызова) при этом всё равно недоступна.
Плохо, что вместо GC подсчёт ссылок. Банальное дерево, где узел ссылается не только на дочерние, но и на родительские узлы, и мы получаем структуру, имеющую все шансы остаться в памяти навечно.
Я так понимаю, что структуры данных можно писать и на более быстрых языках с ручным управлением памятью.
Проблема не в быстроте, проблема в циклических ссылках при возникновении которых весь граф объектов не будет освобождён. Дерево просто самый простой для понимания пример. Я лет десять назад на VB6 не раз обжигался на таких утечках.
Ну так я ведь не зря упомянул ручное управление памятью.
Зря, т.к. в Swift управление памятью, очевидно, автоматическое. Как бы вы ни изворачивались в C или где-то ещё, циклические ссылки в Swift это не устранит.
Если дерево написано на Си, а объекты из Swift будут лежать уже внутри узлов, то о каких циклических ссылках идет речь?
Там предлагается два варианта решения этой проблемы: weak references и unowned references.
И то, и другое ведёт к потенциальным проблемам, а именно:
1) можно банально забыть поставить слабые ссылки где надо
2) трудноотлавливаемые ошибки времени выполнения, вылезающие когда объект по слабой ссылке становится недоступен.
GC в этом плане всё же существенно надёжнее.
1) можно банально забыть поставить слабые ссылки где надо
2) трудноотлавливаемые ошибки времени выполнения, вылезающие когда объект по слабой ссылке становится недоступен.
GC в этом плане всё же существенно надёжнее.
Они решили, переложить эти проблемы на плечи кодеров. Тоже с «опциональными» переменными, теперь надо будет следить чтобы правильно и в нужном месте ее «распаковать». Зато решили рубишную проблему с nil'ами, добавили optional chaining, но опять же, проблема решена не в корне (nil не выбросили), а просто добавили удобный воркэраунд о котором надо всегда помнить.
Поясните, пожалуйста, какую проблему с nil-ами?
Например, user.subscription.plan.price, а у User'а нету вообще подписки, тогда user.subscription вернет nil, а nil.plan вызовет исключение NoMethodError, так как plan теперь не как метод объекта subscription, а как меторд nil'а. В rails есть хак, метод try, тогда это переписывается как: user.try(:subscription).try(:plan).try(:price). Тогда если на каком-то этапе цепи вызовов будет nil, все выражение вернет nil.
Либо используется NullObject паттерн, или, в случае с rails (когда можно), delegate.
Либо используется NullObject паттерн, или, в случае с rails (когда можно), delegate.
Ну это же не проблема ruby, а проблема проектирования метода программистом. Эта проблема и в джаве возникает, и в любом языке, где функция может вернуть nil. А язык, в котором функция всегда возвращает только правильно инициализированный объект с правильным интерфейсом был бы довольно ущербен на практике, увы. Вот если бы NullObject встроили в язык (сделали бы возможность создавать объекты, которые приводятся к логическому false) — было бы здорово.
Да, как бы не проблема, но сам nil, может означать тонну вещей: у пользователя нету подписок, или подписки не подгрузились, или может пользователь вообще заблокирован и т.д. Сама суть nil'а логически зачастую может быть совершенно неясна. Вот выше пишут, что если какая-то ошибка, то в ObjC принятно возвращать NSError, но программисты забивают на это и возвращают nil. Так что сама концепция nil'а очень спорна.
Ну, есть же ещё Option<T>, или Maybe a
Вы не поверите, но в Swift как раз функция не может внезапно вернуть nil. Точнее, может, но тогда и тип возврата у нее будет optional, а не просто данный класс — и это нужно явно указывать.
> Эта проблема и в джаве возникает, и в любом языке, где функция может вернуть nil.
Вы начинаете понимать суть. :) Почему чувак, придумавший null, назвал его «ошибкой стоимостью в миллиарды долларов», и почему языки так стараются от него избавиться.
Вы начинаете понимать суть. :) Почему чувак, придумавший null, назвал его «ошибкой стоимостью в миллиарды долларов», и почему языки так стараются от него избавиться.
Для этого же есть (.?) safe navigation operator или как он там называется?
Это мы о Руби, там нету. Зато в Groovy есть, и его перенесли в Swift как вариант, но суть в том, что полученный в результате nil ничего не сообщает о природе ошибки (или не ошибки :).
А не надо возвращать nil. Используйте ADT, то бишь в данном случае enum'ы:
И при вызове паттерн-матчинг (который вызывающему придется написать, и, соответственно, как-то обработать все ошибки):
Единственное, что здесь плохо — прокидывать придется вручную. Были бы полноценные монады — было бы проще (впрочем, исключения — это по сути и есть классическая error monad, которая неявно подсовывается во все типы).
enum FooResult {
case Success(Int),
case PEBKACError,
case SomeOtherError(String /*reason*/)
}
func foo(...) -> FooResult { ... }
И при вызове паттерн-матчинг (который вызывающему придется написать, и, соответственно, как-то обработать все ошибки):
switch foo (...) {
case .Success(let result):
...
case .PEBKACError:
...
case .SomeOtherError(let reason):
...
}
Единственное, что здесь плохо — прокидывать придется вручную. Были бы полноценные монады — было бы проще (впрочем, исключения — это по сути и есть классическая error monad, которая неявно подсовывается во все типы).
GC не лишен своих недостатков. Видимо Apple хочет избежать «остановки мира».
Комментарий не читай — сразу отвечай :)
«Остановка мира» — это момент, когда GC решает освободить память, скрывающуюся за висячими указателями. Как нетрудно догадаться, это занимает некоторое время. Большое или нет — зависит от реализации GC и паттерна использования памяти приложением. Если бы у GC вообще не было недостатков, их давно начали бы пихать во встраиваемые системы на микроконтроллерах, где размеры оперативной памяти варьируются в широчайших пределах: от сотен байт до сотен килобайт.
Скорее всего причина банальнее — Apple хочет совместимости с их библиотеками, которые под GC не заточены.
GC отлично умеет работать с библиотеками, заточенными под подсчёт ссылок. Просто вместо освобождения памяти он освобождает ссылку, а дальше объект сам разбирается, в каком состянии у него счётчик. В дотнете так работа с COM реализована.
Apple сама недавно задеприкейтила GC, до этого он был в маковских приложениях. На самом деле ARC быстрее и в большинстве случаев позволяет не задумываться о том, когда объект освободится и т.п.
для этого есть слабые ссылка(ключевое слово weak)
Описанная ситуация — ошибка программиста. Не надо так )
Это не ошибка, если есть GC.
Вам уже выше написали про weak. Не вижу смысла обсуждать ARC при сравнении Swift и Objective-C, ведь в Objective-C это работает так же. Так что для айос девелоперов это само собой разумеющееся, для остальных — ну, welcome to our world.
Сам по себе GC не спасает от ошибки, зависит от конкретной реализации алгоритма GC. Точно такая же проблема может и встретиться при GC, так что GC не панацея и тоже можно накосячить.
А GC как такие структуры собирает? Определяет что дальше по коду ссылок на родительские ноды не будет?
На iOS и сейчас нет GC. Почти все перешли на ARC. Не исключено что сборщик мусора добавят в более поздних версиях рантайма.
Weak ptr в помощь. А непредсказуемый GC на свалку.
А, уже написали
А, уже написали
Я бы на самом деле комбинировал два подхода. Подсчёт ссылок для освобождения памяти по мере того как становится известно, что она не нужна + GC для сбора графов объектов с циклическими ссылками. Тогда и проблем нет с циклами, и мусора достаточно мало, чтобы GC отрабатывал быстро.
Забавно то, что я даже еще ObjC не успел еще выучить, а тут Swift :))
и где «инновации» в данном языке? в чем его фишка?
инновация в том, что язык стал проще, быстрее и больше возможностей для разработки
По-моему, возврат к С (в плане синтаксиса). Разве что if без кавычек
О, уверяю Вас, изменения в языке намного существеннее, чем может показаться на первый взгляд.
И это радует (по крайней мере меня т.к. имхо синтаксис obj-c крайне отвратителен)
А так язык очень даже интересный, только не совсем понятно, там инкапсуляция есть? А то в доках не нашёл как задаются приватные\защищённые методы,
А так язык очень даже интересный, только не совсем понятно, там инкапсуляция есть? А то в доках не нашёл как задаются приватные\защищённые методы,
О, то есть переход от вырвиглазного синтаксиса Obj-C к нормальному, читаемому — это инновация?
Apple сделала новый язык для своей экосистемы по образу и подобию существующих решений. Уже только этим привлекаются новые разработчики на эту платформу.
Эм… Вы это серьезно?
Во-первых, вы давно пытались скомпилировать плюсовый код, написанный на VS, хотя бы под gcc?
Во-вторых, как вы думаете, что будет лучше работать: адаптированный под платформу код, или кроссллатформенная реализация алгоритма, учитывающая косяки каждой платформы?
В-третьих, Objective-C по статистике имеет в 2 раза большую долю, чем замечательный «кроссплатформенный» C++.
В-четвертых, как вы думаете, почему самый кроссллатформенный язык программирования java не компилируется в исполняемые файлы, а требует платформозависимую JVM?
Ну и так далее. В итоге кроссплатформенность это из разряда недостижимых парадигм.
Во-первых, вы давно пытались скомпилировать плюсовый код, написанный на VS, хотя бы под gcc?
Во-вторых, как вы думаете, что будет лучше работать: адаптированный под платформу код, или кроссллатформенная реализация алгоритма, учитывающая косяки каждой платформы?
В-третьих, Objective-C по статистике имеет в 2 раза большую долю, чем замечательный «кроссплатформенный» C++.
В-четвертых, как вы думаете, почему самый кроссллатформенный язык программирования java не компилируется в исполняемые файлы, а требует платформозависимую JVM?
Ну и так далее. В итоге кроссплатформенность это из разряда недостижимых парадигм.
Недостижимая парадигма? Да ладно.
configure && make && make install
configure && make && make install
Я бы на вашем месте осторожнее сопоставлял индекс TIOBE и долю языка. Корреляция количества поисковых запросов и доли отнюдь не очевидная.
А что касается кроссборки. Ну я не знаю возьмите линуксовый софт — как то умудряются делать сборки под любую архитектуру. Вот прямо сейчас открыты chrome и firefox которые живут на куче различных платформ от андроида до винды. И все написно на c++
А что касается кроссборки. Ну я не знаю возьмите линуксовый софт — как то умудряются делать сборки под любую архитектуру. Вот прямо сейчас открыты chrome и firefox которые живут на куче различных платформ от андроида до винды. И все написно на c++
Я взял первый попавшийся рейтинг языков программирования. Вместо этого можно взять количество живых проектов на гитхабе. В любом случае для Objective-C весьма высока.
И я не спорю, что есть большие проекты, написанные на плюсах, которые собираются на любой платформе. Но, как уже было сказано, это достигается большим количеством человеко-часов и #ifdef-ов. Возьмите нестандартный компилятор или банально измените конфиг у текущего, и тут же на вас повалится столько, что мама не горюй.
И я не спорю, что есть большие проекты, написанные на плюсах, которые собираются на любой платформе. Но, как уже было сказано, это достигается большим количеством человеко-часов и #ifdef-ов. Возьмите нестандартный компилятор или банально измените конфиг у текущего, и тут же на вас повалится столько, что мама не горюй.
Лол. Есть большие проекты? UnrealEngine, CryEngine, idTech, Chromiun, Firefox, Photoshop, Blender, Visual Studio, Sublime Text и т.д. и т.п.
Ну-ка назовите мне хотя бы несколько проектов такого же уровня на Obj-C.
Ну-ка назовите мне хотя бы несколько проектов такого же уровня на Obj-C.
А с чего вы собственно решили, что популярность и распространенность языка программирования связана как-то с наличием больших проектов?
Популярность и распространенность ЯП зависит от:
1) Количества проектов на данном ЯП. Чем больше проект, тем больше в нем задействовано людей;
2) Количества библиотек, доступной на данном ЯП.
Ну а теперь сравните Obj-C и C++.
1) Количества проектов на данном ЯП. Чем больше проект, тем больше в нем задействовано людей;
2) Количества библиотек, доступной на данном ЯП.
Ну а теперь сравните Obj-C и C++.
По таким критериям выйдет, что fortran и чистый C популярнее и распространеннее C++.
И большое количество библиотек вообще в достоинства C++ пихать как-то странно. Каждый второй программист пишет свою STL, лишенную недостатков дефолтной реализации по стандарту.
И большое количество библиотек вообще в достоинства C++ пихать как-то странно. Каждый второй программист пишет свою STL, лишенную недостатков дефолтной реализации по стандарту.
Насчет Fortran'а сказать ничего не могу, а чистый C, очевидно, куда популярнее и распространеннее C++: Linux kernel, PostgreSQL, MySQL, PHP, Git, Maple и прочее, и прочее.
Мне кажется, что Вы либо вообще никогда не работали с C++, либо это делали лет 20 назад. Одно из самых ключевых достоинств C++ в том, что на этом языке реализовано почти все, что может понадобиться в жизни. В мире C++ принято сначала искать уже готовую реализацию, и только потом, если ее нет, писать свою.
Опять же, Ваша фраза о STL говорит о том, что о нынешнем положении C++ Вы знаете мало. Своя STL есть только в тех компаниях, которые начинали свою разработку до появления этой самой STL (либо на ее ранних версиях). Все разработчики уже давно используют STL из коробки, boost, poco и прочие либы.
Мне кажется, что Вы либо вообще никогда не работали с C++, либо это делали лет 20 назад. Одно из самых ключевых достоинств C++ в том, что на этом языке реализовано почти все, что может понадобиться в жизни. В мире C++ принято сначала искать уже готовую реализацию, и только потом, если ее нет, писать свою.
Опять же, Ваша фраза о STL говорит о том, что о нынешнем положении C++ Вы знаете мало. Своя STL есть только в тех компаниях, которые начинали свою разработку до появления этой самой STL (либо на ее ранних версиях). Все разработчики уже давно используют STL из коробки, boost, poco и прочие либы.
1) Делаю это каждый день. Все нормальные плюсовики уже давно пишут кроссплатформенный код.
2) Лучше будет работать качественный код, независимо от языка или платформы. Другое дело, когда мы выбираем язык, который поддерживается одной платформой, мы получаем продукт только для этой платформы. Хотим перенести — пишем все заново на чем-то другом, с новыми проблемами и багами (вы когда-нибудь пробовали поддерживать одно и тоже на разных ЯП?).
3) За ссылку на Хабре на эту статистику пора уже бить палками по жопе. Это статистика поисковых запросов, она лишь говорит о том, что информацию по Obj-C пытаются искать чаще, чем по C++. Оно и понятно.
4) Потому что специально был так спроектирован? Есть другие языки, которые вполне одинаково могут работать на разных платформах без виртуальной машины.
2) Лучше будет работать качественный код, независимо от языка или платформы. Другое дело, когда мы выбираем язык, который поддерживается одной платформой, мы получаем продукт только для этой платформы. Хотим перенести — пишем все заново на чем-то другом, с новыми проблемами и багами (вы когда-нибудь пробовали поддерживать одно и тоже на разных ЯП?).
3) За ссылку на Хабре на эту статистику пора уже бить палками по жопе. Это статистика поисковых запросов, она лишь говорит о том, что информацию по Obj-C пытаются искать чаще, чем по C++. Оно и понятно.
4) Потому что специально был так спроектирован? Есть другие языки, которые вполне одинаково могут работать на разных платформах без виртуальной машины.
Популярность языка никак не говорит о его качествах. ObjC — в общем-то, единственный полноценный способ писать приложения на iOS. Был бы Brainfuck вместо ObjC, писали бы на Brainfuck — да, тяжело и унизительно, но жрать тоже хочется.
Да сейчас чуть ли не каждый создатель очередного ЯП первым делом берёт курс на упрощение. Это вообще тренд такой: «MegaFucker — простой и удобный ЯП...», «libshitload — простая и удобная библиотека для рабтоты с...» и т.д. А потом выясняется, что этими простыми и удобными инструментами жутко неудобно делать сложные вещи, а для того, чтобы сделать «сложный и неудобный» инструмент", оказывается, надо приложить гораздо больше усилий.
Согласен. Статья в этом плане жидковата, а самих фич-то хватает.
Отличная книга! =)
Эта же книга доступна в виде HTML: developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/
Автоматический вывод типов, по-моему, неплохая фишка, например.
Было бы неплохо написать серию статей на русском, новичкам полезно, да и просто читать приятнее.
Книга, хоть и на английском, но читается довольно легко.
а есть книга в pdf-е для нищебродов без тунца и айфона? на developer.apple.com нашел только краткий reference/guide
Книга через iTunes выкачивается в формате epub. Забрать EPUB с mega.co.nz
Внутри epub лежат HTML файлы. Забрать HTML с mega.co.nz
Внутри epub лежат HTML файлы. Забрать HTML с mega.co.nz
Можно просто с сайта читать: developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/
да, так же движок Metal не дает покоя :)) будет очень интересно погамать в игры на таком движке
В Swift в качестве имен переменных можно юзать юникод, то бишь можно смайлы!
Синтаксис напоминает JavaScript
Скорее go
да, ECMA-подобное нечто :)
Rust он напоминает.
TypeScript. Почти полное совпадение.
Не знаю насчет синтаксиса (здесь всем кажется, что он напоминает его любимый язык, потому что многие современные языки в плане синтаксиса неотличимы), но судя по структуре и концепциям это язык группы ML.
Я не думаю, что язык с mutable by default (в частности, массивы и структуры) можно причислить к семейсту ML.
Логично, потому что чисто функциональный язык в промышленной разработке сейчас никому не нужен. Однако, есть некоторые вещи (типа let и спецификаторов mutable), которые явно текут оттуда.
Ну, let с таким же успехом мог прийти и из Scheme, например. Но в данном случае я думаю, что прямое заимствование синтаксиса было из ES6.
Спецификатора «mutable» я там нигде не вижу. Вы имеете в виду «mutating»? Но у него, опять же, очень ограниченная ниша (мутирующие методы структур и перечислений), к ML'ному «let mutable» имеющая мало отношения.
Спецификатора «mutable» я там нигде не вижу. Вы имеете в виду «mutating»? Но у него, опять же, очень ограниченная ниша (мутирующие методы структур и перечислений), к ML'ному «let mutable» имеющая мало отношения.
Обычный си-подобный синтаксис с традиционными уже улучшениями и корректировками, облегчающими парсинг (типа var/let перед объявлением переменных, func перед функциями и т.д.). По сути си-пободный синтаксис — стандарт де-факто, и это хорошо.
Мда как давно в Обьектном Си не хватал перегрузки операторов, был громосткий синтаксис, а теперь другая крайность — «Стриж» вообще похож на скриптовые языки.
Он похож не на скриптовые языки, он похож на современные статически типизированные языки (C#, Scala, Kotlin) с type inference. Которые, таки да, в плане синтаксиса многое потырили из ActionScript, ES4, Groovy и т.д. — но это вполне нормально, зачем изобретать велосипед? Но потырили уже давно, в том же C# var был еще в 2008-м :)
Просто подарок судьбы. После руби очень не нравился вырвиглазный синтаксис objective-c (разница в читаемости кода на скришотах, по-моему очевидна), сейчас уже можно и под iphone попробовать что нибудь написать.
Такое впечатление, что начали копировать Scala, но недокопировали (switch и if не выражения, return обязателен).
Но в целом тенденция меня радует.
Но в целом тенденция меня радует.
Тут для Swift хаб уже сделали. Может быть туда?..
Интересно, а со swift-lang.org у Apple конфликтов не планируется :) Даже расширение у файлов, похоже, одинаковое.
Так это и есть они, вот тут ссылка внизу https://developer.apple.com/swift/
Да какие могут быть конфликты у Apple (тысячи разработчиков) и University of Chicago (группа в 10 человек)?
Вероятнее всего, вторая команда будет вынуждена переименовать свой язык, чтобы не спамили: «А как мне на вашем параллельном языке написать тетрис для айфона?»
Такой вот рейдерский захват понравившегося названия (и логотипы тоже похожи)…
Вероятнее всего, вторая команда будет вынуждена переименовать свой язык, чтобы не спамили: «А как мне на вашем параллельном языке написать тетрис для айфона?»
Такой вот рейдерский захват понравившегося названия (и логотипы тоже похожи)…
Сегодня завели скайп чат на тему Swift, будем рады если кто присоединится — (уже 135 человек там):
ссылка:
bit.ly/swift_skype_chat
ссылка в skype формате:
skype:?chat&blob=F1b1xpg2aiYCbjz_iAlNW-zXiMCX17kVSbOreFY23im5QdnT10bXMnsWFRUD4UoyoCLw76F-VTCJzrE
(скайп тормозит с чатами по этому иногда требуется минут 10-15 после захода в чат, чтобы он загрузил все что нужно)
ссылка:
bit.ly/swift_skype_chat
ссылка в skype формате:
skype:?chat&blob=F1b1xpg2aiYCbjz_iAlNW-zXiMCX17kVSbOreFY23im5QdnT10bXMnsWFRUD4UoyoCLw76F-VTCJzrE
(скайп тормозит с чатами по этому иногда требуется минут 10-15 после захода в чат, чтобы он загрузил все что нужно)
Разве есть что-то плохое в ссылке на чат строго по тематике поста? это ведь не реферальная ссылка.
Этот пост через недельку потеряется а люди продолжат общаться и дальше.
Этот пост через недельку потеряется а люди продолжат общаться и дальше.
похоже в настоящее время мы достигли лимита в 300 пользователей на чат скайпа
в связи с чем люди делают новые чаты. например
skype:?chat&blob=1lHQVAEmzXD0kTHjOVeZp-mnqlLCQmAz-pYEjn01Qt4mqBwsyotXgfFgJeVz_xgiHQ78Tb3sy2f5l4Bx9JYg7zoi1-lUVQhECZzcqRoD5scHv1wN4eQVtDc1393_HgzAsrAxcQABCFAZm21sHpbGo6tNGQvgLQ-vTcfpllk9uJHnWg7G4sL3WED9GyYXc2b0Qq-kTdBUd0A_emzmdkCzCmjuQsnX0I1l0Ibt
skype:?chat&blob=1lHQVAEmzXD0kTHjOVeZp-mnqlLCQmAz-pYEjn01Qt4mqBwsyotXgfFgJeVz_xgiHQ78Tb3sy2f5l4Bx9JYg7zoi1-lUVQhECZzcqRoD5scHv1wN4eQVtDc1393_HgzAsrAxcQABCFAZm21sHpbGo6tNGQvgLQ-vTcfpllk9uJHnWg7G4sL3WED9GyYXc2b0Qq-kTdBUd0A_emzmdkCzCmjuQsnX0I1l0Ibt
кто то еще завел канал irc.freenode.net #swift-lang-ru
На Freenode создали IRC канал по Swift — #swift-lang
Как-то весьма поверхностно. И зачем эти скрины, если можно было обойтись вставкой кода?
Рекомендую интересующимся читать книгу, она хорошо и просто написана. Чтобы получить представление о языке хватит 2х первых глав.
// возврат нескольких значений из функции
func getGasPrices() -> (Double, Double, Double) {
return (3.59, 3.69, 3.79)
}
getGasPrices()
// переменно число параметров в функции
func sumOf(numbers: Int...) -> Int {
var sum = 0
for number in numbers {
sum += number
}
return sum
}
sumOf()
sumOf(42, 597, 12)
Рекомендую интересующимся читать книгу, она хорошо и просто написана. Чтобы получить представление о языке хватит 2х первых глав.
А еще на Swift-e можно написать так:
let π = 3.14159
let 你好 = "你好世界"
let Блог = "Хабрахабр"
Я вас наверное удивлю, но на Java тоже.
И в Python, и в Javascript.
И еще практически все .Net-языки забыли…
Но зачем?
Никогда не видел смысла в юникодных идентификаторах в языках программирования. Попадутся вот вам исходники из Китая, что будете делать? Лучше бы уж переносимый набор символов POSIX расширили до 128, назначив на неиспользуемые коды до 0x20 какие-нибудь полезные юникодовские символы типа стрелок и дополнительных скобок, чтобы не мучать парсеры угловыми скобками, которые знаки «больше» и «меньше»:)
Ну как же, разве не красота?
∄ : ∀ {a b} {A : Set a} → (A → Set b) → Set (a ⊔ b)
∄ P = ¬ ∃ P
Красота для настоящего программиста это тогда, когда эти символы есть на любой клавиатуре мира:) Чтобы можно было собственноручно нажать клавишу и увидеть, как символ появлятся в редакторе…
А так… я даже не уверен что они в основных моноширинных шрифтах присутствуют.
А так… я даже не уверен что они в основных моноширинных шрифтах присутствуют.
Не знаю, как в других языках, а в C# такой фокус не прокатит: математические символы не входят в число допустимых в идентификаторах. :(
Иногда всё-таки имеет смысл называть вещи в устоявшейся терминологии предметной области, которая может быть на языке, отличном от английского.
Я видел проект на C#, где классы и поля называли по-русски. Да в таком подходе много минусов, начиная от того что раскладку надо щелкать, заканчивая тем, что выглядит это весьма вырвиглазно. Но плюс в том, что не надо мучительно придумывать и запоминать названия для целой кучи понятий.
С другой стороны — видел проект на испанском. У них алфавит латинский, так что отсутствие юникода не помешало им называть классы и методы на своём. Ну а попало оно потом к нашим :)
Я видел проект на C#, где классы и поля называли по-русски. Да в таком подходе много минусов, начиная от того что раскладку надо щелкать, заканчивая тем, что выглядит это весьма вырвиглазно. Но плюс в том, что не надо мучительно придумывать и запоминать названия для целой кучи понятий.
С другой стороны — видел проект на испанском. У них алфавит латинский, так что отсутствие юникода не помешало им называть классы и методы на своём. Ну а попало оно потом к нашим :)
А по-моему, это не круто. Имею дело с банком, у которого все линки вот с такими словами:
Мораль: на каком-то этапе банк был только венгерский, а потом вышел на более широкий рынок. Переделывать никто не стал.
Это касается и кода и проектов. И возможности с кем-то что-то зашарить, даже если проект целиком 100% всегда будет виден только разработчикам в одной стране. Хотя и тут тоже — в моей компании, находясь физически в одном офисе, работали иностранцы, которые ни слова по-русски не знали. И хоть их было пару человек, всё-равно разработка, основная переписка и тексты коммитов всегда были на английском.
szamlakKozottiAtvezetes.Мораль: на каком-то этапе банк был только венгерский, а потом вышел на более широкий рынок. Переделывать никто не стал.
Это касается и кода и проектов. И возможности с кем-то что-то зашарить, даже если проект целиком 100% всегда будет виден только разработчикам в одной стране. Хотя и тут тоже — в моей компании, находясь физически в одном офисе, работали иностранцы, которые ни слова по-русски не знали. И хоть их было пару человек, всё-равно разработка, основная переписка и тексты коммитов всегда были на английском.
С другой стороны — часто шанс выйти заграницу минимален, но всё равно проект делают на английском, придумывая как же перевести «ЧП», «ПБОЮЛ», или «ИНН». Имеются и плюсы, и минусы, не нужно быть совсем категоричным.
Мне кажется, что сейчас шанс выйти заграницу велик даже у приложений, которые двигают аггрегатами на наших заводах. Всё потому, что заграница сама приезжает и покупает местные компании.
Даже если и так, то представьте, что вы пишете приложение для маленькой конторки в маленьком городе. Потом при работе с зарубежной компанией вспоминаете, что уже однажды делали подобное в том самом проекте, только там все переменные на русском языке. А вам как раз нужно сбросить код/использовать его в текущем проекте.
Пример, конечно, взят с потолка и много проблем тут не будет, переписал и всё. Типа, решаем проблемы по мере их поступления. Но как по мне — это недальновидность. Сейчас уже давно не то изолированное время, как раньше. Да и то, тогда было недальновидностью.
То же самое, что называть переменные аббревиатурами и сокращать до неузнаваемости. Вроде скорость печати увеличивает, а потом хрен разберёшь.
Пример, конечно, взят с потолка и много проблем тут не будет, переписал и всё. Типа, решаем проблемы по мере их поступления. Но как по мне — это недальновидность. Сейчас уже давно не то изолированное время, как раньше. Да и то, тогда было недальновидностью.
То же самое, что называть переменные аббревиатурами и сокращать до неузнаваемости. Вроде скорость печати увеличивает, а потом хрен разберёшь.
Вы воруете код Ваших предыдущих работодателей?
Я думаю, зарубежным компаниям это может очень сильно не понравится…
Да и нашим тоже.
Я думаю, зарубежным компаниям это может очень сильно не понравится…
Да и нашим тоже.
Вы цепляетесь к словам. Тогда представьте, что вы работаете над своими проектами или располагаете полными правами на код, который пишете. Суть от этого не меняется.
Для меня нет особой проблемы переписать известный мне алгоритм. Кроме того, если свой проект был давно, то переписать может даже быстрее получится, чем найти оригинал и адаптировать.
А Вы скользкие примеры публично приводите…
А Вы скользкие примеры публично приводите…
Вы мне напомнили полицию мыслей из 1984. У вас навязчивая идея.
Давайте так.
Вы работаете в компании (А). Все права принадлежат компании А. Вы разрабатываете продукт для компании заказчика (В). Вы знаете, что заказчик из России и пишете код, буквально, на русском языке.
У вас новый проект для компании С, из какого-нибудь зарубежья. Проект по сути, то же самое, что проект для компании В, вы берёте основу из В и дописываете на английском (компания то зарубежная, негоже на русском писать). Будете ли вы переписывать на английском основу или оставите на русском или же будете писать аналог с нуля — неэффективный подход в любом случае, проще было изначально писать на английском.
Давайте так.
Вы работаете в компании (А). Все права принадлежат компании А. Вы разрабатываете продукт для компании заказчика (В). Вы знаете, что заказчик из России и пишете код, буквально, на русском языке.
У вас новый проект для компании С, из какого-нибудь зарубежья. Проект по сути, то же самое, что проект для компании В, вы берёте основу из В и дописываете на английском (компания то зарубежная, негоже на русском писать). Будете ли вы переписывать на английском основу или оставите на русском или же будете писать аналог с нуля — неэффективный подход в любом случае, проще было изначально писать на английском.
Я вот в толк не могу понять нафиг вводить еще один элемент в словарь языка? " ->"
одновременно numbers: Int и -> Int
func sumOf(numbers: Int...) -> Int {
var sum = 0
for number in numbers {
sum += number
}
return sum
}одновременно numbers: Int и -> Int
Предлагаете просто опустить стрелочку?
func sumOf(numbers: Int...) Int {}Зачем? func sumOf(numbers: Int...):Int {} всем более чем привычен. Но свой вопрос я снимаю. К примеру decorator(f: (Int) -> String) -> (Int) -> String читается проще чем decorator(x: (Int): Str): (Int): String
Вполня понятена возможность каринга. Может она пока и не реализованна но синтаксис предполагает возможнось реализации данной фичи.
«decorator(int->string f) int ->string» читается еще привычнее (для С/С++/C#/Java программистов конечно же). Но раз теперь пошла мода писать имя переменной перед ее типом, то да, стрелочки и двоеточия. Как по мне, так они все лишние, однозначность синтаксиса без них не пострадает при любом варианте.
Напомните, как в С объявить функцию, возращающую массив указателей на функции?
Чур, в cdecl не подглядывать!
Чур, в cdecl не подглядывать!
Что сложного?
Функция:
Указатель на функцию:
Массив указателей на функцию:
Функция, возвращающая указатель на массив указателей на функцию:
Размеры массива только нужно проставить, ну или убрать массив и оставить только указатель:
И что значит «не подглядывать в cdecl»? В stdcall, значит, можно? :)
P.S. Вот чудесная статья для начинающих C-программистов, которая объясняет чтение объявлений типов — www.unixwiz.net/techtips/reading-cdecl.html — очень доходчиво всё написано.
Функция:
int foo()Указатель на функцию:
int (*foo)()Массив указателей на функцию:
int (*foo[])()Функция, возвращающая указатель на массив указателей на функцию:
int (*(*foo())[])()Размеры массива только нужно проставить, ну или убрать массив и оставить только указатель:
int (**foo())()И что значит «не подглядывать в cdecl»? В stdcall, значит, можно? :)
P.S. Вот чудесная статья для начинающих C-программистов, которая объясняет чтение объявлений типов — www.unixwiz.net/techtips/reading-cdecl.html — очень доходчиво всё написано.
«Use -> to separate the parameter names and types from the function’s return type.»
Что не так? первое указывает на тип элементов массива/списка (еще не было времени, посмотреть про этот язык, в любом случае что-то итерируемое)
-> Int указывает, что эта функция возвращает Int. Подобный синтаксис используется в Haskell. В Scala тоже указывается, но чутка другим синтаксисом.
-> Int указывает, что эта функция возвращает Int. Подобный синтаксис используется в Haskell. В Scala тоже указывается, но чутка другим синтаксисом.
Я догадываюсь о ответе, но все же:
— есть ли отдельный компилятор?
— что насчет других платформ? или это чисто язык для Cacao/Carbon?
— есть ли отдельный компилятор?
— что насчет других платформ? или это чисто язык для Cacao/Carbon?
Не программист по основной деятельности, потому могу быть неправ, но ядро реальных потребительских вещей сейчас пишется на С/С++/С# и тому подобном, в силу факта, что такой код легко компилируется на целевое потребительское устройство.
В плане маркетинга и откусывания себе куска сообщества разработчиков — шаг хорош. Но со стороны пользы для людей — не очень хорошо выглядит. Ведь существуют миллиарды (хотя чую продешевил на пару порядков) строк кода на, скажем так, портируемых языках, над поддержкой и улучшением которых (и строк, и языков) стоило бы поработать для улучшения жизни людям. Вместо этого знаменитая фруктовая компания усложняет и без того непередаваемо сложную систему языков, компиляторов и платформ.
Почему нельзя доработать OpenGL, вместо создания поделки только для своей платформы. Почему не сделать поддержку C++ для Cocoa (и избавить разработчиков от необходимости писать порой слой совместимости).
Нет, мы будем придумывать ещё язык. ещё систему, книги, руководства, документации, на которые нужно тратить драгоценное время. И это время в итоге не окупится в виде полезного для всех кода. И это при том, что есть вещи, которые без знания Си и использования CoreFoundation претворить в жизнь невозможно.
В плане маркетинга и откусывания себе куска сообщества разработчиков — шаг хорош. Но со стороны пользы для людей — не очень хорошо выглядит. Ведь существуют миллиарды (хотя чую продешевил на пару порядков) строк кода на, скажем так, портируемых языках, над поддержкой и улучшением которых (и строк, и языков) стоило бы поработать для улучшения жизни людям. Вместо этого знаменитая фруктовая компания усложняет и без того непередаваемо сложную систему языков, компиляторов и платформ.
Почему нельзя доработать OpenGL, вместо создания поделки только для своей платформы. Почему не сделать поддержку C++ для Cocoa (и избавить разработчиков от необходимости писать порой слой совместимости).
Нет, мы будем придумывать ещё язык. ещё систему, книги, руководства, документации, на которые нужно тратить драгоценное время. И это время в итоге не окупится в виде полезного для всех кода. И это при том, что есть вещи, которые без знания Си и использования CoreFoundation претворить в жизнь невозможно.
Вы правы, но тут работает логика подхода vendor lock-in.
Потому что C++ это адски сложный язык. И не только для девелоперов но и для компилятора. Тот же C (а с ним и Obj-C) намного легче.
Ядро потребительских решений уже давно НЕ пишется ни на C ни на C++. С уходом технологий в веб на первое место вышли java, ruby ну и конечно C# для винды.
Ядро потребительских решений уже давно НЕ пишется ни на C ни на C++. С уходом технологий в веб на первое место вышли java, ruby ну и конечно C# для винды.
Технологии уходят в веб, но Swift к этому имеет ровно такое же отношение, как и Obj-C, С++ и ещё немалая доля языков.
Создавать у пользователя на устройстве только обёртки, а всё остальное держать вовне подход хороший, но не всегда. В то время как мощности карманных устройств растут, неосмотрительно их не использовать для улучшения пользовательского опыта. И здесь в игру вступает логика, описывать которую на своём языке для каждой платформы накладно.
Что до сложности С++, не соглашусь. Сложны инструменты, а не язык. Boost не часть языка. Даже от STL можно отказаться. Как раз за создание более простых инструментов для существующих языков я и агитирую. А вот глазами компилятора я смотреть не умею.
Создавать у пользователя на устройстве только обёртки, а всё остальное держать вовне подход хороший, но не всегда. В то время как мощности карманных устройств растут, неосмотрительно их не использовать для улучшения пользовательского опыта. И здесь в игру вступает логика, описывать которую на своём языке для каждой платформы накладно.
Что до сложности С++, не соглашусь. Сложны инструменты, а не язык. Boost не часть языка. Даже от STL можно отказаться. Как раз за создание более простых инструментов для существующих языков я и агитирую. А вот глазами компилятора я смотреть не умею.
Тоже не соглашусь со сложнеостью, тут на днях занимался одним проектиком старым, который вырос из одного примера найденного на просторах сети, там плотно используется lexx и bison, ну и для взаимодействия с моим кодом С, [хотя сам код на C++. Любая правка парсера/лексера приводила к утомительному дебагу, нулевым указателям, утечкам памяти итд… Короче меня это достало, и за день все было переписано на С++/string/shared_ptr, после чего приложение завелось и тстабильно работает, правки приврдять к ожидаемым результатам.
Ну и визуально код стал намного проще и понятнее…
Ну и визуально код стал намного проще и понятнее…
Смешно читать про выход на первое место ruby. Скорее уж python, на нем хотя бы программистов найти можно.
Программист, раньше писал на C++ теперь перешел на Objective-C и пишу под iOS. На Objective-C писать мне проще и моя производительность выросла в пару раз. Плюс порог входа программиста стал гораздо ниже (Symbian тому пример), в результате стало проще нанять в 2 раза больше людей и выпустить в 2 раза больше продуктов.
Смысл в том, чтобы программист не тащил за собой багаж в виде готового кода, который вообще хрен знает что содержит. А писал сразу правильно, с пониманием философии нового языка.
Как тут уже было сказано, в Swift нету try-catch и для этого, скорее всего, есть логичное объяснение (например, так производительность в целом можно улучшить). В предлагаемом вами варианте для «совместимости» придется тащить костыль механизма бросания исключений, а получим в итоге что-нибудь типа win.api с совместимостью в обе стороны на много десятилетий вперед и назад.
Как тут уже было сказано, в Swift нету try-catch и для этого, скорее всего, есть логичное объяснение (например, так производительность в целом можно улучшить). В предлагаемом вами варианте для «совместимости» придется тащить костыль механизма бросания исключений, а получим в итоге что-нибудь типа win.api с совместимостью в обе стороны на много десятилетий вперед и назад.
>> в Swift нету try-catch и для этого, скорее всего, есть логичное объяснение (например, так производительность в целом можно улучшить)
Нельзя. Об ошибках все равно надо как-то сообщать, и без исключений будут коды ошибок (и, соответственно, их явная обработка через if или switch на вызывающей стороне). В случае, когда чаще всего функция возвращает успешный результат, коды ошибок по скорости проигрывают современной реализации исключений через таблицы, у которых вообще нулевой оверхед при отсутствии ошибок.
Нельзя. Об ошибках все равно надо как-то сообщать, и без исключений будут коды ошибок (и, соответственно, их явная обработка через if или switch на вызывающей стороне). В случае, когда чаще всего функция возвращает успешный результат, коды ошибок по скорости проигрывают современной реализации исключений через таблицы, у которых вообще нулевой оверхед при отсутствии ошибок.
Обработка исключений весьма затратная по времени и местами не интуитивно понятна. Apple предлагает другой подход к обработке ошибок, без исключений, для которого они могли применить свои оптимизации, сильно отличающиеся от традиционных подходов.
А вообще ваше безальтернативное заявление об исключениях напоминает мне историю, когда студенты изготовили изогнутое лобовое стекло потому что им не сказали, что учеными было доказано, что сделать это невозможно.
А вообще ваше безальтернативное заявление об исключениях напоминает мне историю, когда студенты изготовили изогнутое лобовое стекло потому что им не сказали, что учеными было доказано, что сделать это невозможно.
>> Обработка исключений весьма затратная по времени
Исключения называются исключениями именно потому, что они должны быть исключительными. Т.е. в большинстве случаев, при вызове метода, они не происходят. Как уже отмечено выше, при табличной реализации обработчиков исключений, затраты для неисключительного случая — нулевые. То есть буквально, ни одной лишней инструкции по сравнению с кодом без обработки ошибок вообще.
>> Apple предлагает другой подход к обработке ошибок, без исключений, для которого они могли применить свои оптимизации, сильно отличающиеся от традиционных подходов.
Apple в данном случае вообще никакого подхода толком не предлагает — в language guide написано только, что «можно использовать optional». На практике это означает обязательное использование if или switch в точке вызова, а во что компилируются условные операторы в LLVM, мы прекрасно знаем по другим языкам (тот же Clang). Опять же, можете посмотреть на листинг генерируемого кода, благо что компилятор уже есть (я бы и сам посмотрел, но у меня нет OS X). Зачем рассказывать о каких-то волшебных «своих оптимизациях» без указания конкретики? Если конкретика есть, давайте в студию, и обсудим её, и какие у неё характеристики в плане производительности по сравнению с табличными исключениями.
>> А вообще ваше безальтернативное заявление об исключениях
Я не делал безальтернативных заявлений об исключениях. Я просто сказал вам, что замена исключений на коды возврата (то, что предлагается в данном конкретном случае), для типичных паттернов использования исключений (когда они реально исключительные), и при их оптимальной реализации с нулевым оверхедом, не может улучшить производительность по чисто физическим причинам — во всяком случае, в отсуствие компилятора, генерирующего волшебные опкоды, которые исполняются за отрицательное число тактов процессора.
>> студенты изготовили изогнутое лобовое стекло потому что им не сказали, что учеными было доказано, что сделать это невозможно.
Это из того же разряда, что и шмель, который якобы по науке не может летать, но летает. Красивая история, но к действительности не имеет отношения, а на практике вредная именно потому, что используется для поддержки всякого рода научного фричества.
Исключения называются исключениями именно потому, что они должны быть исключительными. Т.е. в большинстве случаев, при вызове метода, они не происходят. Как уже отмечено выше, при табличной реализации обработчиков исключений, затраты для неисключительного случая — нулевые. То есть буквально, ни одной лишней инструкции по сравнению с кодом без обработки ошибок вообще.
>> Apple предлагает другой подход к обработке ошибок, без исключений, для которого они могли применить свои оптимизации, сильно отличающиеся от традиционных подходов.
Apple в данном случае вообще никакого подхода толком не предлагает — в language guide написано только, что «можно использовать optional». На практике это означает обязательное использование if или switch в точке вызова, а во что компилируются условные операторы в LLVM, мы прекрасно знаем по другим языкам (тот же Clang). Опять же, можете посмотреть на листинг генерируемого кода, благо что компилятор уже есть (я бы и сам посмотрел, но у меня нет OS X). Зачем рассказывать о каких-то волшебных «своих оптимизациях» без указания конкретики? Если конкретика есть, давайте в студию, и обсудим её, и какие у неё характеристики в плане производительности по сравнению с табличными исключениями.
>> А вообще ваше безальтернативное заявление об исключениях
Я не делал безальтернативных заявлений об исключениях. Я просто сказал вам, что замена исключений на коды возврата (то, что предлагается в данном конкретном случае), для типичных паттернов использования исключений (когда они реально исключительные), и при их оптимальной реализации с нулевым оверхедом, не может улучшить производительность по чисто физическим причинам — во всяком случае, в отсуствие компилятора, генерирующего волшебные опкоды, которые исполняются за отрицательное число тактов процессора.
>> студенты изготовили изогнутое лобовое стекло потому что им не сказали, что учеными было доказано, что сделать это невозможно.
Это из того же разряда, что и шмель, который якобы по науке не может летать, но летает. Красивая история, но к действительности не имеет отношения, а на практике вредная именно потому, что используется для поддержки всякого рода научного фричества.
Особой разницы для программиста в обработке ошибок через исключения или монадами(именно такой подход, имхо, уместен в случае swift) нет: вы либо разбираете значение монады в точке вызова (pattern matching против try), либо пробрасываете дальше преобразуя значение (map vs дальнейшего исполнения). Это нормальный функциональный подход.
С точки зрения скорости, не буду спорить, но чисто логически при одинаковости действий результирующий код должен быть схож.
С точки зрения скорости, не буду спорить, но чисто логически при одинаковости действий результирующий код должен быть схож.
Вместо этого знаменитая фруктовая компания усложняет и без того непередаваемо сложную систему языков, компиляторов и платформ.
А где тут собственно усложнение? Представлен простой и приятный язык вместо костыльного ObjC.
А вместо того чтобы биться головой об GLES, пытаясь выжимать по каплям хоть что-то, можно использовать удобный API, который позволит наконец задействовать возможности GPU.
Почему нельзя доработать OpenGL, вместо создания поделки только для своей платформы.
Устаревшие абстракции. Однопоточность. Отсутствие прекомпиляции шейдеров. Большие оверхиды везде. Костыли из расширений.
А вместо того чтобы биться головой об GLES, пытаясь выжимать по каплям хоть что-то
Подозреваю, что биться о GLES будут в любом случае в целях переносимости. Под Android в любом случае придётся пыжиться, а ради маркетинга будет не выгодно, если на каком-нибудь новеньком Samsung Galaxy S6 игра будет «в 10 раз медленнее»*, чем на новеньком iPhone 6.
А если всё же начнётся массовое применение Metal, то боюсь у нас будет зоопарк подобного лоу-левела в исполнении NVIDIA, Intel, ARM и Qualcomm, причём несовместимого друг с другом. Ну либо пойдут стопами NVIDIA, реализовав на мобильных чипах полный OpenGL 4.4 с AZDO.
* — согласно заверениям Apple.
Насколько я заметил проглядев по-диагонали документацию, Metal не настолько низкоуровневый, как его малюют. Это скорее осовремененный DX11 с яблочным соусом.
iOS стремится быть «консолью» и это хорошо. Нативный код, фиксированная конфигурация. А главное — единообразный API. GL всё-таки инородный.
iOS стремится быть «консолью» и это хорошо. Нативный код, фиксированная конфигурация. А главное — единообразный API. GL всё-таки инородный.
iOS стремится быть «консолью» и это хорошо. Нативный код, фиксированная конфигурация. А главное — единообразный API. GL всё-таки инородный.
По большому счёту iOS всегда и была консолью. Несколько лет была на PVR5 и ARMv7, только сейчас смена на ARMv8 и PVR6, так что, видимо, снова на несколько лет связка обеспечена. Ну и API, естественно, логичный шаг. Хотя непонятно, что с Mac. В OS X новой походу не собираются обновлять OpenGL, и непонятно, где там с compute shaders играться. ну то есть sdk-то не дали, а opengl на маке древний и без compute-части. Получается, на самих устройствах.
В общем, я против этого Metal, если он приведёт к ситуации, где у каждого GPU будет по своему API. Хотя в этом случае небось плюнут и будут писать как обычно с
А вообще может быть выстроен сценарий, что для кроссплатформы юзайте WebGL, а для эксклюзивов — все эти ваши Metal/Mantle и прочее, что сейчас нарожает воспалённое воображение в ARM, Qualcomm, NVIDIA и Intel.
Почему нельзя доработать OpenGL, вместо создания поделки только для своей платформы. Почему не сделать поддержку C++ для Cocoa (и избавить разработчиков от необходимости писать порой слой совместимости).
Потому что Apple зарабатывает деньги на максимальной сильной привязке к своей платформе.
Очень приятное впечатление от языка, синтаксис генериков очень похож на c#
О святые инновации! Большинство этих «фич» давно есть в Java, C#, ActionScript и прочих…
Собственно и что? «Фичи» перечисленных языков пришли из других языков программирования. Вопрос только в том, кто сделает язык программирования, который будет лишен недостатков традиционных подходов. У apple, на первый взгляд, вышло весьма неплохо. Немало моих друзей-программистов с интересом на него смотрят, поскольку теперь можно делать приложения для ios/osx не изучая громоздкий Obj-C.
Нужно ли знать Objective-C если решился писать под iOS/OSX и решил использовать только C++ и Swift?
Хватит только Swift.
Можно не знать. Документация по системным API обновлена для двух языков. Так что можно читать сразу про API для Swift и не заморачиваться, как оно было во времена Obj-C. Для работы со сторонними фреймворками и библиотекам пригодится понимание как транслируются имена Obj-C в Swift.
крайне желательно быть знакомым с Objective-C, хотя бы потому что куча примеров, проблем-решений (ресурсы типа stackoverflow), и сторонних библиотек на Objective-C.
Посмотрел документацию. Язык в целом не плох для не чисто функционального языка.
Ясть весьма интересные фичи. Особенно хорош оператор switch, позволяющий реализавать pattern matching.
Ясть весьма интересные фичи. Особенно хорош оператор switch, позволяющий реализавать pattern matching.
Чем-то похож на Lua :)
Pascal, Lua, Java???
С Pascal, Lua ничего общего.
Только в последних версиях Java появились замыкания.
Тренд к функционально-объектным языкам в целом понятен и не может не радовать.
Хотя без таких костылей как generics можно было бы и обойтись.
С Pascal, Lua ничего общего.
Только в последних версиях Java появились замыкания.
Тренд к функционально-объектным языкам в целом понятен и не может не радовать.
Хотя без таких костылей как generics можно было бы и обойтись.
Здорово, например, что можно будет вместо
писать
Вообще с objective-c дикое количество boilerplate'а выходит.
BLABlahBlahBlahViewController *blah = [[BLABlahBlahBlahViewController alloc] initWithStyle: BLABlahBlahBlahViewControllerFancyStyle];
писать
var blah = BlahBlahBlahViewController(style: .fancy)
Вообще с objective-c дикое количество boilerplate'а выходит.
Нет ли у кого-нибудь кроме меня безумного, абсолютно не подкрепленного разумными соображениями сделать реализацию компилятора этого языка под .NET или JS?
Давайте будем разумны. Если он LLVM-based то можно с небольшим допилом реализовать его как источник для Emscripten'а. Чисто поржать. Вообще LLVM идеальная платформа для экспериментов. А как нынче языки загоняют на .Net платформу? Наверняка есть какой-то рецепт красивый, был же бум Iron* проектов и прочих.
Парсер можно на основе Nitra соорудить.
Посмотрел Irony проект, наработки из IronRuby (как наиболее близкого к Swift'у), но это безумие и не имеет смысла, вы правильно сказали. Даже чисто гипотетически оба варианта — наркоманство, что притащить еще один язык на .Net (чтобы он там умер через полгода, как это было с Iron* проектами), что подтащить .Net платформу к языку. Минимум несколько месяцев нечеловеческой мозгопарьщины ради пары-тройки звездочек на гитхабе? :)
ждем Xamarin update
.NET — более высокоуровневая штука, на нее он плохо ляжет. Во-первых придется имитировать отсутствие GC :) Во-вторых большая часть фишек .NET в него не влезет — тот же рефлекшн, например.
Тоже самое примерно и с JS — там тоже есть GC, и очень многое построено на динамической типизации. А скорости от отказа от GC и динамики не получится.
Для .NET уже был весьма похожий по идеологии Boo (не знаю жив ли). Ну и F# вполне себе.
Для JS тоже есть масса всякого, гораздо более выгодно выглядящего. Кроме того, в JS чаще всего компилируют чтобы иметь один и тот же язык на клиенте и сервере. А зачем Swift на веб-сервере — не ясно совершенно, он по куче причин для этого не подходит.
Тоже самое примерно и с JS — там тоже есть GC, и очень многое построено на динамической типизации. А скорости от отказа от GC и динамики не получится.
Для .NET уже был весьма похожий по идеологии Boo (не знаю жив ли). Ну и F# вполне себе.
Для JS тоже есть масса всякого, гораздо более выгодно выглядящего. Кроме того, в JS чаще всего компилируют чтобы иметь один и тот же язык на клиенте и сервере. А зачем Swift на веб-сервере — не ясно совершенно, он по куче причин для этого не подходит.
Основная причина не портировать его на .NET — у него модель памяти на подсчете ссылок. Это можно реализовать и поверх дотнетовской объектной модели, конечно (и это придется делать, чтобы обеспечить корректную семантику деинициализации в соответствии спекой), но GC-то внизу все равно будет сидеть и кушать ресурсы. Плюс при передаче Swift'ного объекта в другой .NET-язык, последний не сможет корректно считать ссылки.
Так что получится что-то вроде ISO-стандартной части C++/CLI — вроде и компилируем в IL, но толку от этого ноль, т.к. реально фичи рантайма не используются.
Так что получится что-то вроде ISO-стандартной части C++/CLI — вроде и компилируем в IL, но толку от этого ноль, т.к. реально фичи рантайма не используются.
Насчет подсчета ссылок, прошу прощения за возможно глупый вопрос — но есть ли принципиальная необходимость сохранять данную семантику? Я подозреваю, что можно написать программу, которая будет выдавать несколько разные результаты в зависимости от того, используется ли подсчет ссылок или сборщик мусора, но это будет синтетический пример.
Если мы ориентируемся на .NET, мы заведомо знаем, что на ней есть GC и JIT, которые потребляют какие-то ресурсы и, вполне возможно, программа будет работать чуть медленнее, чем на оригинальной платформе. Но суть порта была не в том, чтобы сделать реализацию, не уступающую существующей в производительности ни на процент — а в том, чтобы расширить область применения языка Swift.
Если мы ориентируемся на .NET, мы заведомо знаем, что на ней есть GC и JIT, которые потребляют какие-то ресурсы и, вполне возможно, программа будет работать чуть медленнее, чем на оригинальной платформе. Но суть порта была не в том, чтобы сделать реализацию, не уступающую существующей в производительности ни на процент — а в том, чтобы расширить область применения языка Swift.
Есть принципиальная, и примеры будут вполне реальные, причем на самом простом коде. Например, хотите вы в функции открыть и попользовать файл:
Поскольку подсчет ссылок гарантирует, что объект будет детерминистически деинициализирован при выходе из функции, файл не нужно явно закрывать, даже если где-то в середине будет return. С GC такой гарантии нет, и код, написанный под детерминистическую модель, будет вести себя некорректно.
func foo() {
let f = File("foo.txt");
...
// ссылка умерла файл закрылся
}
Поскольку подсчет ссылок гарантирует, что объект будет детерминистически деинициализирован при выходе из функции, файл не нужно явно закрывать, даже если где-то в середине будет return. С GC такой гарантии нет, и код, написанный под детерминистическую модель, будет вести себя некорректно.
Страх господень, зачем case-префикс у элементов enum'a? Читаешь пост, блок за блоком наблюдаешь разумные упрощения синтаксиса действительно громоздкого Obj-C, попутно унаследовавшего излишнюю чувствительность C (типа скобочек для condition'а у if'а и бессмысленного typedef'а) и доходишь до начала описания enum'а, радуешься и, внезапно, на тебе леща, любитель легкой типизации и изящества — пиши case для каждого элемента. Извращенцы, блин.
Необязательно, там их просто можно через запятую перечислять.
А ключевое слово case там не спроста — Swift взял много из функциональны, enum-ы в нем похожи на case-class в скале или на конструкторы типов в хаскелле. Книжку по нему посмотрите, поймете.
enum MyEnum: Int {
case E1, E2, E3, E4
}
А ключевое слово case там не спроста — Swift взял много из функциональны, enum-ы в нем похожи на case-class в скале или на конструкторы типов в хаскелле. Книжку по нему посмотрите, поймете.
Зато как удобно, что тип Enum'а можно опускать во многих операциях:
Очень жалко, что такого нет в C#.
let myValue = MyEnum.FieldA
// в условиях
if myValue == .FieldB { ... }
// и в switch
switch myValue {
case .FieldC: ...
}
Очень жалко, что такого нет в C#.
Чума будет, когда кто-то сделает транслятор Swift в JS — я думаю эта штука затмит собой остальные попытки исправить JS.
Зачем, черт побери? Это уже второе предложение скрестить/заменить/подружить овчарку и енота-полоскуна. Вам мало JS-производных наречий или что? Что это за фатальный недостаток JS, который нужно (безумцы) устранить с помощью еще толком не обрекшего тело языка из совсем другой оперы?
По моему тут путаница языка и области его применения.
Я думаю что можно, в итоге, сэкономить время разработки и иметь более широкое сообщество по языку.
Я думаю что можно, в итоге, сэкономить время разработки и иметь более широкое сообщество по языку.
Понял о чем вы, погорячился, мои извинения. Трансляторов в JS с кучи языков пруд пруди, хотя на мой взгляд это попахивает легкой наркоманией.
Придется имитировать отсутствие GC :)
На самом деле сложность не в изучении языка как такового, а в изучении всех фрэймворков Apple. Именно на изучение парадигмы этих библиотек уходит львиная доля времени.
Сам испытал это на себе, когда купил RubyMotion. Но на него уже понаписали достаточно врапперов над Cocoa, которые существенно упрощают жизнь и делают вещи «правильными», хотя не исключаю возможность, что правильными только для rails разработчика.
Сам испытал это на себе, когда купил RubyMotion. Но на него уже понаписали достаточно врапперов над Cocoa, которые существенно упрощают жизнь и делают вещи «правильными», хотя не исключаю возможность, что правильными только для rails разработчика.
Может, я буду слишком резок и субъективен, но…
А я знаааал, что Obj-C — отстой!:)
По теме:
С первого взгляда симпатично. Даже захотелось обзавестись яблочными девайсами и что-нибудь на нем написать:)
А я знаааал, что Obj-C — отстой!:)
По теме:
С первого взгляда симпатично. Даже захотелось обзавестись яблочными девайсами и что-нибудь на нем написать:)
Единственное, я не совсем понимаю, он уже готов к работе или пока только как игрушка?
Извините, а вы на нём писали?
Я вот на шарпе не писал, могу ли я из-за этого его называть отстоем?
Я вот на шарпе не писал, могу ли я из-за этого его называть отстоем?
Помогал товарищу в коде разбираться. Этого часа мне хватило, чтобы понять, что я никогда по собственному желанию не буду на этом кодить.
Такого отвращения я даже от сложных однострочников на Перл не испытывал, поскольку там весь этлт ужас был намеренным, а не из-за того, что язык такой.
О том, что все это субъективно, я написал выше
Такого отвращения я даже от сложных однострочников на Перл не испытывал, поскольку там весь этлт ужас был намеренным, а не из-за того, что язык такой.
О том, что все это субъективно, я написал выше
А я один пытался читать пост через фирменное приложение Хабрахабр и ругался на автора за форматирование кода картинками?
Не вижу смысла публиковать код картинками с таким количеством мусора по краям.
Не вижу смысла публиковать код картинками с таким количеством мусора по краям.
Ещё вопрос на тему о сравнении Swift и JavaScript: что такого будет в Swift, чего нет в JavaScript (не считая возможности запускаться на айфонах да на айпэдах)?
Вопрос не риторический и не сократический, то есть он не имеет подразумеваемого мною ответа.
Вопрос не риторический и не сократический, то есть он не имеет подразумеваемого мною ответа.
Вы имеете в виду синтаксис языка, или возможности платформы?
Swift статически типизированный, со всеми вытекающими, обобщения выведение типов, классы и протоколы (интерфейсы) с методами расширения, pattern maching, а вообще сами языки как и их назначения очень отличаются
В JavaScript можно вот так сделать:
А в Swift — нет, потому что он со строгой типизацией, компилируемый и, как следствие, более быстрый. У Свифта хорошая задача — сделать ниже входной порог для начинающих разработчиков. Потому как, чтобы выучить Obj-C, надо выучить все 30 лет истории развития языка — очень непросто.
var name = "Alex";
name = 10;
А в Swift — нет, потому что он со строгой типизацией, компилируемый и, как следствие, более быстрый. У Свифта хорошая задача — сделать ниже входной порог для начинающих разработчиков. Потому как, чтобы выучить Obj-C, надо выучить все 30 лет истории развития языка — очень непросто.
Да ладно, выучить 30 лет истории… Порог входа у Obj-C достаточно мал. Единственное, почему-то всех пугают скобки и длинные названия.
Конечно изучение всех фреймворков займёт много времени, но это уже не сам язык как таковой.
На мой взгляд он не сделает порого входа ниже. Он скорее направлен на предоставление новых, модных фишечек для заманивания. Лично мне больше всего импонирует возможность использования функционального подхода для некоторых вещей.
Конечно изучение всех фреймворков займёт много времени, но это уже не сам язык как таковой.
На мой взгляд он не сделает порого входа ниже. Он скорее направлен на предоставление новых, модных фишечек для заманивания. Лично мне больше всего импонирует возможность использования функционального подхода для некоторых вещей.
Ээээм, ну а разницу между скажем C++ и JavaScript вы видете? Если да, то тут почти тоже самое. Хотя Swit не поддерживает метапрограммирование и возможности работы на низком уровне жёстко зафиксированы, а не произвольны как в C++. Однако в любом случае это статически типизированный компилируемый язык, дающий полный доступ к API операционной системы.
Я один во время паузы перед появлением названия нового языка Swift, верил и надеялся что это будет С# или Java?!
Я действительно не понимаю зачем изобретать все эти велосипеды с новыми недоязыками, вместо того чтобы использовать давно известные, отлаженные и накачанные действительно толковыми фичами языки.
Я действительно не понимаю зачем изобретать все эти велосипеды с новыми недоязыками, вместо того чтобы использовать давно известные, отлаженные и накачанные действительно толковыми фичами языки.
Дык фатальный недостаток!
ну а если серьезно, если использовать C# или Java, можно получить иск в суд, как уже было с гуглом.
И это даже не говоря о технических проблемах.
ну а если серьезно, если использовать C# или Java, можно получить иск в суд, как уже было с гуглом.
И это даже не говоря о технических проблемах.
Вообще то Swift выглядит посильнее Java и C#. Он скорее ближе к упрощённому D…
Грустно, что в который раз очередная крупная компания изобретает новый язык, понадёргивав в него функций из D (как это было с C#, например, да и Rust имеет очень много заимствований, не говоря уже о последних спецификациях C++), вместо того, чтобы популяризировать сам D.
>понадёргивав в него функций из D
D — не является первоисточником всех конструкций, они были задолго до него. А D сам довольно сложный — это раз. Второе — Эпплу надо было сделать язык на базе рантайма Objective C чтобы было полная взаимная совместимость. Это, в частности, привело к ARC вместо GC (как в D). Так что не было шансов использовать именно D.
D — не является первоисточником всех конструкций, они были задолго до него. А D сам довольно сложный — это раз. Второе — Эпплу надо было сделать язык на базе рантайма Objective C чтобы было полная взаимная совместимость. Это, в частности, привело к ARC вместо GC (как в D). Так что не было шансов использовать именно D.
В принципе согласен. Но в случае Apple как раз совсем не удивлён — это как раз полностью укладывается в их стиль. )
Толковые фичи типа кривых generics с type erasure?
Подскажите, как в Swift реализуются модификаторы доступа (public, private и т.п.)? Книжку просмотрел несколько раз, не нашел.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Swift — нововведения