Есть ли у Юрия Вишневского обоснованная критика Юлии?

МЕНЯ ПОПРОСИЛИ ответить на критику Юрия Вишневского в статье Почему я больше не рекомендую Юлю. Как большой поклонник Джулии и автор книги Джулия как второй язык я чувствую себя обязанным серьезно отнестись к критике Юлии.

Я думаю, что Юрий делает много обоснованных выводов, но я искренне считаю, что еще слишком рано делать выводы. Julia все еще очень молодой язык с незрелой экосистемой. В том, что в незрелых библиотеках и инструментах есть ошибки, нет ничего нового. Я занимался разработкой для iOS, когда Swift был относительно новым и постоянно сталкивался с непонятными проблемами. Я столкнулся с большим количеством дрянных библиотек Objective-C при создании мобильных приложений.

Тем не менее, все это меркнет по сравнению со всем мусором JavaScript, с которым я сталкивался, особенно в отношении мобильной разработки. Однако многие люди справляются с этим, потому что это набор инструментов, который им нравится и с которым они хотят работать.

Большинство библиотек Джулии все еще незрелые и имеют очень мало участников. Несправедливо сравнивать хорошо зарекомендовавшие себя библиотеки на других платформах с большим количеством разработчиков и многочисленными ресурсами в их распоряжении. Apache Arrow — отличный пример. Джулия получила полноту функций до эталонной платформы C++ с большой командой разработчиков, у которых было преимущество и гораздо больше ресурсов. Если я не ошибаюсь, у Джулии работал только один парень.

Если у вас есть один парень, обыгравший целую команду, я думаю, что Джулии следует немного послабить за то, что в популярных библиотеках немного больше ошибок. У Джулии просто нет ресурсов, которые есть у других языков на данный момент. И, честно говоря, я не уверен, что это обоснованное утверждение. Когда у вас есть библиотеки, которые могут делать намного больше, у вас будет больше угловых случаев, которые нужно охватить. Джулия предлагает чрезвычайно гибкие и универсальные библиотеки.

Почему у платформы ПК больше проблем, чем у платформы Mac? Потому что есть гораздо большие различия в оборудовании. Дополнительные параметры конфигурации. То же самое при сравнении iOS и Android. Когда я был мобильным разработчиком, я помню, как сложно было тестировать программное обеспечение для Android, потому что у нас были разные размеры экрана и форм-факторы.

Вопрос в том, чего вы можете достичь как разработчик и что вы можете контролировать? Должен сказать, что у меня гораздо больше положительного опыта, чем у Юрия Вишневского, но Юлию я тоже, наверное, использую совсем по-другому. Я больше разработчик программного обеспечения старой школы. Это означает, что я использую Джулию более консервативно, чем многие другие. Я избегаю слишком многих хитрых уловок. Я использую аннотации типов намного чаще, чем многие другие, и стараюсь свести зависимости от библиотек к минимуму.

Выбирая библиотеки для использования, я стараюсь избегать сложности. Я предпочитаю вещи, которые я могу легко понять и которые я могу исправить, если это необходимо. Люди чувствуют разные болевые точки. Для меня сложность в различных воплощениях всегда главный враг. Я в значительной степени верю в философию Unix «чем хуже, тем лучше». На мой взгляд, лучше быть немного неверным и простым, чем очень сложным и правильным.

Вот причина:

Если я смогу понять код, я смогу его исправить. Неправильный код может быть преобразован в правильный код. Корректность часто является временным свойством в мире, где программное обеспечение постоянно меняется. То, что работает сегодня, завтра может сломаться. Таким образом, легкость, с которой проблемы могут быть решены по мере их возникновения, важнее, чем правильность прямо в данном случае.

Это свойство - то, где я нахожу Джулию благосклонной. Я считаю, что устранять неполадки в Джулии намного проще, чем во многих других языках. Ключевой причиной этого является отличная среда REPL, которую предлагает Джулия, и то, насколько хорошо она соответствует сильным сторонам языка. В последнее время я запускаю отладчики в Go, и каждый раз, когда я работаю на традиционном статическом языке с отладчиком, выполняющим код по одной строке за раз, я вспоминаю, какой плохой заменой является отладчик для высококачественной среды REPL.

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

Суть в том, что я не утверждаю, что Юрий Вишневский не прав, просто я ценю разные вещи. Для меня очень важны простые и удобные инструменты. Джулия намного проще в использовании, чем многие современные языки, и я не думаю, что это говорит только мой внутренний фанат Джулии. Я помогал новичкам, которые разочаровались в Python и полюбили Джулию. Непрофессиональные разработчики, которые хотели делать простые вещи, но не могли справиться со сложностью экосистемы Python.

Конечно, экосистема Python очень зрелая, а это значит, что вы получаете пакеты с меньшим количеством ошибок. Но обратной стороной этого является гораздо более сложная среда для работы. Проблема Python 2.x против 3.x, Anaconda против PIP, pipenv, virtualenv, venv, JAX против PyPy против Numba, Cython и этот список можно продолжить. С Julia вы получаете управление пакетами, модули, зависимости и среды в одном стандартном пакете. С ним новичкам намного проще начать работать.

Проблемы, с которыми Джулия сталкивается при объединении пакетов, очень похожи на пакеты Python. Они не всегда хорошо работают вместе, и решить эти проблемы непросто.

Такого рода сложности существуют во многих языках, особенно в том, на котором я провел большую часть своей профессиональной жизни: C++. Существует бесконечный список инструментов сборки, таких как Scons, Ninja и CMake. Их сложность быстро достигает уровня, когда вам нужен эксперт для их обслуживания. Когда я работал разработчиком C++, я никогда не понимал систем сборки, с которыми имел дело. Настраивать сборки в Xcode не сложно, но это что-то вроде черного ящика, и вы можете быстро запутаться в параметрах компилятора, путях к библиотекам, параметрах компоновщика, каталогах ресурсов, подписи двоичных файлов и т. д.

Управление зависимостями в C++, как правило, довольно плохое. Когда две библиотеки зависят от разных версий третьей библиотеки, у вас быстро возникают проблемы. Тот факт, что стандартная библиотека C++ так долго была такой маленькой, а распространение библиотек настолько неудобным, привело к традиции действительно больших библиотек, таких как Qt, которые не всегда хорошо взаимодействуют с другими библиотеками. Работа с 3–5 различными несовместимыми классами строк кажется нормальным явлением в любом умеренно большом проекте.

В результате вы тратите много времени на написание связующего кода для соединения всех этих разных библиотек. Здесь возникает интересное соображение с Джулией. Гибкость в работе практически с любым типом для такого количества библиотек Джулии — вот что делает так сложно боевое тестирование библиотек Джулии и убедиться, что они работают во всех возможных комбинациях. Юрий Вишневский справедливо указывает на это как на проблему. Тем не менее, он никогда не распространяется о последствиях отсутствия такой гибкости. Анти-Julia — это C++, и я ничуть не убежден, что это подходящая альтернатива. Когда всем приходится писать связующий код, вы увеличиваете вероятность ошибок. Каждый проект будет в основном решать одну и ту же проблему снова и снова.

Для Джулии, напротив, когда проблема интеграции обнаруживается, она решается таким образом, что приносит пользу всем проектам. В конце концов, связующий код — это не то, что кто-то поставляет или распространяет как повторно используемый компонент. Джулия во многих отношениях делает то, что раньше не делалось в больших масштабах:

Джулия способствует созданию своего рода универсального связующего кода многократного использования. По своей природе это трудно сделать правильно, но как только это сгладится, преимущества огромны.

Клеевой код может быть массивным. Создатели игрового движка Godot экспериментировали с использованием Lua, JavaScript, Python и других языков в качестве языка сценариев. В конце концов они остановились на собственном языке под названием GDScript. Оказалось, что для полной реализации GDScript требуется меньше строк кода, чем для других языков сценариев.

Вот еще один пример: космическим ракетам нужно много программного обеспечения для управления ими. Система космического запуска НАСА (SLS) решила эту проблему, купив множество модулей и интегрировав их. SpaceX построил все с нуля. Опять же, связующий код, написанный НАСА, оказался больше, чем все управляющее программное обеспечение SpaceX.

Склеивающий код легко забыть, но он может быть огромным и может быть большим источником ошибок и проблем. Да, может быть хреново записывать ошибки в библиотеку Julia или добавлять исправления самостоятельно, но когда вы это делаете, вы также помогаете другим. Исправляя свой связующий код, вы на самом деле не помогаете никому, кроме себя. Повторного использования нет.

Критика Юрия Вишневского — это возможность для сообщества Юлии сосредоточиться на слабых сторонах и исправиться, но я не думаю, что это представляет собой неразрешимые проблемы. Значительное повышение производительности и радость от программирования, которыми многие из нас наслаждаются с Джулией, вполне реальны. Многие пришли к Джулии после того, как столкнулись с Python, Matlab, Fortran, R или другими языками, которые не могли обеспечить ни производительность, ни производительность, к которым они стремились. Лично меня как разработчика C++ чуть не выжрал, а Julia был одним из языков, которые снова сделали программирование приятным. Я думаю, что еще слишком рано отказываться от Джулии. У нас все еще есть небольшое сообщество, но у которого есть большой потенциал для роста.

В чем Джулия действительно нуждается, так это в привлечении крупных корпораций, таких как Google, Microsoft, Apple, Amazon или IBM. Я думаю, что более профессиональные разработчики с опытом работы в отрасли значительно улучшили бы качество. Джулия до сих пор полагалась почти исключительно на академическое и научное сообщество.

Мне жаль, что у меня действительно нет больше материала, чтобы добавить к этому вопросу. Объективное измерение качества библиотек Julia было бы сложной задачей. Каково качество проекта Julia, разработанного, скажем, за 5 человеко-лет, по сравнению с проектом Python или проектом C++ за такое же количество лет. Опыт Apache Arrow показывает, что часто мы сравниваем яблоко с апельсином. Мы рискуем сравнивать то, что выглядит как эквивалентные библиотеки по функциональности, не понимая, что 1/10 от количества ресурсов было потрачено на создание версии для Джулии. Можем ли мы тогда обвинить версию Джулии в том, что в ней, скажем, на 50% больше ошибок?

Я думаю, что в ответ на этот вопрос следует выбрать некоторые популярные библиотеки, сравнить возможности, ресурсы, распространенность и серьезность ошибок между Джулией и конкурирующими языками.