Комментарии 48
Поэтому куда проще применить машинное обучение, для которого вообще ничего понимать не надо
Видимо это и есть основная причина, почему программисты не понимают физиков. Думать приходиться обеим сторонам, а это не безболезненно.
Программист, обычно, как и всякий инженер (кодеры с учёными не работают — учёные и сами часто неплохие кодеры) пытается сделать какой-никакой обобщённый продукт, а учёному продукт не нужен. Ему нужна гаражная поделка под данное конкретное исследование/грант. И далее чем на исследование вперёд учёный чаще всего свою работу не планирует и не хочет.
Поэтому тут нужен особый подход, как с Вольфрамом и прочими" Математиками" — учёный от программирования должен проводить мета-исследования по современной науке, выявлять проблемы и предлагать алгоритмы и организовывать их реализацию в ПО с помощью «обычных» программистов. Ну а учёный из других областей должен уметь всем этим пользоваться (и немного кодить на С и Excel) — это необходимая часть современной научной культуры.
А так напрямую — да мало чего хорошего и осмысленного получится.
Примерно как с математикой вообще (программирование — это прикладная математика). Какому-нибудь социологу или лингвисту тоже бывает сложно взаимодействовать даже с банальным аналитиком-статистиком, не говоря уже у чём-нибудь позабористее.
Я сам физик (ФФ, волна + E.Polytechnique + ULaval) и не-программист после 10 лет в науке ушёл в смежную область (вместо должности профессора выбрал по сути коммерческое R&D). Добавлю что у академии и бизнеса очень разный подход. Науку чаще всего по факту делают PhD и постдоки. Группы чаще небольшие (20 человек это большая группа), проекты или их аспекты чаще новые для каждого. PhD делают 3 года, постдок как правило на годовых контрактах. Задача и того и другого - публикации (я в эту игру профессионально играл, устриц ел). Для бизнеса и три года и один невероятно долго, а защищаться по зоопарку мелких задач сложно. В итоге бизнес входит по-принципу «что не жалко» и что не очень ждём. А исполнитель может писать любой код на любом языке, делать абсолютно все что угодно если это даёт прототип и публикуемый результат (в конце статьи пишется параграф как продолжение этой работы принесёт мировое счастье). Поддерживать код лично он скорее всего не будет (для карьеры плохо сидеть на одном месте ). Опять же физика никто специально не учил программировать, чему сам нахватался то и хорошо.
В итоге я сейчас, по факту, занимаюсь подстройкой мостов между наукой и бизнесом - передачей технологии от одних к другим (и больше ничего не публикую :) ). Пусть не самых последних технологий, но с учётом интересов того кто даёт деньги и в разумные сроки за разумные деньги.
Чем фортран не устраивает ? Есть стандарт 2018, не обязательно писать на 77. Просто нужно определиться с кругом задач. Если вы хотите создать очередной облачный сервис JetBrains от которого можно будет отключать пользователей из России, тогда достаточно взять [подставь сюда любой язык для которого есть JetBrains IDE].
Во первых, как лично мне показалось, если автором и был кинут камень в огород Фортрана, то исключительно на территорию 77-го.
Во вторых, с использованием 2018-го стандарта есть проблема, которую автор также подметил. Работники науки старшей школы просто не понимают, зачем все это нужно: ООП, классы, интерфейсы, области видимости и т.д., если они всю жизнь обходились с помощью глобальных массивов (или даже массивА, разные части которого хранят разную информацию).
В третьих, как по мне, если и ставить цель избавиться от легаси в науки (а заодно и расширить кругозор некоторых ее работников) то 2018-ый Фортран является плохим вариантом. Ибо будем честны, язык уже фактически мертв (да, есть stdlib, fpm и ещё несколько проектов, но этого мало), даже несмотря на рейтинги Tiobe. Julia является прекрасной альтернативой: схожий синтаксис, скорость, наличие достаточного количества библиотек для мат. вычислений, возможность безболезненного вызова Фортран-кода и т.д. Numba позволяет и Python превратить в нечто похожее, но данную комбинацию я ещё в полной мере не пробовал.
P.S. Я тот человек, который пришел в науку после университета без IT подготовки, но пытающийся расширять свой кругозор.
ООП, классы, интерфейсы, области видимости и т.д.
Ну честно говоря им хватает этого, т.к. если я не ошибаюсь то например в opencv, ООП более менее начали использовать в 3 или 4(текущая 4.5) версии. А там сейчас порядка 600к строк и до сих пор есть куча объявлений через define.
Честно говоря, если пишешь программу на 1-2к строк, то ООП особо и не нужно, т.к. с большой вероятностью им хватит структурного программирования. Я не поддерживаю такой подход, но ученые в основном не пишут такой код, в котором нужны слишком сложные абстракции и т.д.
Многие ученые и код свой не прилагают к статьям, говоря только о результах симуляции, не давая возможности проверить, а как они вообще это насчитали.
Научные статьи пишутся для публикации новых научных результатов по физике в данном случае. Предполагается, что написанная программа достаточно хорошо оттестирована (верифицирована и/или валидирована, говоря современным языком). Часто такая программа является уникальной (не имеющей аналогов в мире) и является результатом высококвалифицированного труда многих лет. А принципы расчета описываются в виде системы уравнений, которые используются для моделирования. Собственно, моделирование находится довольно далеко от программирования и не ставит целью открытого распространения софта.
Предполагается, что написанная программа достаточно хорошо оттестирована
(верифицирована и/или валидирована, говоря современным языком).
По моему опыту реально наблюдается две ситуации: либо она все-таки не очень хорошо оттестированна (в крупных проектах решулярно находят баги в физических моделях) или же она оттестированна практически вручную, без всяких там новомодных иструментов для тестирования и после этого она неимеет потенциала к изменению, на код даже стараются "не дышать".
А принципы расчета описываются в виде системы уравнений, которые используются для моделирования.
Математическую модель можно считать по разному, и тут очень важен ваш алгоритм для расчета. Одну и туже модель можно считать очень по разному и без кода проверить кто из двух авторов обсчитался слабо реально.
Собственно, моделирование находится довольно далеко от программирования и не ставит целью открытого распространения софта.
Если поставить цель уйти совсем в ортодоксию, то можно сказать что моделирование без выложенного кода, это вообще крайне сомнительный научный результат.
Ну вот подход к программе как к системе уравнений - это и есть типичная ошибка физиков. Современная программа, особенно работающая с данными - это гораздо больше, чем просто алгоритм. Основная часть - это обвязка и инфраструктура. Точно так же как и в коммерческой разработке.
Поэтому если дать людям выбор, они будут писать на Python. Это не плохо само по себе, но проблема в том, что после публикации этот код можно выкинуть.
1) Если хочется имееть свежие версии фортрана нужно завязываться на проприетарные компиляторы, потому что подержка фортрана в том же gcc появляется с отстованием.
2) То что язык развивается это хорошо, но так он просто превращается в ещё один язык с ООП, причем априори хуже условного C++/Java/Kotlin, так имеет менее развитую экосистему/поддержку/тулинг/размер сообщетва etc.
3) Внезапно, нетолько JetBrains, но и мировые научные центры имеют кучу своих интернет-сервисов
Можете привести пример большого публичного проекта на Fortran 2018?
Прочитал и слегка обалдел. Это реклама какая-то чего-то? Я занимаюсь вычислительной физикой давно. Поэтому у меня две профессии - физика и программирование, которые друг без друга в моём случае не живут. С моей точки зрения, интервью полнО каких-то удивительных перлов, от которых несколько не по себе. Скажем,
Дело в том, что физики пишут вычислительный код на C++, а потом оборачивают его в код на Python.
Вот так. И ведь прочтёт кто-то, и нехорошо подумает. Или:
Важная особенность науки в том, что в ней очень мало профессиональных программистов.
Это правда. Но выше я ужЕ сказал - я профи. Но ведь в цитате не это имелось в виду. А вот то, что имелось в виду - это не правда. Поясню. Для этого нужно сформулировать, чем программирование в физике отличается от программистского мэйнстрима. Автор это даже не попытался сделать. Обработка больших объёмов данных - это как раз мэйнстрим (и то с оговорками, то есть, если дело не доходит до физического смысла результатов такой обработки). Вот смотрИте: я хочу численно изучить некую физическую систему. Мне нужна физическая модель. Потом математическая модель. Потом я пробую сделать какие-то оценки на пальцах, чтобы понять, а чего мне ожидать. Я должен знать ответ заранее, пусть в общих чертах. Потом я попытаюсь это посчитать на бумаге. Асимптотики, теория возмущений - иногда можно получить что-то интересное. Но и так ясно - нужна численная модель. Так вот. Тупо в лоб это, как правило, не пробивается. То есть, вот эта метода: "ага, дифуры? возьмём библиотеку и посчитаем" - она для сложных задач не работает в принципе. Чтобы продвинуться, вы должны в своём численном алгоритме учесть особенности вот этой конкретной физической модели. Возможно, где-то есть скрытые симметрии (очень эффективная штука). Возможно, что-то толстенькое (поток электронов, например) можно в рамках данной задачи разбить на набор чего-то тоненького, а взаимодействие между этими частями упростить. И так далее. Тут нет общих решений. Всё только под конкретную модель явления. И, глядишь, непробиваемая задача начинает довольно шустро вычисляться. Но это только одна сторона, физическая. Есть и встречная программистская. В каждой нетривиальной задаче есть узкие с точки зрения вычислительных затрат места. Тут на Хабре иногда появляются статьи на этот счёт. Бывает выгодно вычисления с плавающей точкой (что для физики естественно) переформулировать в целочисленные, определённым образом организованные. И это тоже определяется задачей. И делается это ручками на ассемблере.
А теперь скажите мне, дорогие друзья, о приглашении каких "профессиональных программистов" на подобного рода работу идёт речь? Ещё одна специфика "научных" программ заключается в том (это отчасти - следствие вышесказанного), что они относительно не велики по размеру. 10 тыс. строк кода - это порядок верхней планки. Их сложность не в объёме, а в структуре, которая сильнейшим образом зависит от структуры физической модели. Поэтому, вообще говоря, совершенно безразлично, на каком языке это написано. Всё определяется удобством, в том числе, и личным. Ну, и любопытством ещё. Мои любимцы - Фортран и Паскаль (Дельфи). А диапазон - от Алгола-60 до Джулии (она забавная).
Но современные программы так не пишут.
Лучше всего, когда у человека есть хотя бы небольшой опыт промышленной разработки. Я имею в виду не работу в фирме, а практику в веб-разработке или других востребованных областях.
Вот я об этом. Веб-разработка - это основная проблема в программировании в физике. А "так не пишут" - это значит, автор точно знает, как именно пишут. Слишком много слов. Я умолкаю.
> Но в большинстве наук всё ещё используют библиотеки C, Fortran и С++, а над ними пишут надстройку на Python
мне это место тоже понравилось, даже не знаю что и думать
Представьте, но это действительно так.
Julia на этом даже всю идеологию строит: https://juliadatascience.io/julia_accomplish#sec:two_language
сомнения в части использования интерпретаторов типа Python в научных рассчетах, если объем вычислений значительный (что характерно), как раз с Julia насколько понимаю проблем быть не должно,
конечно разделение профессионалов на физиков и программистов, представляется сильно устаревшим, ценность хорошего программиста в современных условиях min на 50% определяется знанием предметной области, imho взаимное проникновение областей смежных с программированием должно только приветствоваться, конечно всегда будут ислючения, но по личному мнению это должно быть где-то на уровне nobel prize winners,
ps
проблему поддержки кода большого объема и пр. вполне понимаю, хотя имел дело с этим только в промышленности, возможно все связано с проблемами финансирования науки в целом, и недостаточного понимания роли sw в ее развитии
Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
спасибо, чуть понятней,
> нельзя быть одновременно крутыми во всем,
иногда можно, если очень требуется :)
> поэтому требуется создание самого понятия "физик-программист
конечно, типа как в bioinformatics, где это вероятно даже более актуально,
помню времена когда за такую фигню как текстовый редактор ученые степени давали, сейчас конечно это типа курам насмех, опыт разработки sw накоплен огромный, типа 40% инженерной силы в us работают над sw, в промышленности дело движется вероятно особенно быстро именно в смежных областях между sw и hw (real time, robotics),
но возможно пришло время серьезно заняться систематизацией sw написанного именно в научных целях, не в виде поддержки реликтов, а координации усилий в совместной разработке нового поколения, типа передвинуть приоритеты, и наметить планы, а не делать ad hoc под конкретные проекты, что возможно потребует совместных усилий сотен людей, как это было на ранних стадиях создания сети
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть.
"Сейчас" - это сильно сказано. С конца 60-х вовсю моделировались процессы в плазме, нелинейные волновые явления, процессы в приборах на сильноточных и релятивистских электронных пучках, и другие замечательные вещи. Скажем, на физфаке МГУ на кафедрах волновых процессов и радиофизики сформировались группы физиков-программистов. Это всё было популярно у студентов, при распределении на эти кафедры был нешуточный конкурс. И да, нужно было быть крутым и там, и там. Был драйв, была сильная мотивация. Бегали на спецкурсы мехмата и ВМК. Приглашали супер спецов со стороны читать семестровые курсы по программированию. Подчеркну, это было фактически пол века назад. Всё, что надо, было "стёрто" тогда. Ничего выдумывать не нужно.
Я укажу вам на ключевое ваше заблуждение:
10 тыс. строк кода - это порядок верхней планки.
CORSIKA это более 100 тыс. строк кода на фотране (причем большая часть кода находится внутри одного файла, кек)
GEANT4 более 3 миллионов строк кода. И это не исключение: ANSYS, COMSOL, TANGO, DOOCS, FLUKA, ROOT --- это проекты с гигантскими кодовыми базами.
А я не это имел в виду (что имел - постарался, как мог, очертить). Понятно, что ребята из ЦЕРНа, Дубны или иного могучего экспериментального подразделения могут и ваяют миллионы строк. Там одних библиотек на фортране, Си, и так далее, за десятки лет написано несметное количество. То же самое относится к САПРовским проектам. Нет вопросов. Это большие коллективы тружеников. Бог им в помощь. Лично я никогда не работал в локальных группах из более трёх человек. В моём мире это обычное дело. И каждая задача - отдельно. Не люблю пережевывать уже один раз сделанное. И вот по моемУ личному опыту и наблюдениям более примерно 10 тыс. строк на проект - редкость. Это значит, автор перестарался, скорее всего.
Мои любимцы - Фортран и Паскаль (Дельфи).
Я тут конечно могу задать не удобный вопрос, который объяснит почему не смотрятя на преимущетсва Паскаля он не смог особо распространится в мире за пределами ex-USSR.
Собственно вы полностью повторяете тезис о том, что просто взять программистов и посадить их делать "физику" нельзя. Я об этом и говорил. Но в то же время, физики сами не справляются с тем, чтобы создавать инфраструктуру для решения своих больших задач.
Справиться-то они справятся, но при этом с большой вероятностью перестанут быть физиками. На моей практике таких примеров уйма.
Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Спасибо за адекватный комментарий!
Фортран в научном программировании будет еще долго - на нем написано 50% программ моделирования для суперкомпьютеров, большое количество библиотек и просто еще есть много сотрудников, для которых он является самым удобным и безопасным в смысле защиты от совершения ошибок.
Да, интерфейс можно (и лучше) дописать на чем-то еще. Интерфейс, конечно, делает эксплуатацию кода более комфортной, но для доработки и отладки вычислительного кода он ученому не нужен.
Software engineering, конечно, важная вещь, но тут важно не ставить телегу впереди лошади (надеюсь, никого не обидел).
Как я и писал, есть разные задачи. Есть код для суперкомпьютеров, который пишется под конкретную очень узкую задачу и практически не меняется. Но это очень малая часть всего многообразия научного программирования. А в массе своей, затраты на поддержку "творческого" кода огромны.
Если не сложно - объясните с чем Вы не были не согласны, написав ответ?
Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Разница в том, что мы смотрим на проблему с разных сторон. Для программиста основной частью является фреймворк, а для физика модель, реализованная с помощью алгоритмов в код для моделирования. Причем, научные данные получаются на основе моделирования, в то время как обработка, в общем-то, вторична. Хотя и выявляет полученные на основе моделирования знания.
Есть пакеты на фортране, в том числе активно развиваемые, которым уже в силу объема не грозит перевод на другой язык. Насколько вижу я в своей области, фортран достаточно широко используется.
Все стало настолько разнообразным и вариативным, что быть в курсе всего практически невозможно. Поэтому благодарю за Вашу точку зрения.
Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
Я тут туплю что-то. Вы изобрели алгоритм (предположим), и потом понесли его куда-то внедрять? Или он Вам же и нужен? А что значит "нет проблем с алгоритмами"? С известными - нет, с неизвестными - всегда. Остальное - дым над водой, имхо. Перед Вами же всё тот же древний цифровой автомат, что был лет 60 назад. И даже дольше.
Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
А вам не кажется, что физик - это непосредственно человек решивший/составивший уравнения, а те кто дальше уже код писал - это не физики, а просто, то что называется, технишены?
Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
Дык, сам в 2022 моделирую течение крови в кровеносных сосудах и прочие Навье-Стоксы на Фортране. Такая легаси досталась. Интерфейса нормального не хватает, это да, но основную свою задачу как инструмент решает.
Для вычислительных алгоритмов уравнений в частных производных подмножество операций таково, что на чем писать не имеет существенной разницы. Мне легко их писать и на фортране, и на паскале и на С/С++. Интерфейс вещь хорошая и полезная, но как только возникает слабоповторяемая ошибка в программе, то первое, что приходится делать для её локализации - это отцеплять от собственно вычислительного кода "все бантики". Вообще, для тщательно тестированной программы желательно иметь её варианты на двух языках, одним из которых является фортран. Как ни говори, у него есть немало достоинств.
Программирование в науке: полувековое легаси и Fortran 77