Обсуждение

Кстати, недавно начался активный пиар нового MIT'овского языка для физического моделирования Simit, обещают десятикратное уменьшение программного кода. Что вы думаете об этом языке? Подобные обещания были когда-то про кучу разных языков, но всё как-то они не сбывались... http://simit-lang.org/language http://people.csail.mit.edu/fred/simit-techreport.pdf ЗЫ. Смотрел я исходники примеров программ на этом Симите, не вижу нигде оснований для десятикратного уменьшения кода. Разве что по сравнению с фортраном да сями...

Мы обсудили Simit в комментах тут: http://ailev.livejournal.com/1285862.html?thread=13984742#t13984742

С русскоязычной всегда сложнее. Во-первых, набор символов сильно другой, поэтому если не вводить только русское (а куда мы денемся от кучи библиотек как минимум), а набирать смешанно, то придётся часто переключаться, а это безумно неудобно. Одна из моих (но думаю, не только моих) личных проблем при наборе в ТеХе, например. Во-вторых, в кириллице много букв, и они на в распространённых раскладках налезают на `~<>[]{}, многие из которых часто нужны. От этого ещё печальнее. Испанцам будет явно проще, удачи им.

Нету у нее никакой скорости Си. Даже на числомолотилках (!) с типизацией (!) последняя версия Julia уступает, например, тупому JavaScriptу на списках.

Есть некоторые грабли по работе со скоростью, на которые в Julia наступает сначала каждый первый -- но потом всё обычно налаживается. Первая и главная -- это попытки замеров скорости при использовании глобальных переменных. Если в расчётах глобальные переменные не используются, то всё магическим образом ускоряется. Ну, и числомолотилки на JavaScript мне как-то трудно представить.

А, то есть это нормально, когда от скоупа зависит производительность кода? Там что, как в древнем питоне, обращение к переменным в скоупе делается через хеш-таблицу? Числомолотилки на Julia представить должно быть ещё труднее, потому что этот язык строго медленнее.

Вопрос про разгон с глобальными переменными стоит в issue к версии 1.0 (как ещё куча разных подобных вопросов). Как я понимаю, там до конца тормоза в этом месте не удаввят, но существенно поведение улучшат. По вопросу числомолотилок на Julia не соглашусь -- достаточно посмотреть, что и кто на нём пишет. Помним, что Julia не заявлялась как язык со скоростью машинного кода. Julia заявлялась, как язык, на котором писать код можно с удобством и скоростью написания кода на Питоне, а исполнять этот код -- со скоростью кода, написанного на Си. Новички, конечно, сначала нарываются на то, что не могут писать код как на Питоне (но потом вдруг оказывается, что скорость освоения языка оказывается примерно такой же), а потом что код получается существенно медленней Си, хотя и в разы быстрее Питона, но потом тоже оказывается, что они просто не заглядывали в раздел документации, где приводятся рекомендации по скорости. Главная же фича, так это что multiple dispatch там дешёвый в плане скорости. Ещё нужно учесть, что в Julia есть несколько разных планов добавления оптимизации, а часть этих планов даже выполнена (скажем, распараллеливатель на многоядерные интеловские процессоры, сделанный силами самой Intel). Конечно, по ходу разработки языка (и компилятора) какие-то оптимизации разваливаются, а какие-то новые появляются. Так что после выхода каждой версии ситуация со скоростью существенно меняется. Так, в версии 0.5 можно отключать контроль выхода за границы массива (что поможет существенно добавить в скорости для этих случаев), но в версии 1.0 планируется переписать и массивы, и строки -- так что опять можно будет ожидать сюрпризов, люди уже тихо радуются ускорению в 0.5 (и нужно учесть, что команда ведёт постоянное регрессионное тестирование в части скорости, так что пытается чинить случайно ломаемые оптимизации).

Глобальных переменных нет, проблем с прогревом нет. Тормозит. Для меня тоже было сюрпризом, что маркетинговое "скорость как у Си" оказалось "медленнее жаваскрипта".

Ну там первый же совет при вопросе про скорость -- глядеть в доки, где описываются оптимизационные приёмы, ибо "любой код будет быстрым" в Julia сейчас явно не работает с 0.4. Ну, и в 0.5 скоростные характеристики существенно изменились во многих местах (особенно в связи с массивами), а в закладываемом сейчас на стапели 0.6 предусмотрены ещё кое-какие трюки. Совсем уж чудес ведь не бывает, для выхода на хорошую скорость в целом по языку нужно некоторое время. Тот же джаваскрипт "из коробки" разгонялся год за годом, точно не в момент создания языка. Тут будет (собственно, уже происходит) всё то же самое, но сама стартовая точка уже довольно высока. Меня тут больше смущает отсутствие альтернативных реализаций -- какое-то соревнование подстегнуло бы жизнь, как в случае с джаваскриптом. Но это для современых языков проблематично и требует огромных ресурсов и времени (и должно быть хоть как-то понятно, зачем. Это в спорте не спрашивают, зачем нужно столько футбольных команд).

Как пишучий на русском скажу, AltGr спасает. Например "раскладка Чистова" http://1c.chistov.pro/2012/11/1.html С учтом того, что майкрософт с выходом рубля все равно превратили правый альт в "серый" минусов у нее не осталось.

VB6 вот тоже был довольно медленным языком, и когда надо было что-то быстро посчитать, люди писали процедуру на ассемблере, компилировали ее в машинный код, перегоняли в hex, вставляли как строку, декодировали в памяти программы и вызывали ее по указателю на строку, используя WinAPI CallWindowProc. Маркетинг: "пишете как на Python, скорость как на C", реальность: "пишете как на C, скорость ниже, чем у JS". Спрашивается, зачем такое нужно. Альтернативных реализаций не будет примерно по той же причине, по какой их компилятор оказался хуже студенческих компиляторов Pascal — безблагодатность команды разработчиков Julia.

Напомню, что JavaScript тоже не заявлялся как язык для числомолотилок и не используется для этих целей нигде, кроме как в сомнительной области браузерной криптографии. Это не мешает ему отставать от нативного кода меньше, чем Julia. Если бы задача преобразования более высокоуровневых конструкций в оптимальный набор низкоуровневых не была алгоритмически неразрешимой, она бы уже была заимплементирована в других ЯП. Написание эффективного кода на языках, которые заявляют, что на них это якобы возможно, но при этом отвергают наличие архитектуры ПК, обычно напоминает проталкивание фарша через мясорубку в обратном направлении в надежде получить кусок мяса, и Julia с её рекомендациями по оптимизации -- не исключение. Для написания эффективного кода необходимо знание архитектуры хотя бы на уровне С++, и я не вижу необходимости переходить с него на языки равно провоцирующие приступы идиосинкразии. Более того, С++ не кормит завтраками по поводу реализации оптимизаций в компиляторах, они уже существуют. Считать же, что они когда-либо появятся в Julia, излишне оптимистично в связи с отсутствием должного финансирования и интереса.

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

Я бы не недооценивал "должное финансирование" и интерес. Вот пример: https://youtu.be/Ti9qqAe_NF4 (и архитектура там существенно использована как Intel, так и самого языка). С пакетами там не так хорошо, это да. Хотелось бы экспоненциального роста, но уж какой есть, линейный: http://pkg.julialang.org/pulse.html (ну, и там значительная часть -- это всякие wrappers, так что никаких иллюзий на этот счёт. Но так все делают. Опять же модули Си и Фортрана доступны безо всяких wrappers, как родные). Ожидающиеся оптимизации компилятора в Julia перечислены для ближайших версий, и финансирование на выпуск этих версий есть. В этой сфере вычислений вообще много чего интересного происходит, она бесхозна. Например, Torch вообще живёт на Lua -- хотя Lua никогда для числомолотилок не был предназначен, но вот поди ж ты. Я знаю, что с трудом заползшие в эпицентр сишных систем оттуда уже не уползают. ))) Я и сам ведь программировал чуть-чуть на древнем Си (на СМ-4, в середине восьмидесятых!), но мне это не слишком нравилось. Споры о языках религиозны, каждому тут своё. Мне самому Julia нравится больше с эстетической стороны и общей направленностью, нежели качеством конкретной реализации или наличием развитой экосистемы.

Проблема не в Julia, проблема в маркетинге. Эффективность работы при переходе с community-инструментария на решения какой-то тусовки падает, затраты растут, создаваемый выход падает, финансирование урезается, за остатки начинается грызня с привлечением все более зубастых маркетологов. Этот автокаталитический процесс катастрофичен для науки.

Комьюнити -- это и есть тусовка. Кто-то в тусовке Кобола до сих пор, кто-то в тусовке Явы, кто-то в тусовке Питона, кто-то в тусовке Юлии. Тусовка любителей численных методов решила сделать Юлию, вот и делает. Есть прямые рекомендации, когда на Юлию переходить: если вы сами придумываете численные алгоритмы, то вам нужна Julia прямо сейчас, а если просто пользуетесь какими-то чужими библиотеками, то пользуйтесь уж чем придётся. Если сочетание -- то сочиняйте алгоритмы на Julia и подключайте чужие библиотеки (или наоборот, вызывайте Julia из других фреймворков, это тоже работает). И я бы не недооценивал чисто культурной реакции (которую я почему-то не видел в отзывах про другие языки): люди подчёркивают, что работать приятно, ссылаются на какие-то эстетические критерии и прочие абсолютно нетехнические характеристики. Даже странно такое читать по сравнению с обычными языковыми разговорами. Возможно потому, что тусовка там прежде всего не профессиональных computer scientists и software engineers, а именно тусовка любителей численных методов -- оптимизация, параллельные вычисления, количественная экономика и т.д..

Комьюнити это все тусовки сразу. В тех тусовках численных методов, с которыми соприкасался я (тензорные поезда и все такое), никакими жулиями не пахнет, только C++, только хардкор. По эстетическим критериям Julia слишком уж воняет 80-ми и матлабом (вполне допускаю, что она приятна тем, кто кроме матлаба ничего больше не видел), так что объективно остается только маркетинг. А вот Python 2.7 как раз по эстетическим критериям опережает 3, в котором добавили скобочек и явных плясок с итераторами и юникодом, но не решили актуальных проблем с параллельностью и быстродействием самого языка.

Ну, комьюнити всё-таки разные. И как раз от си люди и пытаются уйти во что-то более приятное для письма (от разработок на питоне и потом переписки на си, или прямой отладки алгоритмов на си). Что касается матлаба, то большие куски синтаксиса там действительно сознательно взяты из Матлаба. А лисповская часть так вообще по годам древней не бывает! Но вот многое другое там вполне интересное, тот же multiple dispatch (это ж главная фича! Именно её почему-то не замечают "внешние люди"), а ведь она много чего интересного и необычного в язык привносит). Вот, повторюсь: http://ailev.livejournal.com/1218155.html Про Питон я совершенно согласен: с параллельностью и быстродействием ничего не решили -- это всё равно, как остались в рамках второй версии. Кстати, в Julia 2.0 тоже пока не так много на сегодня предполагается изменений. Разве что record (именованный tuple) хотят добавить из типов.

Спасибо, погляжу на неё.