Обсуждение

Не знаю, не знаю, GO уже оброс инфраструктурой и фактически стал "промышленным". Гугл за плечами дает о себе знать.

тем что не надо писать циклы?

Скорее наоборот - в джулия не надо векторизовать.

"Декларативен, но в меру" - что-то в этом есть!

они таки выкинули векторные операции? o_O и вместо а+1 пишут for i in 1:length(a) { a[i]=a[i]+1 } ? PS после их "теста скорости"ТМ использующего "разрезанный" классический пример на превосходство r-кода в матричных вычислениях над матлабоподобными языками я их не смотрел совсем.

Julia - грамотный проект в котором можно и поучаствовать. Не выкинули, но благодаря JIT стандартный способ оптимизации матлабовских расчетов с помощью векторизации необязателен.

Грамотного там увы не так много, их операции над матрицами "монолитны" и не дают возможность на высоком уровне получить промежуточные варианты вычислений (что они и продемонстрировали, поспешив "первыми задать" неудобный для них вопрос тест). А "быстрый цикл" порождает редукцию алгоритма к нагромождению ифов, форов и присваиваний. Гораздо проще и эффективнее сделать вставку кода на C(++).

"минимальный словарь" немецкого 1200-1500 слов, немного осталось :)

хрень какую-то написали: а то lapack и иже с ними позволяют вам получить промежуточные варианты матричных вычислений. >>А "быстрый цикл" порождает редукцию алгоритма к нагромождению ифов, форов и присваиваний. Гораздо проще и эффективнее сделать вставку кода на C(++). Опять же спорное утверждение. И на C вы будете без ифов, форов и присваиваний писать? Может быть приведете какой нибудь конкретный пример чем вам Julia не угодила и мы его предметно обсудим? Пока хозяин журнала не забанит.

Ага, если не учитывать многочисленные проблемы с родами и множественными числами и прочими словоформами (в том числе неправильными глаголами). Тут каждое слово за пяток слов в других языках должно идти, наверное.

1) Ну с моей точки зрения хрень какраз написали вы. А я четко сказал --- юля сводит все матричные операции к вызову лапака и ничего толком не может предложить когда нужен неполный результат (например это резко ускоряет вычисления) 2) Я четко сказал что нужны "быстрые циклы" --- делаем инлайн кода на C(++). Не надо приписывать мне утверждения и потом с ними бороться. 3) Я абсолютно равнодушен к юлии, поскольку я одинаково быстро пишу код и с циклами и векторизированный (но второй существенно короче получается (: ). Пример мне довольно долго искать .... Да и судя по вашему тону мне откровенно жаль тратить время. ЗЫ может писатели юлии с той поры и изменили что то в языке не смотрел, для анализа данных язык не удобен был уклоном в удобство написания программ.

Извините за недопонимание. 1) Полностью согласен - но эта проблема будет у всех мат ориентированных языков: Matlab/R/Octave/Mathematica/Numpy 2) Быстрые циклы на inline C++ - это стандартное решение, к сожалению по моему мнению тяжелее поддерживать. Сейчас идет сильное течении использовать разного типа jit оптимизации - LuaJIT, тоже самое для Питона, поэтому скоро разрыв менжду for циклами в C и JIT оптимизированных языках сократится. 3) Есть задачи которые просто не ложатся в векторную оптимизацию - например преобразование Хофа (Радона) и активно используются в распозновании изображений. Поэтому я ждал julia 0.3 чтобы активно попользовать - используя старые наработки из матлаба.

1) Но не у APL(J) подобных (у них можно только к масштабируемости предъявить претензии). Для "особых" случаев построить на их операторах нужный вариант нестандартного алгоритма очень эффективно (по затратам и получающейся производительности). Тот же R(S) вовсю операторы из APL(J,K) потянул. 2) Rcpp очень популярен. Код единым получается. и каждая часть отвечает за наилучший случай. Безусловно иметь "быстрый цикл" это чисто профит (хотя и провоцирует писать крайне низкоуровневый код). 3) Да, хотя 80 процентов кода укладывается в apply-filter-reduce.

> Кто-нибудь может мне эту симпатичность объяснить? Грейдон Хоар, создатель другого языка (Rust) и ключевой сотрудник компании Mozilla, может. graydon2.dreamwidth.org/3186.html и graydon2.dreamwidth.org/189377.html

Меня в Джулии подкупают вещи типа @inbounds: https://gist.github.com/samtkaplan/5991236 См дискуссию: https://groups.google.com/forum/#!msg/julia-users/aYS_AvKqPCI/DyTiq4lKIAoJ

Спасибо, интересно.

О, питон плюс паскаль дал потомство.

Гипотеза: чтобы вещь (в частности, язык программирования) была именно "симпатичной" (не удобной, не практичной, не эффктивной и так далее), в ней должны быть мелкие несущественные устранимые недостатки. Та самая неидеальность, которая рождает индивидуальность. Примеры мелким симпатичных недостатков в джулии:

julia> round(pi)
ERROR: `round` has no method matching round(::MathConst{:π})

Нельзя просто взять и округлить число пи!

julia> if p 1 else if q 2 else 3 end end
ERROR: syntax: use "elseif" instead of "else if"

А конструкции правильные (правильно составленные из правильных элементов), но не идиоматичные, мы просто запретим нафиг. Хотя джулия тут не первая, оно ещё в джаве было (может, и раньше, но в документации по джаве меня впервые поразило).

Про каждый из этих двух примеров можно написать по абзацу, почему это так (ну... мои предположения, почему это так, я с авторами не общался на эту тему), и как их обойти, если правда надо.

... Не стой под стрелой и над душой! ...

Ну да: такая "симпатичность" типа родинки у манекенщицы -- когда есть поводы для дискуссии "бага это или фича". Но мне Julia симпатична почему-то на более общем уровне. Не по деталькам, а как бы по общему стилю. Удачная (как мне кажется) попытка сделать скриптовый нескриптовый язык, что никак не получается с попытками устроить jit-компиляцию в Питоне. Внимание к немелочам, типа "про метапрограммирование тоже не забыли, хотя многого не ждите" и "параллельность у нас есть, хотя многого не ждите".

Спасибо, этот "взгляд со стороны" (а не изнутри разработчиков Julia) как раз то, что я хотел бы видеть. Точка зрения Грейдона оказалась очень близка к моей точке зрения: "веб-застой" для языков прошёл, и наступает ренессанс -- прерванная линия развития как-то восстанавливается. В принципе, в этих текстах не так много из того, чего я бы не знал (а на многих помянутых там языках я умудрился ещё и попрограммировать, хотя и немножко). Но сама подача очень хороша. Он там впрямую сравнивает Лисп и Форт (вот это мне очень понравилось и было довольно для меня неожиданно) -- и делает их предшественниками Julia в интерактивном компьютинге (я, правда, предпочитаю говорить exploratory programming -- термин употребляется не менее часто). Действительно, из многих языков, которые я пробовал, Forth оставил у меня почему-то очень нежные воспоминания, хотя я и не так много времени им занимался. Рассказ Грейдона про важность multiple dispatch мне очень понравился: аналогичная проблема ведь вылезает в данных-из-базы-данных и их обработке, решается она вообще уходом из объект-ориентированной парадигмы в графовую ("семантические технологии"), но на тему этой аналогичности нужно ещё думать. В этой же точке -- разделение между языками моделирования (языками описания базы данных) и языками запросов (недоделанными языками программирования для запросов из базы, описанной языками моделирования). Мне кажется, что если в это место сделать какое-то интеллектуальное усилие и отстроиться мысленно от "объект-ориентированности" для данных и процедур (например, думать не о "процедурах-над-объектами" -- методах, а о "процедурах-над-паттернами" -- эээ... практиках;) , то можно много чего добиться в плане развития языков. Мы вот делаем SysMoLan как язык моделирования -- и там все эти вопросы немедленно поднимаются. В принципе, Rust тоже очень хороший язык, но мне почему-то он меньше нравится -- именно за счёт того, что он "чисто компилируемый", "машинный" а не для exploratory computing. Но вот если бы из него pattern matching как-то взять в Julia -- о, это было бы шикарно! Ибо не nubmer crunching единым жив человек ))) Но я понимаю, это все "Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича..." ))) Полного счастья с нынешними языками пока не предвидится, но с отнесением Julia к великим языкам (это Грейдон сказал прямо -- great language) я бы согласился.