То, что вы описываете - довольно типичная ситуация в ПО для науки. Ну и тут два пути, либо тянуть ту же историю, которая есть сейчас, при этом, разумеется, у вас есть "конкуренты" и если ваша область востребована, они будут вас очень быстро догонять (для поточной обработки в памяти существует уже довольно много инструментов, и главным блокером для появления новых является, как это ни удивительно пакет Pandas). Или вы понимаете, что вам нужно развитие, и тогда вам придется заняться поэтапной модернизацией проекта, которая требует довольно много усилий.
Ну давайте начнем со слона в комнате, ваш пакет написан на Fortran. Живых людей вне метеорологии, кто писал бы на Fortran уже осталось очень мало. Это означает, что без дополнительных усилий будет довольно сложно привлечь комьюнити. Какие дополнительные усилия можно предпринять? Сделать поставку ядра приложения таким образом, чтобы другие люди могли ей пользоваться. Например сделать обертку на Python. В Python экосистеме это довольно распространенная практика, весь ScipPy так сделан. Сразу предупреждаю, что это не просто если вы до этого никогда этим не занимались. Надо разобраться с тем, как работают более или менее стабильные сборщики, научиться более или менее автоматически делать релизы и сделать минимальные тесты. Не просто, но и не фантастически сложно. Мотивированный студент за полгода должен разобраться.
Дальше вопрос о том, зачем и имеет ли смысл. Тут надо понять, востребован ли ваш пакет за пределами вашей задачи. Для этого лучше всего поискать профессиональные сообщества в вашей теме и закинуть туда вашу идею. У нас есть свое сообщество, и мы иногда занимаемся геоданными, но боюсь не настолько углубленно, чтобы был нужен отдельный пакет для анализа. Если сообщества нет, то можно его создавать. Это тоже не так уж просто (и именно этому могут существенно помочь open source хабы в вузах), но как минимум надо начать с того, чтобы опубликовать код в удобном виде. Можно на Github, возможно у вашего института или вузов, с которыми вы работаете есть какие-то свои хранилища. При этом, как вам уже писали, надо позаботиться о том, чтобы ваш код было удобно и приятно читать.
Теперь о шансах. Шансы, что кто-то со стороны быстро придет и начнет что-то добавлять в ваш сложный код на мертвом по сути языке довольно низкие. При этом если возникнут пользователи, то так или иначе качество кода будет улучшаться. Хотя бы потому, что люди будут приходить и задавать вопросы, по которым будут видны недостатки существующего кода. Может быть и критика, но критика означает в том числе интерес. Даже если сторонних контрибьютеров не будет, будут ваши собственные студенты, для которых публичный вклад в проект будет хорошим опытом и хорошей добавкой в портфолио.
Более того, Столмановское "свободы" зачастую вредны, а не полезны. Потому что не дают построить нормальную систему монетизации. Свободное ПО должно быть выгодно всем участникам процесса и только тогда будет развиваться.
Спасибо за статью. Интересно, что покажет голосование. Пока 100% за нехватку понимания. И это действительно главная проблема. Не только в смысле "зачем делать опенсорс", но и как он работает и какие у него могут быть бизнес-модели (многие все еще воспринимают его как чисто работу "за идею").
Есть еще один аспект, про который часто забывают. Отладка на JVM на порядки проще и удобнее, чем на JS или тем более в нативе. Какую-то сложную common-only логику удобно отлаживать на JVM, а в остальных местах просто использовать. С оговоркой о платформных типах, которая была выше.
Нет, это к сожалению не "детские" проблемы, а как раз проблемы, которые возникают при масштабировании. Это не отменяет того, что джулия весьма хороша в области прототипирования и изолированых научных задач. Но для больших многоцелевых фреймворков она вряд ли будет пригодна.
Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
Как я и писал, есть разные задачи. Есть код для суперкомпьютеров, который пишется под конкретную очень узкую задачу и практически не меняется. Но это очень малая часть всего многообразия научного программирования. А в массе своей, затраты на поддержку "творческого" кода огромны.
Собственно вы полностью повторяете тезис о том, что просто взять программистов и посадить их делать "физику" нельзя. Я об этом и говорил. Но в то же время, физики сами не справляются с тем, чтобы создавать инфраструктуру для решения своих больших задач.
Ну вот подход к программе как к системе уравнений - это и есть типичная ошибка физиков. Современная программа, особенно работающая с данными - это гораздо больше, чем просто алгоритм. Основная часть - это обвязка и инфраструктура. Точно так же как и в коммерческой разработке.
То, что вы описываете - довольно типичная ситуация в ПО для науки. Ну и тут два пути, либо тянуть ту же историю, которая есть сейчас, при этом, разумеется, у вас есть "конкуренты" и если ваша область востребована, они будут вас очень быстро догонять (для поточной обработки в памяти существует уже довольно много инструментов, и главным блокером для появления новых является, как это ни удивительно пакет Pandas). Или вы понимаете, что вам нужно развитие, и тогда вам придется заняться поэтапной модернизацией проекта, которая требует довольно много усилий.
Кстати, куча свободных компиляторов фортрана. Кто мешает протестировать на любом из них?
Ну давайте начнем со слона в комнате, ваш пакет написан на Fortran. Живых людей вне метеорологии, кто писал бы на Fortran уже осталось очень мало. Это означает, что без дополнительных усилий будет довольно сложно привлечь комьюнити. Какие дополнительные усилия можно предпринять? Сделать поставку ядра приложения таким образом, чтобы другие люди могли ей пользоваться. Например сделать обертку на Python. В Python экосистеме это довольно распространенная практика, весь ScipPy так сделан. Сразу предупреждаю, что это не просто если вы до этого никогда этим не занимались. Надо разобраться с тем, как работают более или менее стабильные сборщики, научиться более или менее автоматически делать релизы и сделать минимальные тесты. Не просто, но и не фантастически сложно. Мотивированный студент за полгода должен разобраться.
Дальше вопрос о том, зачем и имеет ли смысл. Тут надо понять, востребован ли ваш пакет за пределами вашей задачи. Для этого лучше всего поискать профессиональные сообщества в вашей теме и закинуть туда вашу идею. У нас есть свое сообщество, и мы иногда занимаемся геоданными, но боюсь не настолько углубленно, чтобы был нужен отдельный пакет для анализа. Если сообщества нет, то можно его создавать. Это тоже не так уж просто (и именно этому могут существенно помочь open source хабы в вузах), но как минимум надо начать с того, чтобы опубликовать код в удобном виде. Можно на Github, возможно у вашего института или вузов, с которыми вы работаете есть какие-то свои хранилища. При этом, как вам уже писали, надо позаботиться о том, чтобы ваш код было удобно и приятно читать.
Теперь о шансах. Шансы, что кто-то со стороны быстро придет и начнет что-то добавлять в ваш сложный код на мертвом по сути языке довольно низкие. При этом если возникнут пользователи, то так или иначе качество кода будет улучшаться. Хотя бы потому, что люди будут приходить и задавать вопросы, по которым будут видны недостатки существующего кода. Может быть и критика, но критика означает в том числе интерес. Даже если сторонних контрибьютеров не будет, будут ваши собственные студенты, для которых публичный вклад в проект будет хорошим опытом и хорошей добавкой в портфолио.
Более того, Столмановское "свободы" зачастую вредны, а не полезны. Потому что не дают построить нормальную систему монетизации. Свободное ПО должно быть выгодно всем участникам процесса и только тогда будет развиваться.
Спасибо за статью. Интересно, что покажет голосование. Пока 100% за нехватку понимания. И это действительно главная проблема. Не только в смысле "зачем делать опенсорс", но и как он работает и какие у него могут быть бизнес-модели (многие все еще воспринимают его как чисто работу "за идею").
Есть еще один аспект, про который часто забывают. Отладка на JVM на порядки проще и удобнее, чем на JS или тем более в нативе. Какую-то сложную common-only логику удобно отлаживать на JVM, а в остальных местах просто использовать. С оговоркой о платформных типах, которая была выше.
Нет, это к сожалению не "детские" проблемы, а как раз проблемы, которые возникают при масштабировании. Это не отменяет того, что джулия весьма хороша в области прототипирования и изолированых научных задач. Но для больших многоцелевых фреймворков она вряд ли будет пригодна.
Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
Именно. Собственно время уже частично упущено. Потому что многие вещи проще заново написать, чем починить. Но лучше поздно, чем никогда.
Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
Забавно получать такие вопросы от интернет-анонимов. У меня вся информация в профиле. Там и список публикации не сложно найти.
Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
Julia на этом даже всю идеологию строит: https://juliadatascience.io/julia_accomplish#sec:two_language
Как я и писал, есть разные задачи. Есть код для суперкомпьютеров, который пишется под конкретную очень узкую задачу и практически не меняется. Но это очень малая часть всего многообразия научного программирования. А в массе своей, затраты на поддержку "творческого" кода огромны.
Собственно вы полностью повторяете тезис о том, что просто взять программистов и посадить их делать "физику" нельзя. Я об этом и говорил. Но в то же время, физики сами не справляются с тем, чтобы создавать инфраструктуру для решения своих больших задач.
Ну вот подход к программе как к системе уравнений - это и есть типичная ошибка физиков. Современная программа, особенно работающая с данными - это гораздо больше, чем просто алгоритм. Основная часть - это обвязка и инфраструктура. Точно так же как и в коммерческой разработке.
Поэтому если дать людям выбор, они будут писать на Python. Это не плохо само по себе, но проблема в том, что после публикации этот код можно выкинуть.