Александр Нозик, физик и программист, руководитель Nuclear Physics Methods Laboratory в JetBrains Research, заместитель заведующего Лабораторией методов ядерно-физических экспериментов и магистерской программой в МФТИ — о том, как перевести научный код на современный стек и почему в науку тяжело внедрять новые инструменты. Статья написана на основе выпуска подкаста «Люди и код» от Skillbox (декабрь 2021 года).
— Александр, расскажите, чем занимаетесь и какие задачи решаете?
— Моё основное место работы — Московский физико-технический институт (МФТИ), также известный как Физтех. Помимо этого, я работаю в Институте ядерных исследований РАН и JetBrains Research — это сообщество лабораторий, связанных с JetBrains. Компания поддерживает лаборатории и таким образом собирает вокруг себя научное сообщество.
Я занимаюсь физикой нейтрино, это основное направление моей научной деятельности. Но в последние годы больше разрабатываю софт и библиотеки для научных исследований.
— Чем наука отличается от коммерческой разработки с точки зрения задач? Как это влияет на выбор инструментов и языков программирования?
— Наука всегда была и остаётся «быстрее, выше, сильнее» остальных сфер. Учёные часто решают те же задачи, что и в коммерческой разработке, но на гораздо большем масштабе. Вспомним интернет-протокол HTTP: изначально его создавали, чтобы научные центры могли обмениваться большими объёмами данных. В одном из коридоров ЦЕРНа даже висит табличка: «В этой комнате придумали интернет».
В экспериментах по ускорению частиц на Большом адронном коллайдере, если мне не изменяет память, генерируется 25 ГБ данных в минуту. Для коммерческих проектов это просто непостижимо. Мы работаем с такими объёмами данных, которых больше нигде нет.
Анализ данных и так называемый Data Science уже стали частью промышленности. «Так называемый», потому что до сих пор нет чёткого определения, что это за наука такая. Тем не менее всю методологию и новые инструменты разрабатывают учёные, потому что только они могут оперировать сложными математическими моделями.
Важная особенность науки в том, что в ней очень мало профессиональных программистов. Поэтому инструменты, которые используют учёные, должны быть не только самыми гибкими и быстрыми, но и простыми. Иначе учёные-непрограммисты, такого наваяют, что потом никто не сможет это разобрать. Собственно, нечто подобное уже случилось в физике, и теперь научное сообщество решает эту проблему.
Дело в том, что физики пишут вычислительный код на C++, а потом оборачивают его в код на Python. И мне кажется, этот подход себя изжил: на Python очень сложно поддерживать большую кодовую базу, а тут размеры проектов растут именно на стороне пользователей кода — учёных. Поэтому такие системы потихоньку рассыпаются и последние пять лет инженеры и учёные ищут более гибкие и простые альтернативы.
— А в других науках используют такую же связку языков?
— Да, везде примерно то же самое, но с небольшой разницей. Например, биоинформатика как отдельная область появилась относительно недавно. В отличие от физиков, которым пришлось «пересаживаться» на Python, там сразу стали работать на современных языках. Но в большинстве наук всё ещё используют библиотеки C, Fortran и С++, а над ними пишут надстройку на Python. И там сейчас те же самые проблемы с гибкостью.
Кроме Python в разных областях науки пишут или пытались писать на других языках.
R. Его используют в статистике. Это узкоспециализированный язык, который отлично подходит для решения статистических задач. Но часто нам надо не только получить данные, но и сделать веб-сервис, чтобы пользователь имел доступ к этим данным. Написать его на R — дело непростое.
Julia. Это довольно интересный язык со множеством конструктивных особенностей. Попробуйте его, если вам не хватает скорости или гибкости в Python. Хотя и у Julia есть недостаток: его набор инструментов всё ещё нестабильный.
Julia придумали как альтернативу Python и MATLAB. Последний до сих пор используют, но это проприетарная, «неживая» система. Как только вы выходите за рамки привычных задач, то сразу ощущаете его ограниченность.
Swift. Из Swift тоже пытались сделать универсальный язык, но он так и не вышел за рамки iOS. А потом появился Kotlin, который по синтаксису сильно напоминает Swift, но при этом подходит для решения более широкого спектра задач и позволяет работать с библиотеками из Java, JavaScript и C.
Java. Раньше я программировал на Java — это классный язык, который часто несправедливо ругают. Его создавали для энтерпрайза, поэтому там чересчур затянутая «церемония»: чтобы собрать простое приложение, надо написать много дополнительного кода. Да, это упрощает поддержку и повышает стабильность приложения, но сильно усложняет сам процесс программирования.
Kotlin. Сейчас я много пишу на Kotlin. Он обладает достоинствами Java, но избавляет программиста от доброй половины «церемоний», и потому, на мой взгляд, у него большие перспективы.
Какие основные проблемы в научном IT и как их пытаются решить
— Вы упомянули, что в науке было много всего наворочено. Интересно, это относится только к библиотекам на Fortran и С++ или к чему-то ещё? И в чём там главные проблемы?
— Это очень большая проблема, которую нам ещё долго предстоит разгребать. Дело в том, что однажды разработка превратилась в отдельную профессиональную область. 40 лет назад, когда программирование только зарождалось, физики были самыми крутыми программистами. Они работали на здоровенных машинах размером со шкаф, и всем всё было понятно. Но 15–20 лет назад оказалось, что software engineering — это самостоятельная инженерная область.
Учёные сильно отстали, потому что продолжали разрабатывать ПО в том же стиле, в котором делали это на допотопных мейнфреймах. Они придумывали замечательные алгоритмы, но совсем не думали о поддержке кода, тестировании, CI/CD и тем более об архитектуре.
Например, системы сбора данных совершенно не умеют взаимодействовать друг с другом. Их писали разные программисты, которые иногда специально делали так, чтобы системы не могли общаться между собой. Если два эксперимента выполнены на разных системах, то учёному придётся обрабатывать их результаты по отдельности. Более того, на изучение каждой системы может уйти несколько лет — настолько они сложные.
Из-за того, что в науке не внедряли современные подходы к проектированию ПО и не использовали новые инструменты, у нас накопились миллионы строк легаси. Там можно встретить хорошие и даже гениальные алгоритмы, но понять их будет практически невозможно. Чтобы почувствовать всю боль, найдите программу на Fortran 77 и попробуйте понять, что там происходит.
Для справки: в Fortran 77 длина имени переменной ограничена восемью символами. Это значит, что, когда заканчиваются все подходящие имена переменных, программа становится нечитаемой. В ход идут числобуквенные идентификаторы, с которыми код становится только запутанней. А ведь большая часть программ в науке всё ещё написана на Fortran.
Относительно недавно учёные поняли, что нужно инвестировать в software engineering, уделять внимание архитектуре и осваивать современные инструменты, а не городить свои велосипеды. К моему удивлению, за последние два года появилось много групп инженеров, которые целенаправленно продвигают современный подход в науке.
— Расскажите немного, что это за группы и чем они занимаются?
— К ним относятся наша лаборатория в Физтехе и в JetBrains Research. Мы пытались продвигать новый подход в ИЯИ РАН ещё восемь лет назад, но столкнулись с сопротивлением. Нельзя просто прийти к учёным и сказать: «Мы хотим написать новую программу, которая будет делать то же самое, что и ваша старая, только гораздо удобнее». Вам ответят: «А у нас и так всё хорошо работает». И никого не волнует, что 80% своего времени они тратят на совершенно бесполезные вещи. Тем не менее в некоторых отраслях стоимость поддержки становится критичной и научное сообщество обращает на это внимание.
Есть и другие группы. Например, недавно мы познакомились с коллегами из института CASUS Science в Дрездене. Мы тесно сотрудничаем с учёными из «Немецкого электронного синхротрона» (DESY) по фундаментальным и прикладным исследованиям. Ещё геоинформатики в Германии внедряют у себя Big Data, как когда-то это сделали в биоинформатике.
Есть и отдельные инженеры, которых мы знаем по JetBrains Research, в Новосибирске и Петербурге. В ЦЕРНе на Большом адронном коллайдере уже довольно давно работает своя группа. Хотя её основная задача — поддерживать существующие системы, а не разрабатывать новые. ВШЭ и «Яндекс» открыли лабораторию Lambda. Правда, пока они используют только методы machine learning, а software engineering не трогают.
— Такие группы только разрабатывают софт или ещё проповедуют свои идеи, организовывают конференции?
— Сообщество software engineering начало собираться в российской науке совсем недавно. Люди только осознают, что нужно менять инструментарий, и потихоньку разрабатывают свои программы, оглядываясь на других.
Мы с коллегами хотим создать сообщество, чтобы обсуждать насущные проблемы IT в науке и обмениваться идеями. Нас поддерживают учёные из других групп, поэтому думаю, что скоро нас станет гораздо больше.
Ещё важный момент. Софтверные группы при исследовательских центрах и крупных экспериментах действуют уже давно. Но они работают как энтерпрайз: быстро решают конкретную задачу и не думают о развитии направления. А продвигать новые архитектуры, инструменты и подходы надо долго и целенаправленно.
Какие проблемы существуют в обучении учёных программированию
— Наверняка преподаватели старой школы отличаются от аспирантов и молодых учёных 30–35 лет. Кому проще объяснить, что необходим системный подход к инжинирингу и выбору тулинга?
— С молодёжью, конечно, договориться проще. Уже в школах и институтах они знакомятся с разными инструментами и понимают, что многие вещи можно делать иначе. А вот учёные старой школы с большим трудом вылезают из привычной экосистемы. Не то чтобы они этого не хотели – просто не видят путей.
Яркий пример: многие сидят на С++ 11 и даже не подозревают об этом. Причём на самом деле они почти не используют возможности C++ 11, а пишут на С++ 98. Если спросить типичного физика, который говорит: «Я знаю С++», про смарт-пойнтеры (необходимую вещь для менеджмента памяти в современном С++), то, скорее всего, он ничего не расскажет.
Я задаю один и тот же вопрос всем «знатокам»: «Как управлять памятью в С++?» Большинство начинает рассказывать про new, delete и так далее. Но современные программы так не пишут.
Лучше всего, когда у человека есть хотя бы небольшой опыт промышленной разработки. Я имею в виду не работу в фирме, а практику в веб-разработке или других востребованных областях. С такими инженерами уже можно говорить на одном языке.
— Как помогает государство или бизнес? Ведётся ли какая-то целенаправленная работа по технологическому обучению молодых физиков, математиков и биологов?
В этом направлении работают компании, правда пока не очень слаженно. Бизнесу выгодно развивать научное программирование, потому что, как я уже сказал, наука решает самые сложные задачи. Кто-то из науки переходит в коммерческую разработку, и компании с радостью хантят таких специалистов. Таким образом, мы тренируем людей на своих задачах и тестируем инструменты компаний.
На Западе в развитие научного тулинга вкладываются гиганты вроде Microsoft и Google, а в России — JetBrains и «Яндекс». Компании поменьше тоже подтягиваются, но пока не знают, с чего начать. Ведь для этого нужно понимать, как работает образование.
— Вы говорили, что за долгие годы в науке накопилось много легаси-кода. Надо ли его переписывать на современный стек или можно оставить как есть, но при этом сменить прослойку из кода на Python?
— И то и другое. Я думаю, что рано или поздно все библиотеки придётся переписать, потому что прослойка не решает всех проблем. Как только вы захотите поменять что-нибудь внутри — а не бывает такого кода, который никогда не меняется, — вы застрянете из-за бесконечно долгой поддержки.
Конечно, невозможно переписать в одночасье всю кодовую базу, поэтому пока мы работаем с обёрткой там, где это возможно. Сам С++ подкидывает проблем, потому что очень плохо дружит с другими языками, для него невозможно писать удобные прослойки. Поэтому зачастую получается vendor lock — чтобы подключиться к старому коду на С++, новый тоже приходится писать на плюсах. Я думаю, с этой проблемой скоро разберутся, потому что стоимость поддержки старых программ растёт.
— Как, на ваш взгляд, выглядит идеальная модель научной IT-инфраструктуры? Какими должны быть железо и программный стек, какие инструменты должны использоваться?
— На этот вопрос нет однозначного ответа, потому что задачи могут быть разные. Например, иногда нужны суперкомпьютеры. Таких задач немного, но они есть, и в них всё завязано на суперкомпьютерах. В большинстве же случаев достаточно мощности персоналок.
Я думаю, что научная IT-инфраструктура должна как минимум не отставать от коммерческой. Обязательно нужны IDE, автоматическая проверка кода, автоматическое тестирование и continuous integration. Последнюю уже внедрили в большой части проектов, но она ещё не до всех дошла.
Нужно внедрять микросервисную архитектуру, потому что наш огромный «зоопарк» инструментов практически нереально подружить. Они написаны на разных языках и реализуют разные протоколы, поэтому вряд ли получится наладить коммуникацию между ними. Думаю, мы движемся к веб-сервисам, браузерной визуализации и, возможно, к распределённой архитектуре. Сейчас много говорят о распределённых вычислениях и удалённой разработке, но пока такие проекты находятся в пилотной стадии.
Как помочь науке и какие технологии изучать начинающим учёным
— Какие есть опенсорс-проекты по переводу старых библиотек в новые? Работаете ли вы с контрибьюторами и как волонтёрам подключаться к крупным инициативам?
— Да, буквально недавно мы обсуждали несколько таких задач. Недавно Дмитрий Костюнин из Технологического института Карлсруэ (KIT) выступал с докладом о переводе CORSIKA, одной из основных библиотек для моделирования, со старого Fortran на современный С++. Проект полностью открытый, туда приглашают всех, кто умеет программировать.
Есть много легаси-кода, который надо просто почистить, найти в нём узкие места и так далее. Большая часть кодовой базы, к счастью, уже открыта и лежит на GitHub. Можно поискать эти проекты и присоединиться.
Основная проблема с переводом в том, что большая часть задач написана не на программистском языке. Было несколько попыток привлечь профессиональных программистов к научной разработке. Например, ЦЕРН когда-то пытался, но столкнулся с банальной проблемой: программисты не понимают, чего хотят физики, а физики не могут доступно объяснить задачу программистам. Поэтому куда проще применить машинное обучение, для которого вообще ничего понимать не надо. Собственно, в этом главная прелесть machine learning.
Учёные, которые более-менее разбираются в программировании, должны формулировать задачи так, чтобы программисты их понимали. Вообще, у разработчиков большой интерес к нашей области. Ко мне часто обращаются энтузиасты и просят дать какое-нибудь задание.
— А что бы вы посоветовали тем, кто только приходит в науку или уже пришёл, но без нормальной IT-подготовки? Какой минимум нужно освоить, чтобы делать хорошие вещи?
— Развивайте кругозор и знакомьтесь с разными областями программирования. В первую очередь — с веб-разработкой, потому что именно там используют самые современные технологии. Желательно знать, как работают простые веб-проекты и сервисы.
В научном софте много проблем с архитектурой, поэтому полезно посмотреть, как устроены большие проекты и как в них организуются потоки данных. Послушайте доклады с конференций по коммерческой разработке, попробуйте их понять и подумайте, как эти технологии можно применить в вашей деятельности.
Разумеется, в инженерии без опыта ничего не сделаешь. Но вообще, это очень хорошая идея — сделать cheat sheet, как максимально быстро перейти на следующий уровень мастерства.
— Что порекомендуете почитать по этой теме? На кого подписаться, за кем следить?
— Первое, что рекомендую, — подписаться на JetBrains Research. У них есть материалы о computer science и натуральных науках на русском языке, а в Telegram можно найти инвайты на семинары в Zoom.
ЦЕРН регулярно выпускает доклады по software engineering. Но я не особо за ними слежу, потому что там не столько рассказывают о новых разработках, сколько переосмысливают сделанное.
Комментарии (45)
sentimentaltrooper
14.03.2022 16:13+3Я сам физик (ФФ, волна + E.Polytechnique + ULaval) и не-программист после 10 лет в науке ушёл в смежную область (вместо должности профессора выбрал по сути коммерческое R&D). Добавлю что у академии и бизнеса очень разный подход. Науку чаще всего по факту делают PhD и постдоки. Группы чаще небольшие (20 человек это большая группа), проекты или их аспекты чаще новые для каждого. PhD делают 3 года, постдок как правило на годовых контрактах. Задача и того и другого - публикации (я в эту игру профессионально играл, устриц ел). Для бизнеса и три года и один невероятно долго, а защищаться по зоопарку мелких задач сложно. В итоге бизнес входит по-принципу «что не жалко» и что не очень ждём. А исполнитель может писать любой код на любом языке, делать абсолютно все что угодно если это даёт прототип и публикуемый результат (в конце статьи пишется параграф как продолжение этой работы принесёт мировое счастье). Поддерживать код лично он скорее всего не будет (для карьеры плохо сидеть на одном месте ). Опять же физика никто специально не учил программировать, чему сам нахватался то и хорошо.
В итоге я сейчас, по факту, занимаюсь подстройкой мостов между наукой и бизнесом - передачей технологии от одних к другим (и больше ничего не публикую :) ). Пусть не самых последних технологий, но с учётом интересов того кто даёт деньги и в разумные сроки за разумные деньги.
darksnake
15.03.2022 15:26Сейчас реально появились группы, которые занимаются этими "мостами" и мне кажется, что в будущем это будет востребованная ниша.
z0ic
14.03.2022 22:06+2Чем фортран не устраивает ? Есть стандарт 2018, не обязательно писать на 77. Просто нужно определиться с кругом задач. Если вы хотите создать очередной облачный сервис JetBrains от которого можно будет отключать пользователей из России, тогда достаточно взять [подставь сюда любой язык для которого есть JetBrains IDE].
EvgeniyMist
15.03.2022 08:25+1Во первых, как лично мне показалось, если автором и был кинут камень в огород Фортрана, то исключительно на территорию 77-го.
Во вторых, с использованием 2018-го стандарта есть проблема, которую автор также подметил. Работники науки старшей школы просто не понимают, зачем все это нужно: ООП, классы, интерфейсы, области видимости и т.д., если они всю жизнь обходились с помощью глобальных массивов (или даже массивА, разные части которого хранят разную информацию).
В третьих, как по мне, если и ставить цель избавиться от легаси в науки (а заодно и расширить кругозор некоторых ее работников) то 2018-ый Фортран является плохим вариантом. Ибо будем честны, язык уже фактически мертв (да, есть stdlib, fpm и ещё несколько проектов, но этого мало), даже несмотря на рейтинги Tiobe. Julia является прекрасной альтернативой: схожий синтаксис, скорость, наличие достаточного количества библиотек для мат. вычислений, возможность безболезненного вызова Фортран-кода и т.д. Numba позволяет и Python превратить в нечто похожее, но данную комбинацию я ещё в полной мере не пробовал.
P.S. Я тот человек, который пришел в науку после университета без IT подготовки, но пытающийся расширять свой кругозор.
calculator212
15.03.2022 09:31ООП, классы, интерфейсы, области видимости и т.д.
Ну честно говоря им хватает этого, т.к. если я не ошибаюсь то например в opencv, ООП более менее начали использовать в 3 или 4(текущая 4.5) версии. А там сейчас порядка 600к строк и до сих пор есть куча объявлений через define.
Честно говоря, если пишешь программу на 1-2к строк, то ООП особо и не нужно, т.к. с большой вероятностью им хватит структурного программирования. Я не поддерживаю такой подход, но ученые в основном не пишут такой код, в котором нужны слишком сложные абстракции и т.д.
MechanicZelenyy
15.03.2022 10:58+1Многие ученые и код свой не прилагают к статьям, говоря только о результах симуляции, не давая возможности проверить, а как они вообще это насчитали.
Kyushu
15.03.2022 12:28Научные статьи пишутся для публикации новых научных результатов по физике в данном случае. Предполагается, что написанная программа достаточно хорошо оттестирована (верифицирована и/или валидирована, говоря современным языком). Часто такая программа является уникальной (не имеющей аналогов в мире) и является результатом высококвалифицированного труда многих лет. А принципы расчета описываются в виде системы уравнений, которые используются для моделирования. Собственно, моделирование находится довольно далеко от программирования и не ставит целью открытого распространения софта.
MechanicZelenyy
15.03.2022 12:56Предполагается, что написанная программа достаточно хорошо оттестирована
(верифицирована и/или валидирована, говоря современным языком).По моему опыту реально наблюдается две ситуации: либо она все-таки не очень хорошо оттестированна (в крупных проектах решулярно находят баги в физических моделях) или же она оттестированна практически вручную, без всяких там новомодных иструментов для тестирования и после этого она неимеет потенциала к изменению, на код даже стараются "не дышать".
А принципы расчета описываются в виде системы уравнений, которые используются для моделирования.
Математическую модель можно считать по разному, и тут очень важен ваш алгоритм для расчета. Одну и туже модель можно считать очень по разному и без кода проверить кто из двух авторов обсчитался слабо реально.
Собственно, моделирование находится довольно далеко от программирования и не ставит целью открытого распространения софта.
Если поставить цель уйти совсем в ортодоксию, то можно сказать что моделирование без выложенного кода, это вообще крайне сомнительный научный результат.
darksnake
15.03.2022 15:32+1Ну вот подход к программе как к системе уравнений - это и есть типичная ошибка физиков. Современная программа, особенно работающая с данными - это гораздо больше, чем просто алгоритм. Основная часть - это обвязка и инфраструктура. Точно так же как и в коммерческой разработке.
darksnake
15.03.2022 15:30Поэтому если дать людям выбор, они будут писать на Python. Это не плохо само по себе, но проблема в том, что после публикации этот код можно выкинуть.
MechanicZelenyy
15.03.2022 10:57+11) Если хочется имееть свежие версии фортрана нужно завязываться на проприетарные компиляторы, потому что подержка фортрана в том же gcc появляется с отстованием.
2) То что язык развивается это хорошо, но так он просто превращается в ещё один язык с ООП, причем априори хуже условного C++/Java/Kotlin, так имеет менее развитую экосистему/поддержку/тулинг/размер сообщетва etc.
3) Внезапно, нетолько JetBrains, но и мировые научные центры имеют кучу своих интернет-сервисов
omxela
15.03.2022 00:30+8Прочитал и слегка обалдел. Это реклама какая-то чего-то? Я занимаюсь вычислительной физикой давно. Поэтому у меня две профессии - физика и программирование, которые друг без друга в моём случае не живут. С моей точки зрения, интервью полнО каких-то удивительных перлов, от которых несколько не по себе. Скажем,
Дело в том, что физики пишут вычислительный код на C++, а потом оборачивают его в код на Python.
Вот так. И ведь прочтёт кто-то, и нехорошо подумает. Или:
Важная особенность науки в том, что в ней очень мало профессиональных программистов.
Это правда. Но выше я ужЕ сказал - я профи. Но ведь в цитате не это имелось в виду. А вот то, что имелось в виду - это не правда. Поясню. Для этого нужно сформулировать, чем программирование в физике отличается от программистского мэйнстрима. Автор это даже не попытался сделать. Обработка больших объёмов данных - это как раз мэйнстрим (и то с оговорками, то есть, если дело не доходит до физического смысла результатов такой обработки). Вот смотрИте: я хочу численно изучить некую физическую систему. Мне нужна физическая модель. Потом математическая модель. Потом я пробую сделать какие-то оценки на пальцах, чтобы понять, а чего мне ожидать. Я должен знать ответ заранее, пусть в общих чертах. Потом я попытаюсь это посчитать на бумаге. Асимптотики, теория возмущений - иногда можно получить что-то интересное. Но и так ясно - нужна численная модель. Так вот. Тупо в лоб это, как правило, не пробивается. То есть, вот эта метода: "ага, дифуры? возьмём библиотеку и посчитаем" - она для сложных задач не работает в принципе. Чтобы продвинуться, вы должны в своём численном алгоритме учесть особенности вот этой конкретной физической модели. Возможно, где-то есть скрытые симметрии (очень эффективная штука). Возможно, что-то толстенькое (поток электронов, например) можно в рамках данной задачи разбить на набор чего-то тоненького, а взаимодействие между этими частями упростить. И так далее. Тут нет общих решений. Всё только под конкретную модель явления. И, глядишь, непробиваемая задача начинает довольно шустро вычисляться. Но это только одна сторона, физическая. Есть и встречная программистская. В каждой нетривиальной задаче есть узкие с точки зрения вычислительных затрат места. Тут на Хабре иногда появляются статьи на этот счёт. Бывает выгодно вычисления с плавающей точкой (что для физики естественно) переформулировать в целочисленные, определённым образом организованные. И это тоже определяется задачей. И делается это ручками на ассемблере.
А теперь скажите мне, дорогие друзья, о приглашении каких "профессиональных программистов" на подобного рода работу идёт речь? Ещё одна специфика "научных" программ заключается в том (это отчасти - следствие вышесказанного), что они относительно не велики по размеру. 10 тыс. строк кода - это порядок верхней планки. Их сложность не в объёме, а в структуре, которая сильнейшим образом зависит от структуры физической модели. Поэтому, вообще говоря, совершенно безразлично, на каком языке это написано. Всё определяется удобством, в том числе, и личным. Ну, и любопытством ещё. Мои любимцы - Фортран и Паскаль (Дельфи). А диапазон - от Алгола-60 до Джулии (она забавная).
Но современные программы так не пишут.
Лучше всего, когда у человека есть хотя бы небольшой опыт промышленной разработки. Я имею в виду не работу в фирме, а практику в веб-разработке или других востребованных областях.
Вот я об этом. Веб-разработка - это основная проблема в программировании в физике. А "так не пишут" - это значит, автор точно знает, как именно пишут. Слишком много слов. Я умолкаю.
victor_1212
15.03.2022 01:32> Но в большинстве наук всё ещё используют библиотеки C, Fortran и С++, а над ними пишут надстройку на Python
мне это место тоже понравилось, даже не знаю что и думать
darksnake
15.03.2022 15:43Julia на этом даже всю идеологию строит: https://juliadatascience.io/julia_accomplish#sec:two_language
victor_1212
15.03.2022 16:04сомнения в части использования интерпретаторов типа Python в научных рассчетах, если объем вычислений значительный (что характерно), как раз с Julia насколько понимаю проблем быть не должно,
конечно разделение профессионалов на физиков и программистов, представляется сильно устаревшим, ценность хорошего программиста в современных условиях min на 50% определяется знанием предметной области, imho взаимное проникновение областей смежных с программированием должно только приветствоваться, конечно всегда будут ислючения, но по личному мнению это должно быть где-то на уровне nobel prize winners,
ps
проблему поддержки кода большого объема и пр. вполне понимаю, хотя имел дело с этим только в промышленности, возможно все связано с проблемами финансирования науки в целом, и недостаточного понимания роли sw в ее развитии
darksnake
15.03.2022 16:41Скажу про то, что точно знаю. В физике частиц и биологии использование Python носит массовый характер. Там, где не Python, там архаичный кривой С++ где-то на уровне стандарта 98 года. Так что уже лучше Python. Julia отвоевала себе очень небольшую нишу. Я знаю буквально одну группу в физике частиц, которая ее использует.
Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть. Проблема в том, что нельзя быть одновременно крутыми во всем, поэтому требуется создание самого понятия "физик-программист". Оно сейчас формируется в сознании людей, но еще не сформировалось.
victor_1212
15.03.2022 18:05спасибо, чуть понятней,
> нельзя быть одновременно крутыми во всем,
иногда можно, если очень требуется :)
> поэтому требуется создание самого понятия "физик-программист
конечно, типа как в bioinformatics, где это вероятно даже более актуально,
помню времена когда за такую фигню как текстовый редактор ученые степени давали, сейчас конечно это типа курам насмех, опыт разработки sw накоплен огромный, типа 40% инженерной силы в us работают над sw, в промышленности дело движется вероятно особенно быстро именно в смежных областях между sw и hw (real time, robotics),
но возможно пришло время серьезно заняться систематизацией sw написанного именно в научных целях, не в виде поддержки реликтов, а координации усилий в совместной разработке нового поколения, типа передвинуть приоритеты, и наметить планы, а не делать ad hoc под конкретные проекты, что возможно потребует совместных усилий сотен людей, как это было на ранних стадиях создания сети
darksnake
15.03.2022 18:15Именно. Собственно время уже частично упущено. Потому что многие вещи проще заново написать, чем починить. Но лучше поздно, чем никогда.
omxela
15.03.2022 23:42Разделение на физиков и программистов де-факто есть. Но действительно, сейчас есть потребность его стереть.
"Сейчас" - это сильно сказано. С конца 60-х вовсю моделировались процессы в плазме, нелинейные волновые явления, процессы в приборах на сильноточных и релятивистских электронных пучках, и другие замечательные вещи. Скажем, на физфаке МГУ на кафедрах волновых процессов и радиофизики сформировались группы физиков-программистов. Это всё было популярно у студентов, при распределении на эти кафедры был нешуточный конкурс. И да, нужно было быть крутым и там, и там. Был драйв, была сильная мотивация. Бегали на спецкурсы мехмата и ВМК. Приглашали супер спецов со стороны читать семестровые курсы по программированию. Подчеркну, это было фактически пол века назад. Всё, что надо, было "стёрто" тогда. Ничего выдумывать не нужно.
MechanicZelenyy
15.03.2022 10:36+1Я укажу вам на ключевое ваше заблуждение:
10 тыс. строк кода - это порядок верхней планки.
CORSIKA это более 100 тыс. строк кода на фотране (причем большая часть кода находится внутри одного файла, кек)
GEANT4 более 3 миллионов строк кода. И это не исключение: ANSYS, COMSOL, TANGO, DOOCS, FLUKA, ROOT --- это проекты с гигантскими кодовыми базами.omxela
16.03.2022 00:17А я не это имел в виду (что имел - постарался, как мог, очертить). Понятно, что ребята из ЦЕРНа, Дубны или иного могучего экспериментального подразделения могут и ваяют миллионы строк. Там одних библиотек на фортране, Си, и так далее, за десятки лет написано несметное количество. То же самое относится к САПРовским проектам. Нет вопросов. Это большие коллективы тружеников. Бог им в помощь. Лично я никогда не работал в локальных группах из более трёх человек. В моём мире это обычное дело. И каждая задача - отдельно. Не люблю пережевывать уже один раз сделанное. И вот по моемУ личному опыту и наблюдениям более примерно 10 тыс. строк на проект - редкость. Это значит, автор перестарался, скорее всего.
MechanicZelenyy
15.03.2022 10:46Мои любимцы - Фортран и Паскаль (Дельфи).
Я тут конечно могу задать не удобный вопрос, который объяснит почему не смотрятя на преимущетсва Паскаля он не смог особо распространится в мире за пределами ex-USSR.
omxela
15.03.2022 23:52А я ничего не говорил о преимуществах Паскаля или фортрана. Их нет. Ни друг перед другом, ни перед другими языками. Вот об этом-то я и говорил. Без разницы. Но о своих личных предпочтениях позволил себе упомянуть.
darksnake
15.03.2022 15:37Собственно вы полностью повторяете тезис о том, что просто взять программистов и посадить их делать "физику" нельзя. Я об этом и говорил. Но в то же время, физики сами не справляются с тем, чтобы создавать инфраструктуру для решения своих больших задач.
Kyushu
15.03.2022 17:16Справиться-то они справятся, но при этом с большой вероятностью перестанут быть физиками. На моей практике таких примеров уйма.
darksnake
15.03.2022 17:33Есть и такое. Потому что разница зарплат слишком большая. Я же говорю о том, что должны быть систематическое решение. Нужно специально готовить "специалистов по мостам" и организовывать для них ставки. Не только в физике. Биология, география, гелология и так далее.
Тут есть еще одна проблема, про которую в интервью не было. Во многих научных организациях и проектах просто нет ставок для IT специалистов. Много публикаций по софту не напишешь, да и позиция там нужна не пост-дока, а подольше. Поэтому тут нужна еще инфраструктура самих научных организаций.
Сейчас идут другим путем. Создаются отдельные центры научного программирования, которые работают с научными организациями "на аутсорсе". Тоже вариант.
Kyushu
15.03.2022 12:16Фортран в научном программировании будет еще долго - на нем написано 50% программ моделирования для суперкомпьютеров, большое количество библиотек и просто еще есть много сотрудников, для которых он является самым удобным и безопасным в смысле защиты от совершения ошибок.
Да, интерфейс можно (и лучше) дописать на чем-то еще. Интерфейс, конечно, делает эксплуатацию кода более комфортной, но для доработки и отладки вычислительного кода он ученому не нужен.
Software engineering, конечно, важная вещь, но тут важно не ставить телегу впереди лошади (надеюсь, никого не обидел).
darksnake
15.03.2022 15:39+1Как я и писал, есть разные задачи. Есть код для суперкомпьютеров, который пишется под конкретную очень узкую задачу и практически не меняется. Но это очень малая часть всего многообразия научного программирования. А в массе своей, затраты на поддержку "творческого" кода огромны.
Kyushu
15.03.2022 17:05Если не сложно - объясните с чем Вы не были не согласны, написав ответ?
darksnake
15.03.2022 17:22Все ваши утверждения верны. Но только именно в приложении к суперкомпьютерным алгоритмам. Если уйти от них, то все три пункта оказываются не совсем верными.
Фортран актуален на суперкомпьютерах. Но за пределами этой области не используется практически совсем. Я знаю некоторых людей, которые иногда на нем пишут "для себя", но сейчас на нем прекращают даже поддержку проектов. Не говоря о новых проектах.
В задачах по сбору и анализу данных "интерфейс" является первичным. Реализацию как раз всегда можно подменить. Есть разные алгоритмы для того, чтобы сделать одно и то же, но если нет абстракции, которая их изолирует, то под каждый алгоритм надо переписывать всю систему. Это очень расточительно.
Собственно то же, что и пункт 2. В фреймворках, возьмите тот же CERN ROOT дизайн является первичным, а реализации вторичными. Когда эти системы создавались, они зачастую создавались вокруг алгоритмов. Но уже давно эти алгоритмы стали сильно вариативными и дизайн системы играет в целом большую если не бОльшую роль. Если есть контрпример - пишите.
Kyushu
15.03.2022 17:59Разница в том, что мы смотрим на проблему с разных сторон. Для программиста основной частью является фреймворк, а для физика модель, реализованная с помощью алгоритмов в код для моделирования. Причем, научные данные получаются на основе моделирования, в то время как обработка, в общем-то, вторична. Хотя и выявляет полученные на основе моделирования знания.
Есть пакеты на фортране, в том числе активно развиваемые, которым уже в силу объема не грозит перевод на другой язык. Насколько вижу я в своей области, фортран достаточно широко используется.
Все стало настолько разнообразным и вариативным, что быть в курсе всего практически невозможно. Поэтому благодарю за Вашу точку зрения.
darksnake
15.03.2022 18:14Так я в первую очередь физик. И во со всей профессиональной уверенностью могу сказать, что сейчас нет проблем с алгоритмами. Зато есть куча проблем с фреймворками. Собственно по этой причине между изобретениям алгоритмов и и их внедрением проходит куча времени.
omxela
16.03.2022 00:35Я тут туплю что-то. Вы изобрели алгоритм (предположим), и потом понесли его куда-то внедрять? Или он Вам же и нужен? А что значит "нет проблем с алгоритмами"? С известными - нет, с неизвестными - всегда. Остальное - дым над водой, имхо. Перед Вами же всё тот же древний цифровой автомат, что был лет 60 назад. И даже дольше.
darksnake
16.03.2022 09:42+1Ну собственно вы и тут и в другом своем комментарии подтверждаете один из моих поинтов из интервью. Вы утверждаете, что программирование сейчас и программирование 50 лет назад - это одно и тоже программирование. Это совсем не так. Это совсем другая дисциплина. Она имеет очень мало отношения к математике и очень много к инженерии. Я не готов тут полную лекцию про это рассказывать, так что просто буду апеллировать к своему опыту. Я начал что-то программировать где-то в конце 90-х и всю эту эволюцию очень хорошо вижу.
Людям, которые считают, что это "то же самое, что 50 лет назад", рекомендую пойти и почитать какие-нибудь форумы по веб бек-энд разработке современной и попробовать понять, что там происходит. И не говорите "это нам не нужно, у нас и так все работает".
cyberenigma
16.03.2022 20:21А вам не кажется, что физик - это непосредственно человек решивший/составивший уравнения, а те кто дальше уже код писал - это не физики, а просто, то что называется, технишены?
darksnake
16.03.2022 20:25+1Не кажется. "Составлением уравнений" занимается в лучшем случае теоретик, да и то далеко не каждый. Это что-то типа одного процента от всех физиков, если не меньше. Я экспериментатор и совершенно точно могу сказать, что "составления уравнений" там очень мало.
А в остальном, я же написал. Если сказать, что физик отвечает за физику, а программист за программу, то ничего не работает. Потому что первый второму не может объяснить, что надо делать. Опять же как физик-программист могу сказать, что в вычислительных методах и анализе данных очень много нюансов, которые нельзя эффективно разрешить без понимания предметной области.
kovserg
Видимо это и есть основная причина, почему программисты не понимают физиков. Думать приходиться обеим сторонам, а это не безболезненно.
ksbes
По своей практике скорее наоборот — физики не понимают программистов.
Программист, обычно, как и всякий инженер (кодеры с учёными не работают — учёные и сами часто неплохие кодеры) пытается сделать какой-никакой обобщённый продукт, а учёному продукт не нужен. Ему нужна гаражная поделка под данное конкретное исследование/грант. И далее чем на исследование вперёд учёный чаще всего свою работу не планирует и не хочет.
Поэтому тут нужен особый подход, как с Вольфрамом и прочими" Математиками" — учёный от программирования должен проводить мета-исследования по современной науке, выявлять проблемы и предлагать алгоритмы и организовывать их реализацию в ПО с помощью «обычных» программистов. Ну а учёный из других областей должен уметь всем этим пользоваться (и немного кодить на С и Excel) — это необходимая часть современной научной культуры.
А так напрямую — да мало чего хорошего и осмысленного получится.
Примерно как с математикой вообще (программирование — это прикладная математика). Какому-нибудь социологу или лингвисту тоже бывает сложно взаимодействовать даже с банальным аналитиком-статистиком, не говоря уже у чём-нибудь позабористее.
darksnake
Суть в том, что на текущем этапе уже нужны именно продукты. С супер-большими объемами данных и сложными структурами в ноутбучиках не поработаешь. И вы правы в том, что ученые этого не понимают.
А программисты хотят четкое ТЗ, которого в науке действительно быть не может.
Kyushu
Вот лучшее свидетельство того, что Вы - физик. :)