Комментарии 9
Даже достаточно базовые пакеты всё ещё не очень стабильны в плане воспроизводимости результата. При запуске своего же кода после обновления пакетов легко получить сильно отличающийся результат.
В таком случае уже недостаточно просто приложить фрагменты кода в конце статьи, нужно также обязательно фиксировать версии пакетов, в т.ч. базовых. А следующему исследователю при необходимости придётся их либо обновлять по одному, либо пользоваться старыми, если он не хочет потерять совместимости с первой версией. Похоже на генератор легаси.
Поскольку цель научной статьи в первую очередь - передать некоторую идею, и код обычно является только иллюстрацией какой-то отдельной мысли автора, то обычно это не является проблемой. Была бы возможность хоть как-то запустить этот код, чтобы в деталях понять авторскую мысль. Но если версии не указаны и код не работает - то сложность исправления может оказаться зашкаливающе высокой, и не факт, что результат после исправлений останется таким же, каким был изначально
Вообще, проблема воспроизводимости является общей для всех языков и при использовании кода в публикациях лучше всегда указывать используемые версии языка и библиотек. Просто у каких-то языков, например у Fortran, проблема воспроизводимости выражена очень слабо, а у Julia пока что довольно выражена
Статьи бывают не только такие. У меня были точные оценки на некоторые объекты и их свойства. Нерабочий/сложный в запуске код делает результаты невоспроизводимыми. Может быть я правильно написал алгоритм и корректно его обосновал, но допустил ошибку в программировании. Вряд ли её будут исправлять за меня другие.
Поэтому нужно не просто запустить, а быть уверенным, что запуск именно такой, каким его предполагали авторы. И в промышленных языках с этим обычно проще, там проблема воспроизводимости результатов(пакетов/образов) критична. C++, например, умеет в обратную совместимость на десятилетия назад (но с библиотеками может быть сложнее)
Ну так если версия языка и пакетов указаны, в чём проблема: собираем окружение с этими версиями, запускаем код, и получаем гарантировано тот же результат, что и у автора. Все вычисления и их результат будут те же. Никакие ошибки за автором исправлять не надо. В некотором смысле, Julia просто более явно проявляет проблему, которая всегда была при добавлении кода в научную работу: без дополнительной информации, как именно запустить этот код, чтобы получить тот же результат, что и у автора, мы не можем быть уверены, что получаем тот же результат, что и у автора. Эта проблема есть у всех языков. У Julia тоже всё отлично с обратной совместимостью, но нам ведь мало использовать чистую Julia, мы ведь, как правило, хотим задействовать ещё и некоторый набор пакетов. Проблемы в первую очередь возникают с пакетами. А если не забывать указывать в статье все версии - то и проблемы нет
Меня в Юле очень печалит, что она полностью непригодна для использования на машинах без доступа в интернет. Для того же дотнета достаточно сложить в какую-нибудь папку файлы .nupkg нужных пакетов и указать её как источник, и всё заработает. У Юли же скачать что-то с сайта juliapackages.com не представляется возможным. Мало того, некоторые пакеты при установке сами лезут в сеть и что-то докачивают (в основном бинарники).
Идея создать сборку на компе с сетью и перенести её на рабочий тоже провалилась, ведь часть пакетов при установке захардкоживает пути в свой код и на другой машине вместо работы валится куча невнятных ошибок (как вообще можно было до такого додуматься? 21 век на дворе!). Пара пакетов вообще ставит Conda и качает через неё что-то питоновое.
А ещё пакетов очень-очень много и они друг от друга зависят. Один из интересующих меня пакетов имеет 5 прямых зависимостей и почти сотню косвенных (81 обычный пакет + 14 бинарных пакетов). Причём среди этих зависимостей есть, например, LightXML и TimeZones, которые вообще непонятно зачем нужны в пакете для решения дифуров. Учитывая, что на компе без интернета всё это придётся собирать руками из исходников с гитхаба и добиться при этом совместимости всех версий очень сложно, периодически посещающее меня желание поменять Фортран на Юлю желанием так и остаётся.
Julia собирает все пакеты в локальную директорию ~/.julia. Если один раз пакет закачан, второй раз менеджер пакетов за ним не полезет. А вот если будет добавление нового пакета с новой зависимостью по тем, которые были установлены ранее, то да, потребует докачать. И будет хранить обе версии.
Артифакты и наборы данных закачиваются туда же в ~/.julia/artifacts и ~/.julia/datadeps/, но произойдёт это тогда, когда будет запущен код из пакетов. Собственно, если надо гарантировать что всё закачано, надо либо глобально для всех пакетов запустить встроенные тесты, либо запустить тесты по своей программе, чтобы закачать только то, что нужно.
По-хорошему, директория ~/.julia вполне переносима с машины на машину.
Касаемо juliapackages.com - для этого есть механизм реестров. Разворачивайте в своей сети свой собственный LocalPackageServer и делайте с ним что хотите - полную копию внешнего реестра или только то, что нужно. Официальный репозиторий с реестром - https://github.com/JuliaRegistries/General
По-хорошему, директория
~/.juliaвполне переносима с машины на машину.
Некоторые разработчики пакетов этого не понимают. В моей папке с пакетами нашлось 619 файлов, в которых встречается полный путь к этой папке. Существенная часть из них — что-то предкомпиленное, но есть и вполне себе конфигурационные файлы, и какие-то скрипты на баше, и даже код на Julia. Ещё в 18 файлах встречается имя пользователя, но там вроде всё некритичное для работы среды, всякие кэши и т.д. И уверенности, что этим привязка установки к конкретной машине ограничивается, у меня нет.
Разворачивайте в своей сети свой собственный LocalPackageServer и делайте с ним что хотите
Пока не встретится пакет, которому вот прям очень надо перед первым запуском залезть в интернет и что-то скачать. Вот вам кусочек кода из одного пакета, от которого зависит интересная мне решалка дифуров (сокращённый, но основную проблему я оставил):
function _installer_url()
#<пропущено около 30 строк>
if USE_MINIFORGE
res = "https://github.com/conda-forge/miniforge/releases/latest/download/Miniforge3-"
else
res = "https://repo.continuum.io/miniconda/Miniconda$(MINICONDA_VERSION)-latest-"
end
res *= conda_platform
res *= Sys.iswindows() ? ".exe" : ".sh"
return res
endА всего файлов, в которых встречается какой-то URL — 1308. И я очень надеюсь, что в основном эти адреса находятся в комментариях.
Я использую julia как основной яп больше 2х лет и мне повезло писать рабочие проекты на ней... и это какой то странный набор недостатков... не считая прожорливости рантайма, большого объема собираемых бинарников и Android. Эти три вещи - прям по больному... И так, скажем, не несколько Гб - это большое преувеличение, это будет синтетический пример, но все же...
Что это за бенчмарки такие удивительные, в которых кода на python получается меньше, чем на julia... Почему fortran потребляет так много... Посмотрев несколько из них, джулия там, похоже, запускается над сырым кодом т.е. ее компилятор с выводом типов, мегаоптимизатор, все проверки, первый прогон с оптимизацией для выведенных типов - все засчитывается за время выполнения программы в т.ч. по потреблению памяти. Что то я сомневаюсь, что секция MAKE для других языков учитывается при подсчете потребления памяти и работы скомпилированной программы - иначе представьте что там было бы для крестов! И питону не нужно выводить никаких типов, ничего компилировать, генерировать оптимальный код для разных наборов типов... И даже при этом джулия дает удивительно хорошие результаты... Причем у нее ведь больше возможностей по ручному контролю за памятью, чем у python - мне приходилось пару раз переписывать код с python на julia т.к. он слишком много потреблял памяти и не умещался в память...
Очень странна секция про недостатки пакетной системы и непереносимость результатов - для какого языка и пакетной системы это не справедливо? для R? .ipynb очень непросто перенести без явной заморозки пакетов и культуры работы с зависимостями. Недавно при таком переносе у меня случились взаимоисключающие требования по версиям зависимостей - сижу и гадаю теперь, как это вообще работало ^^ А еще, julia, в отличие от python, автоматически генерирует в папочке проекта спасительный файл манифеста с версиями... А еще, там где навязывают культуру работы с зависимостями, это воспринимается как высокий порог вхождения в язык...
Докуменатция у джулии приличная по сравнению с большей частью документации, что я видел... И, надеюсь, она никогда не станет настолько чудовищно избыточной как в ваших примерах функций R - они же короче, чем документация к ним... Единственное, чего не хватает офф документации жулии - больше деталей о работе многопоточности и распределенности. Например, для реальных суперкомпьютеров и крупномасштабных распределенных вычислений использовали MPI.jl, a в офф документациии про него ни слова...
Julia была задумана как язык, совершенный во всех отношениях
Она задумана как совершенный энтерпрайзный язык... Что в каком то смысле противоположно совершенному ^^
Документация по открытому наугад конструктору DataFrame заставляет меня грустить. Что за table в третьем снизу конструкторе? Почему во всех остальных конструкторах copycols имеет тип Bool, а конкретно в этом может быть ещё и nothing?
В расте, например, я могу просто покликать по типам аргументов, понять откуда можно взять нужные значения и чем этот метод отличается от другого похожего. Документация же джулии предлагает мне почитать пару абзацев описания перегрузок метода и их аргументов, зачастую оказывается проще сходить в исходники вооружившись LSP.
Десять предупреждений для желающих познакомиться поближе с Julia