Специфика научного ПО
Содержание:
1. Несколько мифов о научном ПО;
2.Специфика научного ПО (Вы читаете данный раздел);
3. История программ молекулярного моделирования;
4. Причины успеха свободного ПО в науке.
Научное ПО имеет ряд особенностей, которые редко встречаются в современном коммерческом программировании:
> Используемые алгоритмы крайне сложны. Разобраться в них с ходу зачастую не могут даже доктора наук, не говоря уже о студентах или «простых» программистах.
> Низкая универсальность. По сути работает принцип «все, что можно сделать стандартными методами, уже давно сделано». Для решения новой научной задачи программу часто приходится модифицировать и адаптировать.
> Уникальная модель распространения. Научное ПО «рекламируется» практически только через реферируемые научные журналы. Причем статьи о самих программах обычно публикуются уже после того, как с помощью этих программ были получены и опубликованы какие-то интересные научные результаты. Без этого программу никто не будет воспринимать всерьез.
> «Остаточное» финансирование. Ученые крайне редко получают целенаправленное финансирование на развитие ПО. Чаще всего эта деятельность рассматривается всего лишь как производная от конкретной научной задачи. Только самые крупные и популярные программы удостаиваются отдельных грантов.
> Ученый - это не программист. Программы пишутся самими учеными, которые обычно не имеют образования в сфере ИТ. Во главу угла ставится выполнение нужной научной задачи, а культуре разработки (системе сборки, переносимости, стандартам оформления кода, документации) уделяется мало внимания.
> Тяжелое наследие прошлого. Кодовая база многих программ очень стара и восходит к 70-/80-м годам прошлого века. Эти слои кода практически невозможно поддерживать, т.к. они написаны на «мертвых» языках вроде Fortran-77 и совершенно не вписываются в современные стандарты программирования.
> Фрагментация разработки. Разные модули программ пишутся в основном аспирантами или сотрудниками, работающими по временным контрактам. Они работают над кодом в течение 2-3 лет, пока для них есть финансирование, а потом меняют место работы, бросая код в «полусыром» виде. Т.к. культура программирования не является приоритетом, через несколько лет возникает классическое «спагетти», разобраться в котором становится все труднее.
> Сложность отладки и тестирования. Сравнить результаты работы программ зачастую просто не с чем, т.к. это и есть пресловутый «передний край науки». Чтобы отладить программу, ее приходится скрупулезно проверять на множестве тестовых примеров с известными результатами, но и это не дает полной гарантии. В реальной задаче могут встретиться совершенно неожиданные комбинации данных, нарушающие сходимость численных алгоритмов, вызывающие неожиданные переполнения и возникновения печально знаменитых «corner cases». >
> Требования к пользователям. Часто непонятно, что является «глюком» программы, а что - спецификой исследуемого объекта. Для интерпретации полученного результата нужна хорошая научная квалификация пользователя. Кроме того, работает принцип «мусор на входе - мусор на выходе». Научное ПО не может отсечь «мусор» на входе, т.к. заранее неизвестно, для какого объекта его будут применять. Например, масса объекта в некоторых случаях может оказаться отрицательной (воздушный шарик с гелием в разгоняющейся машине) и «отсекать» отрицательную массу программа не имеет права. Понимать, что такое «мусор», должен сам пользователь.
1. Несколько мифов о научном ПО;
2.
3. История программ молекулярного моделирования;
4. Причины успеха свободного ПО в науке.
> Используемые алгоритмы крайне сложны. Разобраться в них с ходу зачастую не могут даже доктора наук, не говоря уже о студентах или «простых» программистах.
> Низкая универсальность. По сути работает принцип «все, что можно сделать стандартными методами, уже давно сделано». Для решения новой научной задачи программу часто приходится модифицировать и адаптировать.
> Уникальная модель распространения. Научное ПО «рекламируется» практически только через реферируемые научные журналы. Причем статьи о самих программах обычно публикуются уже после того, как с помощью этих программ были получены и опубликованы какие-то интересные научные результаты. Без этого программу никто не будет воспринимать всерьез.
> «Остаточное» финансирование. Ученые крайне редко получают целенаправленное финансирование на развитие ПО. Чаще всего эта деятельность рассматривается всего лишь как производная от конкретной научной задачи. Только самые крупные и популярные программы удостаиваются отдельных грантов.
> Ученый - это не программист. Программы пишутся самими учеными, которые обычно не имеют образования в сфере ИТ. Во главу угла ставится выполнение нужной научной задачи, а культуре разработки (системе сборки, переносимости, стандартам оформления кода, документации) уделяется мало внимания.
> Тяжелое наследие прошлого. Кодовая база многих программ очень стара и восходит к 70-/80-м годам прошлого века. Эти слои кода практически невозможно поддерживать, т.к. они написаны на «мертвых» языках вроде Fortran-77 и совершенно не вписываются в современные стандарты программирования.
> Фрагментация разработки. Разные модули программ пишутся в основном аспирантами или сотрудниками, работающими по временным контрактам. Они работают над кодом в течение 2-3 лет, пока для них есть финансирование, а потом меняют место работы, бросая код в «полусыром» виде. Т.к. культура программирования не является приоритетом, через несколько лет возникает классическое «спагетти», разобраться в котором становится все труднее.
> Сложность отладки и тестирования. Сравнить результаты работы программ зачастую просто не с чем, т.к. это и есть пресловутый «передний край науки». Чтобы отладить программу, ее приходится скрупулезно проверять на множестве тестовых примеров с известными результатами, но и это не дает полной гарантии. В реальной задаче могут встретиться совершенно неожиданные комбинации данных, нарушающие сходимость численных алгоритмов, вызывающие неожиданные переполнения и возникновения печально знаменитых «corner cases». >
> Требования к пользователям. Часто непонятно, что является «глюком» программы, а что - спецификой исследуемого объекта. Для интерпретации полученного результата нужна хорошая научная квалификация пользователя. Кроме того, работает принцип «мусор на входе - мусор на выходе». Научное ПО не может отсечь «мусор» на входе, т.к. заранее неизвестно, для какого объекта его будут применять. Например, масса объекта в некоторых случаях может оказаться отрицательной (воздушный шарик с гелием в разгоняющейся машине) и «отсекать» отрицательную массу программа не имеет права. Понимать, что такое «мусор», должен сам пользователь.
