Александр Нозик, физик и программист, руководитель 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. Но я не особо за ними слежу, потому что там не столько рассказывают о новых разработках, сколько переосмысливают сделанное.