| 1.1, Аноним (-), 09:20, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Кто - нибудь объяснит: для чего официальные сборки подготавливают для Linux?
| | |
| |
| 2.2, A.Stahl (ok), 09:23, 30/03/2018 [^] [^^] [^^^] [ответить]
| +11 +/– |
 Реклама. "Какие мы открытые и вы, сраные прыщавые очкарики, тоже можете приобщиться к прекрасному и подумать иначе". А технически, вероятно, поддержка двух платформ почти ничего не стоит. Поэтому под Винду и нет версии.
| | |
| |
| 3.5, Солнышко (??), 09:39, 30/03/2018 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Основа потому что nix.
А кто-нибудь скажет компетентный, есть хоть какие-то преимущества использования этого поделия на Linux? Как язык? Как Python?
Я вот на Clojure пишу для бытовых задач и небольших личных проектов и все тип-топ. Зачем еще и Swift?
| | |
| |
| 4.13, rscx64_ (?), 09:55, 30/03/2018 [^] [^^] [^^^] [ответить]
| +5 +/– |
может вдруг его не для целей "заменить твой clojure" делали? может для своих яблочных задач?
| | |
| |
| |
| 6.64, Аноним (-), 14:35, 30/03/2018 [^] [^^] [^^^] [ответить]
| –6 +/– |
Не знаю как он, но разработчики homebrew поголовно сидят на линуксе. Мак не готов для разработчика.
| | |
| |
| 7.71, Anin (?), 15:32, 30/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вас не смущает что homebrew на линуксе это порт от маковской версии?
| | |
| |
| 8.75, Аноним (-), 15:57, 30/03/2018 [^] [^^] [^^^] [ответить] | +/– | homebrew как раз оригинал на маке Для линукса linuxbrew Под консольку на лине ... текст свёрнут, показать | | |
| |
| 9.87, Аноним (-), 03:29, 31/03/2018 [^] [^^] [^^^] [ответить] | +/– | Да ну вон там уже зашкаливает версия в NET и я слышал окна можно вращать в WPF ... текст свёрнут, показать | | |
|
|
| 7.90, Аноним (-), 05:53, 31/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>Мак не готов для разработчика
Ну да, ну да. Все коллеги сидят на таком не готовом маке, успешно кодят веб, и вообще тащатся.
| | |
|
|
|
| 4.15, Alexey (??), 09:59, 30/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вам он скорей всего никогда не понадобится. Его ниша - приложения для iOS, macOS и всего остального от эппл. Можно писать консольные и серверные приложения для Linux, но здесь наверно не взлетит т.к. много конкурентов. Как язык для бекенда его IBM пытается двигать: https://developer.ibm.com/swift/
| | |
| |
| 5.61, bOOster (ok), 14:28, 30/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Похожая разновидность ООЯП используется для программирования контроллеров XMOS. Даже можно сказать брат близнец, но с интересными доработками полного параллелизма многоядерной аппаратной реализации этих контроллеров.
| | |
|
| 4.24, _hide_ (ok), 10:27, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Вам бы в википедию заглянуть :-)
А то Ваш вопрос обескураживает.
| | |
| 4.40, Аноним (-), 11:55, 30/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если у Вас последний гном, то есть преимущество. На этом языке можно писать смайлами!
| | |
|
|
| 2.44, Аноним (-), 12:09, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ничего не стоит портировать программу с макоси на линух, потому что оба никсы.
| | |
| |
| |
| 4.53, Аноним (-), 13:10, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
В чём собственно разница? Это очередной дистрибутив с нескучными обоями, только закрытый.
| | |
| |
| 5.72, kk (??), 15:37, 30/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Как вы считаете *BSD сильно от линукса отличается или нет? А солярка? А HP-UX?
| | |
|
|
|
|
| |
| 2.6, Солнышко (??), 09:40, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> чтобы на swift backend ы пилить
В чем преимущества языка по сравнению с Pyhon/Java/Ruby и т.п.?
| | |
| |
| 3.11, Аноним (-), 09:54, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Он нативный, быстрее и вообще был написан для iOS, где на вот этих ваших Python/Java/Ruby без костылей не попишешь
| | |
| |
| 4.22, Аноним (-), 10:21, 30/03/2018 [^] [^^] [^^^] [ответить]
| –16 +/– |
Это когда через LLVM, то нативный? Это сейчас такое у хипстеров нативным называется?
А вот Python - да, нативный.
| | |
| |
| 5.37, Ordu (ok), 11:37, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Ну вот сами и жрите своё нативное интерпретируемое гно с утиной типизацией и GIL. Хотя, java тут несколько выбивается -- там всё же многое можно решить статической типизацией, а если и динамической, то хотя бы доступ к полю не через хештабличку по имени. Но интерпретируемость тем не менее остаётся.
| | |
| 5.59, Аноним (-), 14:18, 30/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Это когда через LLVM, то нативный?
Да
>А вот Python - да, нативный.
Нет, интерпертируемый
| | |
|
| 4.31, trdm (ok), 11:03, 30/03/2018 [^] [^^] [^^^] [ответить]
| –4 +/– |
 > Он нативный
нативные языки для компьютера - только машинные коды.
Остальные языки требуют обработки для упаковки в машинные коды.
Т.о. чистых нативных популярных языков просто нет в природе.
Как и нативных контролов - они все популисткие допущения.
| | |
| |
| 5.32, Аноним (-), 11:08, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну значит моё допущение, я имел ввиду компилируемый, как собственно написали чуть ниже
| | |
|
|
| 3.14, rscx64_ (?), 09:56, 30/03/2018 [^] [^^] [^^^] [ответить]
| +7 +/– |
swift это компилируемый язык а не интерпретируемый, почему ты вообще его сравниваешь с ruby/python/остальными? просто игнорируй факт того что он существует
| | |
| 3.63, bOOster (ok), 14:33, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> чтобы на swift backend ы пилить
> В чем преимущества языка по сравнению с Pyhon/Java/Ruby и т.п.?
Вообще отличное сравнение. Язык уровня С++ который практически напрямую ложиться в машинные коды, сравнивать с интерпретаторами и виртуальными машинами. Все в кучу...
-"Вы уж либо трусы наденьте, либо крестик сымите"
| | |
|
|
| 1.7, ДяДя (?), 09:43, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
> Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты.
Это оксюморон!!!
Формально с точки зрения теории сборки мусора подсчёта ссылок на объекты является сборкой мусора.
| | |
| |
| 2.8, Аноним (-), 09:50, 30/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Хер там, циклические зависимости подсчет ссылок не разрулит.
| | |
| |
| 3.16, angra (ok), 09:59, 30/03/2018 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Погугли weak reference
У каждого сборщика мусора есть свои проблемы. Но наличие проблем не превращает их в другие сущности. Другое дело, что большинство технически безграмотно и считает трассирующие сборщики мусора их единственным вариантом.
| | |
| |
| 4.86, Аноним (-), 23:29, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>Погугли weak reference
Я прекрасно знаю что такое weak reference. И то что их ставить надо руками. В отличие от сборщика мусора где просто все работает само и ничего делать не надо.
| | |
|
|
| 2.12, Alexey (??), 09:55, 30/03/2018 [^] [^^] [^^^] [ответить]
| –6 +/– |
в Swift подсчет ссылок выполняется на этапе компиляции а не выполнения как в Java. На мобилках отсутствие GC визуально заметно.
| | |
| |
| 3.17, angra (ok), 10:04, 30/03/2018 [^] [^^] [^^^] [ответить]
| +5 +/– | |
В java вообще не выполняется подсчет ссылок, там принципиально другой сборщик мусора. Ну и задача тебе на каникулы, напиши программу, которая примет от пользователя число, а потом создаст массив с количеством объектов, равным введенному числу, а потом по очереди их из массива уберет. Помедитируй над подсчетом ссылок во время компиляции в этом случае.
| | |
| |
| 4.28, Alexey (??), 10:31, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
А в чем проблема? Код arc не читал, но документация утверждает что после прекращения использования объекта он зарелизится (уменьшится количество ссылок на 1), если количество сылок будет равно 0 то объект удалится. Это раньше надо было делать руками в Objective-C, с появлением arc просто пропала необходимость писать [object release].
> В java вообще не выполняется подсчет ссылок, там принципиально другой сборщик мусора.
возможно я ошибся, на java не пишу
| | |
| |
| 5.46, Crazy Alex (ok), 12:13, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 Вы путаете автоматический подсчёт ссылок (который делается в рантайме, разумеется, но не требует явных указаний со стороны программиста) с "подсчётом на этапе компиляции" что, разумеется, невозможно кроме совсем уж частных случаев или введения очень жёстких правил доступа и контроля времени жизни, как в Rust.
| | |
|
|
| 3.25, ДяДя (?), 10:27, 30/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> в Swift подсчет ссылок выполняется на этапе компиляции
Это невозможно.
| | |
| 3.26, ДяДя (?), 10:29, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>в Swift подсчет ссылок выполняется на этапе компиляци
Это невозможно в нашей Вселенной.
| | |
|
| 2.27, _hide_ (ok), 10:31, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Не является. Потому что подсчет ссылок приводит к перманентному удалению объекта, а не к отложенной очистке.
Так что подсчет ссылок и сборка мусора является способами управления жизненным циклом объектов, просто частенько их используют вместе.
| | |
| |
| 3.42, ДяДя (?), 12:03, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
См. первоисточники.
Чисто формально в OpenJDK вообще не сборка мусора, а поиск живых объектов.
| | |
|
| 2.50, Аноним84701 (ok), 13:02, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 >> Вместо сборщика мусора в Swift используются средства подсчёта ссылок на объекты.
> Это оксюморон!!! Формально с точки зрения теории сборки мусора подсчёта ссылок на объекты является
> сборкой мусора.
Это маркетология.
Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
| | |
| |
| 3.67, Анонимусис (?), 15:00, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
во-первых arc = automatic reference counting, перевод нужен?
во-вторых в питоне все же другой алгоритм
| | |
| |
| 4.69, Andrey Mitrofanov (?), 15:08, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
> во-первых arc = automatic reference counting, перевод нужен?
Так вот вы про какой http://www.arclanguage.org/ "arc".
Что ж вы сразу-то молчали? :7
> во-вторых в питоне все же другой алгоритм | | |
| 4.70, Аноним84701 (ok), 15:17, 30/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Да и вообще, ARC звучит круче и солидней, чем "банальный и медленный счетчик ссылок, как в том же CPython, но без разруливания циклических зависимостей".
> во-первых arc = automatic reference counting, перевод нужен?
Ох уж эти фанаты.
С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?
А фигурирует оно везде почему-то как "ARC", хотя вне ябла обычно ограничиваются "ref(erence) count(ing)", т.к. всем причастным ясно, что оно, в этом контексте, обычно таки всегда автоматическое. Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
| | |
| |
| 5.78, Анонимусис (?), 18:10, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?
а потому что вы так свои комменты формулируете
>Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
молодой человек, вы таки хотите сказать, что kobject_put в этом вашем л-нуксе тормозной? (я надеюсь, вы сможете нагуглить что оно делает без сторонней помощи)
| | |
| |
| 6.81, Аноним84701 (ok), 18:33, 30/03/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>С чего это вы взяли, что аббревиатура мне не знакома или требует перевода?
> а потому что вы так свои комменты формулируете
В общем, из серии "сам додумал, сам оспорил" …
>>Потому что при неавтоматическом можно и сразу ручками проставлять free, вместо заботливого выписывания "inc(refX);dec(refY)" для тормозной обертки.
> молодой человек, вы таки хотите сказать, что kobject_put в этом вашем л-нуксе
Дедуля, про контекст, см "оно, в этом контексте" в предыдущем предложении было не ради красного словца написано. А то ведь ref. counting много где еще применяется - см. тот же гткшный gobject или ФС.
| | |
| |
| 7.82, Анонимусис (?), 19:08, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>Дедуля, про контекст, см "оно, в этом контексте" (т.е. – ЯП) в предыдущем предложении было не ради красного словца написано.
внучек, контекст заключается в том, что "подсчет ссылок" и "использование malloc/free" --- это ни разу не антонимы, это во-первых.
во-вторых, можно ручками (как в л-нуксе) прописывать вызовы к манипуляторам рефкаунта, а можно сделать так, чтобы компилятор сам это делал. собственно ябл и сделал второе
| | |
|
|
| 5.79, Crazy Alex (ok), 18:17, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Оно ARC потому что до 2013-го, кажется, года оно именно ручным и было (плюс костыль NSAutoreleasePool), а потом эппл таки сподобилась сделать автомат и обозвала это дело ARC.
| | |
|
|
|
|
| |
| 2.10, A.Stahl (ok), 09:53, 30/03/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
А ведь там наверное не только компилятор, но и стандартная либа, линковщик, дебаггер, профайлер...
Так что это проще назвать "язык" и не заниматься излишним буквоедством.
| | |
| 2.55, Аноним (-), 13:37, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Там не только компилятор, но и стандартная библиотека и спецификации на сам язык.
| | |
| |
| 3.56, Аноним (-), 13:40, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Там не только компилятор, но и стандартная библиотека и спецификации на сам
> язык.
Т.е. обновился именно язык, а в компиляторе лишь обеспечили поддержку изменений.
| | |
|
|
| 1.18, Аноним (-), 10:08, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Нет, ну, конечно, есть надежда, что будет реализована возможность разработки для IOS на Linux дистрах...
| | |
| |
| 2.23, anonas (?), 10:27, 30/03/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
писать то можно на чем угодно, вот скомпилировать и залить в стор получается только на маке :(
| | |
| |
| 3.91, Аноним (-), 05:59, 31/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> писать то можно на чем угодно, вот скомпилировать и залить в стор
> получается только на маке :(
И правильно, нефиг плодить разработчиков-маргиналов.
| | |
|
|
| 1.21, Аноним (-), 10:17, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
как они задолбали со своими новыми версиями. вместо того чтобы код писать, постоянно приходится разруливать результаты преобразования к очередному диалекту.
| | |
| |
| 2.29, A.Stahl (ok), 10:35, 30/03/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
Сишники и плюсовики удивлённо переглядываются и хохмы ради пытаются вспомнить когда в последний раз новый стандарт ломал что-то такое, что к этому моменту не успело безнадёжно устареть и иногда кем-то использовалось.
| | |
| |
| 3.36, Crazy Alex (ok), 11:26, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Ну так это ж не эппловская песочница, где разработчиков можно куда угодно загнать. А сишный или плюсовый "стандарт", ломающий совместимость, тупо остался бы на бумаге.
| | |
| 3.45, iPony (?), 12:12, 30/03/2018 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Сишники и плюсовики удивлённо переглядываются и хохмы ради пытаются вспомнить когда в последний раз новый стандарт ломал что-то такое,
А мне вот что-то плакать хочется 😢
Потому что, если ты чисто пишешь Hello World ы то, это дно. А на практике все равно со всеми стыками взаимодействия ломается всё и вся.
| | |
| |
| 4.80, Crazy Alex (ok), 18:18, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
Для всего хоть как-то актуального есть минимум 14 плюсы. В которых, да, auto_ptr заменили на share_ptr + unique_ptr.
| | |
| |
| 5.93, Анонимусис (?), 14:58, 31/03/2018 [^] [^^] [^^^] [ответить]
| +/– | |
>Для всего хоть как-то актуального
у вас актуальное только винда да лялекс
для глубокого эмбеддеда не все так однозначно
| | |
|
|
|
|
| 1.47, iZEN (ok), 12:15, 30/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
 Нужно больше языков на разных версиях LLVM. У меня, например, на FreeBSD сейчас два LLVM-5.0.1: системный и прикладной для Mesa3D и Rust и ещё один LLVM-6.0.0 ждёт своего часа для обновлённого порта Rust (который будет использоваться в будущих версиях Firefox, выходящих через неделю). Ждём чего-то полезного на Swift, который к тому времени будет требовать LLVM-7.0.0.
| | |
| |
| 2.58, Moomintroll (ok), 14:16, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Swift, который к тому времени будет требовать LLVM-7.0.0
Когда я последний раз смотрел на Swift, он требовал патченного LLVM и, соответственно, не мог использовать системный...
С тех пор что-нибудь изменилось?
| | |
| 2.60, Аноним84701 (ok), 14:18, 30/03/2018 [^] [^^] [^^^] [ответить]
| +/– |
> будет использоваться в будущих версиях Firefox, выходящих через неделю). Ждём чего-то
> полезного на Swift, который к тому времени будет требовать LLVM-7.0.0.
Могу "посоветовать" pure (" Modern-style functional programming language", в чем-то прикольный ЯП, основывающийся на term-rewriting) - зависит от llvm 3.5, openshadinglanguage (llvm 4.0), ponyc ("Pony language compiler") - llvm 5.0.
Для полноты набора, так сказать :)
| | |
|
| 1.88, Аноним (-), 03:31, 31/03/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Пока яблойды не портируют свою Какоу или Кокау или каккау под линус толку от всех этих языков просто не будет. А по понятным причинам какуау портировать не будут так как она наследине некста и вообще у линукойдов свой гтк на пару с аляпистым кутэ
| | |
| |
| 2.97, csdoc (ok), 16:26, 01/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Сколько весит hello world! на Swift?
Hello.swift:
print("Hello, World!")
бинарник с отладочной информацией получается 14808 байт,
если сделать strip - будет 11408 байт.
$ swift -version
Swift version 4.1 (swift-4.1-RELEASE)
Target: x86_64-unknown-linux-gnu
P.S.
Swift можно поставить на убунту и самому попробовать, https://swift.org/download/
| | |
|
| 1.98, csdoc (ok), 16:51, 01/04/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
подробное объяснение, почему в Swift сделали ARC
и не сделали полноценный GC, как например, в Java:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.
[swift-evolution] What about garbage collection?
[...]
> Has a GC been considered at all?
GC also has several *huge* disadvantages that are usually glossed over: while it is true that modern GC's can provide high performance, they can only do that when they are granted *much* more memory than the process is actually using. Generally, unless you give the GC 3-4x more memory than is needed, you’ll get thrashing and incredibly poor performance. Additionally, since the sweep pass touches almost all RAM in the process, they tend to be very power inefficient (leading to reduced battery life).
I’m personally not interested in requiring a model that requires us to throw away a ton of perfectly good RAM to get an “simpler" programming model - particularly on that adds so many tradeoffs.
| | |
| |
| 2.99, Анонимный аноним (?), 20:43, 01/04/2018 [^] [^^] [^^^] [ответить]
| +/– |
> подробное объяснение, почему в Swift сделали ARC и не сделали полноценный GC, как например, в Java:
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.
Оттуда же, для танкистов:
> Technically speaking, reference counting is a form of garbage collection,
> Since there are multiple forms of GC, I'll assume that you mean a generational mark and sweep algorithm like you’d see in a Java implementation. | | |
|
|
