Т.е. цитируя ваши слова "наш герой" "опытный разработчик уровня senior" занимался венчурной т.е. наукоемкой разработкой, не предполагающей гарантированного результата "в области, в которой у него был значительный опыт". Сразу вопрос: может это не с ним что то не так? Раз вы сами даете ему такую характеристику и он проработал у вас так долго...
В какой то момент компания решила продолжать разработку "другим составом"... Опять же, до этого он в соло задачу тянул, а на замену вы целый состав планируете нанимать?
При этом компания не захотела тратиться на официальную процедуру увольнения и потребовала у работника увольнения по собственному желанию... Я все правильно понял? Это незаконно... даже по нашему законодательству, а в других европейских странах оно еще жестче к работодателю... Понятно, почему конфликт возник... И это только ваши слова... А если к этому добавить точку зрения "нашего героя" и что для него это явно было неожиданностью...
Насколько я понял, с момента конфликта вы уже заплатили ему два оклада. Это не считая всех прочих расходов, включая юридические, время сотрудников(как минимум hr, упомянутые тех лиды, руководство), повышение уровня токсичности в компании, репутационные потери... Почему сразу нельзя было так сделать и оформить все по закону? Или предложить ему те же два оклада за увольнение по собственному...
И про аттестацию: вы ее провели уже? У вас, вообще, есть в компании люди способные оценить квалификацию такого сотрудника? Куда они смотрели 9 месяцев? Или руководство все устраивало?
Я использую julia как основной яп больше 2х лет и мне повезло писать рабочие проекты на ней... и это какой то странный набор недостатков... не считая прожорливости рантайма, большого объема собираемых бинарников и Android. Эти три вещи - прям по больному... И так, скажем, не несколько Гб - это большое преувеличение, это будет синтетический пример, но все же...
Что это за бенчмарки такие удивительные, в которых кода на python получается меньше, чем на julia... Почему fortran потребляет так много... Посмотрев несколько из них, джулия там, похоже, запускается над сырым кодом т.е. ее компилятор с выводом типов, мегаоптимизатор, все проверки, первый прогон с оптимизацией для выведенных типов - все засчитывается за время выполнения программы в т.ч. по потреблению памяти. Что то я сомневаюсь, что секция MAKE для других языков учитывается при подсчете потребления памяти и работы скомпилированной программы - иначе представьте что там было бы для крестов! И питону не нужно выводить никаких типов, ничего компилировать, генерировать оптимальный код для разных наборов типов... И даже при этом джулия дает удивительно хорошие результаты... Причем у нее ведь больше возможностей по ручному контролю за памятью, чем у python - мне приходилось пару раз переписывать код с python на julia т.к. он слишком много потреблял памяти и не умещался в память...
Очень странна секция про недостатки пакетной системы и непереносимость результатов - для какого языка и пакетной системы это не справедливо? для R? .ipynb очень непросто перенести без явной заморозки пакетов и культуры работы с зависимостями. Недавно при таком переносе у меня случились взаимоисключающие требования по версиям зависимостей - сижу и гадаю теперь, как это вообще работало ^^ А еще, julia, в отличие от python, автоматически генерирует в папочке проекта спасительный файл манифеста с версиями... А еще, там где навязывают культуру работы с зависимостями, это воспринимается как высокий порог вхождения в язык...
Докуменатция у джулии приличная по сравнению с большей частью документации, что я видел... И, надеюсь, она никогда не станет настолько чудовищно избыточной как в ваших примерах функций R - они же короче, чем документация к ним... Единственное, чего не хватает офф документации жулии - больше деталей о работе многопоточности и распределенности. Например, для реальных суперкомпьютеров и крупномасштабных распределенных вычислений использовали MPI.jl, a в офф документациии про него ни слова...
Julia была задумана как язык, совершенный во всех отношениях
Она задумана как совершенный энтерпрайзный язык... Что в каком то смысле противоположно совершенному ^^
можно подробней про грязный код? Пожалуй, все используемые мной питоновские библиотеки — грязные… Но, пока, проблем не было… даже очень все хорошо… Ждать, что может прилететь?
Коркретно по pandas, numpy, scipy я оценивал готовность pycall. Скажем, mean — «грязный» вызов из нативной части pandas, прекрасно работает:
не понмиаю, почему вы так сужаете область применения Julia? У меня она полностью вытеснила python в т.ч. в работе. Julia — это тот же python, тока:
без проблем с производительностью
без глобальной блокировки интерпретаторa
с опциональной типизацией с выводом типов
с, вообще говоря, зависимыми типами. Раньше в документации так и писали, но потом убрали из-за того, что в julia это не то же самое и не так круто как в idris, но когда люди читают «зависимые типы», то ждут именно чего то в стиле idris...
с отличными средствами интроспекции и оптимизации кода, когда вызываешь что то в стиле @code_llvm custom_code, смотришь генерируемый llvm-код, подправляешь, обычно, типы, снова смотишь… добиваясь идеального кода, чтобы julia все могла вывести статически, чтобы в рантайме не было лишних выделений памяти или диспатчеризации методов… кайф...
@pyimport math
# с этого момента math - полноценный julia-модуль
m = math
m.sin(m.pi/4)
Вообще говоря, можно подконнектиться к существующему python-процессу…
Самое главное, что julia разрывает порочный круг, когда прототипируешь на python, но потом это начинает работать слишком медленно, переписываешь на что то более быстрое и менее интерактивное… и в этом момент получается две версии одного кода, которые надо синхронизировать и каждое изменение в прототипе может потребовать переписывать ускоренную версию. А на juliа прототипируешь, уже получая большую производительность… Но в случае чего достаточно расставить типы в критических местах(массивы, циклы) и проблема с производительностью решена.
А поддержка синтаксиса в стиле matlab/octave/numpy — это, скорей, приятный бонус. Синтаксический сахарок. Да и, на самом деле, для питона поболее математических библиотек…
я читал, что ОС уже давно научились создавать своп-файл одним куском, так что никакой фрагментации и лишних seek'ов. Собственно приоритет на своп-раздеры в линуксе изначально был как раз потому что он этого не умел. Но с как минимум 3-ей версии ядра умеет из коробки.
По моему винда работала сначала со своп-файлом и в каком то году(кажется, в висте) она освоила своп-разделы. Помню, сильно удивился, когда она во время установки стала требовать своп-раздел. Хотя в последних версиях, говорят, опять вернулись к своп-файлам, но если есть своп-раздел, то винда отдает предпочтение ему…
Я не раз читал подобное историческое объяснение, что своп-раздел был, потому что ОС чего то не умела: не умела выходить из гибернации, не умела выделять монолитный кусок диска, чтобы эффективней с ним работать… Всегда с ремаркой, что сейчас ОС это умеет. Скажем линукс с 3-ей версии без проблем работает со своп-файлом: и выходит из гибернации, и производительность та же, судя по бенчмаркам которые я видел(хотя они были посредственные)… При этом когда ставишь современные версии линукса, они просят создавать неудобный своп-раздел… Создается впечатление, что это какое то ритуальное поведение. Я с десяток админов озадалич этим вопросом — никто не знает. Может ли быть такое, что огромная куча компов(сотни миллионов?) по всему миру работают с неудобным своп-разделом только из за этого?
Зачем для свопа выделяют отдельный дисковый раздел? Почему отказались от свопа в файл? Ведь изменить размер файла при необходимости очень просто, а переразбить диск — очень затруднительно.
Т.е. цитируя ваши слова "наш герой" "опытный разработчик уровня senior" занимался венчурной т.е. наукоемкой разработкой, не предполагающей гарантированного результата "в области, в которой у него был значительный опыт". Сразу вопрос: может это не с ним что то не так? Раз вы сами даете ему такую характеристику и он проработал у вас так долго...
В какой то момент компания решила продолжать разработку "другим составом"... Опять же, до этого он в соло задачу тянул, а на замену вы целый состав планируете нанимать?
При этом компания не захотела тратиться на официальную процедуру увольнения и потребовала у работника увольнения по собственному желанию... Я все правильно понял? Это незаконно... даже по нашему законодательству, а в других европейских странах оно еще жестче к работодателю... Понятно, почему конфликт возник... И это только ваши слова... А если к этому добавить точку зрения "нашего героя" и что для него это явно было неожиданностью...
Насколько я понял, с момента конфликта вы уже заплатили ему два оклада. Это не считая всех прочих расходов, включая юридические, время сотрудников(как минимум hr, упомянутые тех лиды, руководство), повышение уровня токсичности в компании, репутационные потери... Почему сразу нельзя было так сделать и оформить все по закону? Или предложить ему те же два оклада за увольнение по собственному...
И про аттестацию: вы ее провели уже? У вас, вообще, есть в компании люди способные оценить квалификацию такого сотрудника? Куда они смотрели 9 месяцев? Или руководство все устраивало?
а что это за версия питона? Ато у меня
AttributeError: 'NoSlots' object has no attribute 'dict'Я использую julia как основной яп больше 2х лет и мне повезло писать рабочие проекты на ней... и это какой то странный набор недостатков... не считая прожорливости рантайма, большого объема собираемых бинарников и Android. Эти три вещи - прям по больному... И так, скажем, не несколько Гб - это большое преувеличение, это будет синтетический пример, но все же...
Что это за бенчмарки такие удивительные, в которых кода на python получается меньше, чем на julia... Почему fortran потребляет так много... Посмотрев несколько из них, джулия там, похоже, запускается над сырым кодом т.е. ее компилятор с выводом типов, мегаоптимизатор, все проверки, первый прогон с оптимизацией для выведенных типов - все засчитывается за время выполнения программы в т.ч. по потреблению памяти. Что то я сомневаюсь, что секция MAKE для других языков учитывается при подсчете потребления памяти и работы скомпилированной программы - иначе представьте что там было бы для крестов! И питону не нужно выводить никаких типов, ничего компилировать, генерировать оптимальный код для разных наборов типов... И даже при этом джулия дает удивительно хорошие результаты... Причем у нее ведь больше возможностей по ручному контролю за памятью, чем у python - мне приходилось пару раз переписывать код с python на julia т.к. он слишком много потреблял памяти и не умещался в память...
Очень странна секция про недостатки пакетной системы и непереносимость результатов - для какого языка и пакетной системы это не справедливо? для R? .ipynb очень непросто перенести без явной заморозки пакетов и культуры работы с зависимостями. Недавно при таком переносе у меня случились взаимоисключающие требования по версиям зависимостей - сижу и гадаю теперь, как это вообще работало ^^ А еще, julia, в отличие от python, автоматически генерирует в папочке проекта спасительный файл манифеста с версиями... А еще, там где навязывают культуру работы с зависимостями, это воспринимается как высокий порог вхождения в язык...
Докуменатция у джулии приличная по сравнению с большей частью документации, что я видел... И, надеюсь, она никогда не станет настолько чудовищно избыточной как в ваших примерах функций R - они же короче, чем документация к ним... Единственное, чего не хватает офф документации жулии - больше деталей о работе многопоточности и распределенности. Например, для реальных суперкомпьютеров и крупномасштабных распределенных вычислений использовали MPI.jl, a в офф документациии про него ни слова...
Она задумана как совершенный энтерпрайзный язык... Что в каком то смысле противоположно совершенному ^^
Коркретно по pandas, numpy, scipy я оценивал готовность pycall. Скажем, mean — «грязный» вызов из нативной части pandas, прекрасно работает:
pytorch обязательно попробую на днях прикрутить…
При этом она позволяет органично использовать экосистему python с помощью github.com/JuliaPy/PyCall.jl
Вообще говоря, можно подконнектиться к существующему python-процессу…
Самое главное, что julia разрывает порочный круг, когда прототипируешь на python, но потом это начинает работать слишком медленно, переписываешь на что то более быстрое и менее интерактивное… и в этом момент получается две версии одного кода, которые надо синхронизировать и каждое изменение в прототипе может потребовать переписывать ускоренную версию. А на juliа прототипируешь, уже получая большую производительность… Но в случае чего достаточно расставить типы в критических местах(массивы, циклы) и проблема с производительностью решена.
А поддержка синтаксиса в стиле matlab/octave/numpy — это, скорей, приятный бонус. Синтаксический сахарок. Да и, на самом деле, для питона поболее математических библиотек…