Обсуждение

А сколько строк на Julia вы сами написали?

Какое замечательное, прекрасное, мощное, всепобеждающее средство создания бардака.

Хороший вопрос, учитывая что я ни разу не программист сейчас и вообще ни на каких языках не пишу кроме русского и иногда английского ))) Хотя когда-то я писал на языках программирования много, и на самых разных, но это сильно "когда-то", ещё в прошлом веке. Ах, я ещё иногда диаграммы на ArchiMate пишу, но это уж совсем про другое. Тем не менее, строк двести на Julia в Juno я недавно всё-таки написал. Не для какой-то потребности, а просто для удовольствия. И мне очень понравилось. Когда я пробовал писать на Питоне, мне это не очень нравилось, по совокупности причин. Мы ведь выпустили основанный на питоне dot15926, и там я иногда пользовался питон-консолью, да и сейчас в простой код на Питоне регулярно приходится залезать, ибо мой отрок на нём задачки решает -- но это никогда не было "с удовольствием от языка". А вот на Julia с внутренними ощущениями от языка всё было ОК. Ну, и нужно добавить, что назад в программисты я уже вряд ли подамся. Так что нельзя ожидать, что через пару месяцев я отрапортую о паре тысяч своих собственных строк на Julia. Хотя зарекаться не буду, жизнь иногда круче любых фантазий оказывается )))

"автомагически" - знакомое выражение :) как раз позавчера его встретил в лекции Pascal Vincent'а http://videolectures.net/deeplearning2015_vincent_machine_learning/

А сравните пожалуйста Julia с Ruby. Что-нибудь есть новое с теоретической точки зрения? Кроме того, его нет на http://benchmarksgame.alioth.debian.org -- как можно тогда говорить о скорости Julia? Ещё есть много других новых и не очень новых языков: Nim, D, Scala, новый стандарт C. Почему именно Julia должен кто-либо использовать, кроме теоретиков? Вот попользовался я им для adagram.jl -- и всё точь в точь как с другими языками: глючит и не сильно быстро работает (поэтому библиотека использует расширение, написанное на С).

В Julia скорость работы почему-то самое ожидаемое свойство. Но там есть хитрость: быстро работать у Julia в нынешних версиях свойство "потенциальное", она быстро работает только в умелых руках. У новичков это обычно втрое-вчетверо быстрее Питона, только и всего. В следующих версиях ситуация будет улучшаться, но это не так быстро. Те же, кто существенную часть работы делает на Julia как раз упирают на то, что скорость там не самое главное, а сам язык приятный. Теоретического в языке немного, скорее уж более-менее удачная реализация давно известного. Удачность в том, что в Julia удалось соединить ранее плохо соединяемое (типа опциональной типизации с выводом и multiple dispatch. Впрочем, и в свежий Питон опциональную типизацию вставили, так что Julia тут "всего лишь" в мейнстриме). Ну, и "теоретики, использующие Julia" -- это прямо против целей Julia. Авторы писали некоторое время назад, что пусть с проблемами computer science борются другие команды, а они будут бороться с проблемами практического программирования (например, проблемами плохо умещающихся в оперативной памяти матриц вместо проблем иммутабельности данных). И, конечно, Julia никто не "должен" использовать, вы странно выразились. Julia будут хотеть использовать. В версии 0.4 только-только сделали прекомпиляцию библиотек (там сейчас RC3, официально версия ещё не вышла), а в версии 0.5 существенно переделают реализацию массивов. На подходе traits. Всё потихоньку развивается по направлении к заявленным свойствам, как и в других языках. А заявленные свойства разные. Вот поглядим, как жизнь повернётся. Если я прав, то инженеры вполне будут писать на Julia, а на D, Scala и новом стандарте Си будут писать не инженеры, а всякие другие люди -- математики, профессиональные программисты и т.д.

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

Я ж и говорю, что для инженеров это должно быть терпимо. Близость синтаксиса языка к линии фортрана-матлаба осознанный шаг был, дизайн-цель.

Ясно. До 0.6 лучше на него и не смотреть, пусть всё устаканится сначала. Т.е. вы не желаете его сравнивать с Ruby и с Nim -- для вас новый перспективный язык только один. >Удачность в том, что в Julia удалось соединить ранее плохо соединяемое (типа опциональной типизации с выводом и multiple dispatch. Я вот не пойму -- почему вы считаете, что есть какая-то важность именно в этих фичах? Языки применяются для двух основных целей: 1) написание маленьких программ 2) написание больших программ В области 1 Julia от остальных неотличим, в области 2 ещё непонятно, будут ли эти фичи ему мешать, и что за серьёзные проблемы будут с языком. Как минимум одна проблема в (2) есть -- что до 0.6 нельзя на массивы опираться, иначе всё переписывать придётся.

Julia - это язык для научных/технических расчетов типа Matlab/Octave Для этой сферы он весьма интересный и конкурентный (см к примеру http://economics.sas.upenn.edu/~jesusfv/comparison_languages.pdf), а с Ruby его сравнивать наверное незачем :) Небольшие бенчмарки есть тут http://julialang.org/ Matlab/Octave по мнению некоторых товарищей (например Andrew Ng) есть лучший язык для машин лёрнинга. Ибо умножение матриц и решение систем уравнений выполняется крайне компактной записью: A*B, A\B, A/B. Плюс понятное дело куча функций/пакетов для научных расчетов и графики. Вот в R умножать матрицы надо так A:*:B а решать уравнения A:*:solve(B). Хотя для статистики, понятное дело, что R круче ибо там есть куча пакетов. Сейчас еще Python продвигается для научных расчетов - ну и это тоже прикольно, ибо это general purpose язык с соответствующей инфракструктурой, к которому есть хорошие научные библиотеки. У Matlab/Octave есть "недостаток", что этот язык не ориентированы никак на проф программистов, имеется в виду, что сложный модульный код писать там не очень удобно. Т.е. развитие и сопровождение больших программ несколько затруднено в сравнению с тем что ожидал бы юзер Ruby/Python/Java/Scala и т.д. Julia сохраняет почти полностью синтаксис Matlab/Octave ну и добавляет скорости а также модульности. В этом смысле очень интересный язык. Но вряд ли он интересен пользователям Ruby :)

Хуже того, сейчас в Julia ещё и дебаггера толком нет! Несмотря на это, на нём уже довольно много пишут. И необходимость переделки кода с массивами не останавливает. Аргумент про "вот устаканится, и тогда перейду", тем не менее, самый распространённый. Очень много людей ждут магического номера "1.0" и пока просто делают на нём любительские проекты, но не продакшн. С Rubi я и сравнивать не хочу, это правда. Эти языки про разное. C Nim и Morfa формальное сравнение вполне возможно, но выглядит Julia более социальным проектом, нежели проектом какой-то узкой группы. Им как-то удалось организовать наработку собственных библиотек, чего не случилось с Nim и Morfa. Это косвенное подтверждение, что с библиотеками и впрямь в Julia чуток получше, чем в других языках -- а для меня этот аспект важнейший, об этом и пост.

>Языки <...> 1) написание маленьких программ 2) написание больших программ - Языки 1) написания маленьких проблем 2) написания больших проблем.

Такой multiple dispatch и в питонах можно. Вот только его мало. Потому что с _каждой_ реализацией рантайм-диспатча по "is something" в результате обнаруживается необходимость более общего диспатча по "has something", а затем и произвольным паттернам предметной области. Причём, сами паттерны обобщаются, а вот правила specificity для них (см. http://www.w3.org/TR/css3-selectors/#specificity ) и особенности создаваемых индексов зависят от предметки. То есть, требуются не хаки в языке, а развитый функционал для написания библиотек паттернов.

Вот что мне подозрительно, так это базисность механизма паттернов -- и кажинный раз облом в её реализации, крутость кривых обучения. С одной стороны, паттерны -- это то самое "вначале было Слово", это ход на регулярность структуры чего угодно, это ход на компактификацию знаний. С другой стороны -- популярным имеет шанс стать всё что угодно, кроме самих паттернов в их наиболее всеобъемлющем виде. В Julia стандартный способ введения новой функциональности -- это макро. Вот, например, про тот же pattern matching есть уже такое: https://matchjl.readthedocs.org/en/latest/

К сожалению, этого тоже недостаточно. Макросы уровня AST способны подменить ядро, но не дополнить его. Последствия этого - необходимость дублирования части функционала хост-языка в своём EDSL и его слабая сочетаемость с EDSL других авторов. Решается эта проблема реализацией самого ядра на смысловых макросах, работающих на уровне системы наследуемых/синтезируемых атрибутов и системы идентификации. Что, однако, само по себе задача сложная и длительная. С паттернами и pattern matching тоже всё хитро. Каждый язык удовлетворяет только своему маленькому срезу требований в этой области. Так что и "компактификация" не всегда компактифицирует, а может и увести куда-то в алхимические дебри. Что, опять же, неизбежно при отсутствии дополняемого ядра.

Ну вот нет в жизни счастья. Выводимые типы в Julia сами по себе дались нелегко (там ведь была ещё цель эффективной реализации), а если в получившееся месиво ядра добавить ещё и pattern matching общего вида, сохраняя при этом и multiple dispatch с эффективной реализацией -- ничего хорошего не будет. В Julia последовательно убирали все фичи, которые требуют (или для которых быстро не смогли придумать) задумчивости. Это была приоритетная дизайн-цель. Они честно пишут, что решают проблемы вычислительной математики в первую голову, а проблемы computer science оставляют решать другим командам. Тем не менее, я удивляюсь уже тому, что им таки удалось сделать в области решения "задач computer science" при текущей постановке вопроса. Там довольно интересные обсуждения для того, что ожидается в ближайшее время (оно всё там не слишком революционное, но из видео хорошо понятно, насколько сложно сделать просто нормальный язык): https://youtu.be/xUP3cSKb8sI Собственно, на базе Julia можно было бы пробовать вернуться к проблематике SysMoLan -- как только удастся понять, как это можно будет связать с ontology learning.

Видео иллюстрирует проблемы быстрохак-подхода. Ребята только сейчас дошли до такой базовой вещи как замыкания и проявили абсолютное непонимание собственного lexical scope. А ведь ядро должно менеджить lexical scope (и остальные правила видимости/лифтинга), с учётом таких вещей как замыкания и анонимные классы, иначе вместо компактных правил вылезают неконсистентные хаки в многокода. И у меня сложилось впечатление, что понимания здесь не будет, хаки просто войдут в стандарт. Как и переразвитый (и этим бесполезный) алгоритм вывода specificity.

Я боюсь, что понимание там в наличии, а вот способов реализации (приемлемых с точки зрения достижения их дизайн целей -- быстрый и не заумный язык) там не придумано. Отсюда и делаются проектные шаги. Там в форумах девелоперов Julia непрерывно идёт обсуждение всех шевелящихся сегодня языков -- что из них брать, что успешно, к чему потом приводит в реализации, к чему в "социальном окружении". Всё бодренько.

Это намного более популярное слово, чем вы думаете.

Ага. Я вот так подумал, что при сходной базе (а в их предметке ещё Фортран помнят) тоже старался бы найти удобные локальные решения. Для big picture приходится набивать шишки очень много где, и это не особо приятный процесс. Так что, все хорошие, просто о разном.