Есть еще один аспект, про который часто забывают. Отладка на JVM на порядки проще и удобнее, чем на JS или тем более в нативе. Какую-то сложную common-only логику удобно отлаживать на JVM, а в остальных местах просто использовать. С оговоркой о платформных типах, которая была выше.
Нет, это к сожалению не "детские" проблемы, а как раз проблемы, которые возникают при масштабировании. Это не отменяет того, что джулия весьма хороша в области прототипирования и изолированых научных задач. Но для больших многоцелевых фреймворков она вряд ли будет пригодна.
Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
Как я и писал, есть разные задачи. Есть код для суперкомпьютеров, который пишется под конкретную очень узкую задачу и практически не меняется. Но это очень малая часть всего многообразия научного программирования. А в массе своей, затраты на поддержку "творческого" кода огромны.
Собственно вы полностью повторяете тезис о том, что просто взять программистов и посадить их делать "физику" нельзя. Я об этом и говорил. Но в то же время, физики сами не справляются с тем, чтобы создавать инфраструктуру для решения своих больших задач.
Ну вот подход к программе как к системе уравнений - это и есть типичная ошибка физиков. Современная программа, особенно работающая с данными - это гораздо больше, чем просто алгоритм. Основная часть - это обвязка и инфраструктура. Точно так же как и в коммерческой разработке.
Суть в том, что на текущем этапе уже нужны именно продукты. С супер-большими объемами данных и сложными структурами в ноутбучиках не поработаешь. И вы правы в том, что ученые этого не понимают.
А программисты хотят четкое ТЗ, которого в науке действительно быть не может.
Я выше ответил на аналогичный вопрос. Я сам занимаюсь в том числе разработкой систем сбора данных (см. тут: https://github.com/mipt-npm/controls.kt) и совершенно не фанат LabView, потому что он слишком ограничен и громоздок. Но при этом совершенно очевидно, что если речь идет не о программистах - это первый выбор.
Если интересно, то прямая работа с железом была у нас на курсе "Продвинутое программирование на языке Python" Михаила Зеленого (там она прямо на зачет была с реальным железом). Возможно что-то будет на курсе "Введение в научное программирование на Kotlin" этой весной. Но в обоих случаях идет речь о программистах. А LabView - это система, созданная для людей, которые не хотят заморачиваться с языками программирования.
Есть еще один аспект, про который часто забывают. Отладка на 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. Это не плохо само по себе, но проблема в том, что после публикации этот код можно выкинуть.
Можете привести пример большого публичного проекта на Fortran 2018?
Сейчас реально появились группы, которые занимаются этими "мостами" и мне кажется, что в будущем это будет востребованная ниша.
Суть в том, что на текущем этапе уже нужны именно продукты. С супер-большими объемами данных и сложными структурами в ноутбучиках не поработаешь. И вы правы в том, что ученые этого не понимают.
А программисты хотят четкое ТЗ, которого в науке действительно быть не может.
Я выше ответил на аналогичный вопрос. Я сам занимаюсь в том числе разработкой систем сбора данных (см. тут: https://github.com/mipt-npm/controls.kt) и совершенно не фанат LabView, потому что он слишком ограничен и громоздок. Но при этом совершенно очевидно, что если речь идет не о программистах - это первый выбор.
Если интересно, то прямая работа с железом была у нас на курсе "Продвинутое программирование на языке Python" Михаила Зеленого (там она прямо на зачет была с реальным железом). Возможно что-то будет на курсе "Введение в научное программирование на Kotlin" этой весной. Но в обоих случаях идет речь о программистах. А LabView - это система, созданная для людей, которые не хотят заморачиваться с языками программирования.