Если бы это двигали только ученые, то всю идею можно было бы класть в гроб и закапывать. Ученые — отличные генераторы идей и кадров, чтобы эти идеи реализовать.

Но как только мы выходим за рамки чистой идеи, и становится нужен минимальный менеджмент ресурсов, все оказывается плохо.

— Александр Нозик @darksnake, директор Scientific Programming Centre (SPC)

«Астрологи объявили» месяц научного open source, и это — большое интервью c Александром о развитии сферы научного программирования на основе открытых разработок. Говорим об истории вопроса, проблемах, менеджменте и не только.

Кстати, тут собрал ожидания экспертов на этот год в open source.

Расскажите, пожалуйста, о собственном профессиональном опыте и развитии в научном программировании. Чем вас заинтересовала эта сфера деятельности?

Наверное, тут надо начать, как учили позитивисты, с терминов. Что такое это «научное программирование». Центр научного программирования был «придуман» в 2021 году, а формально создан в 2022 году. И если поискать, то до этого момента термин почти не встречался, была пара книг с таким названием, но на этом все. Поэтому нам пришлось не столько «присоединиться к явлению», сколько в какой-то мере его изобрести.

Если взглянуть не на название, а на содержание, то тут корни уходят в гораздо более раннее время. Я поступил в МФТИ в 2002 году. У меня уже был некоторый опыт программирования на Pascal, С++ и Delphi так как в моем доме компьютер появился по российским меркам очень рано (в районе 1993 года), и мой отец осваивал программирование и немного учил меня. 

В 2004 году я пришел на кафедру ИЯИ РАН к академику Лобашеву. Какое-то время я пытался приткнуться к какой-то полезной работе, но ни у кого не было на меня времени, поэтому мне предложили самому найти, чем заняться. И я занялся тем, с чем был уже более или менее знаком — программированием и анализом данных.

По мере того, как я разбирался с этой «дисциплиной» и смотрел на то, что делают в этой сфере люди вокруг, я понимал, что качество программного обеспечения в науке крайне низкое, и есть многие вещи, которые можно было бы улучшить. В районе 2007 года мне стало совсем тесно в экосистеме «учебного» языка Оберон, который всячески проповедовал мой тогдашний наставник Федор Васильевич Ткачев, и я начал искать более индустриальные (хотя тогда я такого слова не знал) решения. И начал пробовать писать на Java.

По мере того, как я погружался в эту экосистему, мне все больше и больше становилось очевидно, что программы и методы, которые используют в науке, необратимо устарели и стали бы куда лучше, если в них можно было бы использовать современные (на тот момент) инструменты из прикладного программирования — но этого не получается добиться, потому что ученые в принципе не хотят и не умеют заниматься программированием.

А потом произошел обратный эффект. В 2016–2017 годах, перепробовав несколько разных языков, я начал активно писать на Kotlin и, что более важно, активно общаться в комьюнити. И обнаружил удивительную вещь: не только научные программы могут много выиграть от индустрии, но и в индустриальном программировании только-только начинают внедрять методы, которые я для своих поделок разрабатывал за несколько лет до этого.

То есть и индустрия может получить много пользы от науки.

Мои сотрудники прошли примерно тот же путь, хотя быть может и в более сжатые сроки. Большинство начинало в академической среде, но в какой-то момент смотрело в сторону индустриальных подходов и приходило к выводу о том, что «тут надо что-то делать».

Как это часто бывает с новыми идеями, пробиться было непросто. Я пытался создать маленькую лабораторию (сектор) в ИЯИ РАН для того, чтобы разрабатывать более эффективные и современные программы, но оказалось, что там просто нет программистов. При том, что потребность в более качественном ПО уже ощущалась, писать его было некому. Сейчас почти все мои сотрудники — это в той или иной мере мои ученики. В 2016 фундамента для такой работы не было. Пришлось его построить самостоятельно.

В общественном сознании переломными, наверное, можно считать «пандемические годы». За два года в мире появилось несколько групп, так же, как и мы, осознавших, что подход к разработке ПО в науке надо менять. Общество стало готово воспринимать эту идею. Хотя полного признания и инструментов для внедрения нет до сих пор.

Сейчас для нас «научное программирование» — это возможность привносить инструменты и методы из индустрии в ПО для науки, а также возможность привносить исследовательский подход и модельное мышление в индустриальную программную инженерию.

С учетом вашего опыта, можно ли утверждать, что сфера научного программирования становится более структурированной и понятной: как с позиции проблем, над которыми можно работать, так и карьерных возможностей?

Определенно наблюдается улучшение ситуации. Сейчас понимание того, что качество ПО в науке неудовлетворительное, является консенсусом. Принимаются меры для того, чтобы это изменить. Также в индустрии предпринимаются попытки приложить исследовательскую методологию к совершенствованию методов программной инженерии. К сожалению, понимание проблемы — не значит работающая система.

В академии главной проблемой является наукометрия. Много статей на разработке ПО не сделаешь. Журналы по тематике начали появляться, но их все еще очень и очень мало, и методология для «научной» публикации ПО отработана плохо. Кроме того, как минимум в России очень туго с грантами. Заявки все время «проваливаются мимо рубрикатора» — попадают либо к «физикам старой закалки», которые просто не признают программирование за что-то серьезное, либо в раздел computer science, который тоже не имеет почти ничего общего с программной инженерией и посвящен в основном разработке алгоритмов, а не реализации инженерных систем. [Интервью по теме — тут.]

В индустрии проблема другая. Многие компании пытаются создавать исследовательские подразделения, но сталкиваются с тем, что структура такого подразделения и методология его работы радикально отличается от того, что делается в индустриальной разработке. Для создания таких подразделений нужны люди с опытом и в академической науке, и в индустрии, а таких все еще очень мало. [Запись по теме — тут.]

Тем не менее мы видим вполне определенный и направленный процесс. И я уверен, что в течение нескольких лет эти проблемы будут решены и это понятие научного программирования станет неотъемлемой частью как НИИ, так и коммерческих компаний. Мы сами не сидим, сложа руки. Скоро будет третий выпуск нашей магистратуры. Мы каждый год ищем самых мотивированных студентов и привлекаем все новых академических и индустриальных партнеров.

Как вы могли бы охарактеризовать положение дел в мировом и российском научном программировании? В чем заключаются основные отличия? Что сейчас на переднем крае? Какие есть сложности? Какое место в этой истории занимает open source?

Последняя череда кризисов разной природы больно ударила не только по России. Многие инициативы по развитию научного ПО, которые возникли во время пандемии, не получили должного развития. Но общая тенденция везде одинаковая. Потребность в более плотной интеграции исследовательской деятельности и индустрии возрастает.

«Революция AI» сыграла в этом и хорошую, и плохую роль. Хорошая в том, что повысился интерес программистов (и, как следствие, богатых компаний) к науке. А плохая в том, что фокус опять перенесся с программной инженерии на алгоритмы, и такие вещи как архитектура и качество кода остались за бортом. Но эта волна сейчас везде спадает, и важность инфраструктуры (доставка данных для тех же ML-моделей, распределенные вычисления и так далее) опять выходит на первый план.

Open source играет во всей этой истории ключевую роль. Наука создается сообществом. Возможность исследовать что-то исключительно «в компании и для компании» давно не существует. А open source является единственным отработанным и принятым обществом вариантом сотрудничества между компаниями. Как я говорил до этого, инфраструктура и организационные формы для этого не идеальны как в академической среде (код это не публикация), так и в компаниях (каждая компания хочет сделать что-то «открытое, но свое»). Но, как минимум, проблемы эти осознаны и решаются.

В России, дополнительно ко всему вышеперечисленному, всегда была и есть проблема государства, которое часто пытается вмешаться туда, куда его не звали. Но необходимость быстро создавать замену многим проприетарным технологиям неожиданно подстегнула эту машину в нужном направлении. Государственные инициативы в области как open source вообще, так и научного ПО — все еще скорее бесполезная трата времени и денег, но и откровенного вредительства, как было со многими научным и образовательными инициативами до этого, вроде нет.

Какими разработками занимается ваш центр? Можно ли говорить об определенной специализации — например, на решениях для анализа и визуализации данных?

Для нашей команды 2024 год стал в своем роде переломным. Мы начали всерьез коммерчески внедрять наши open-source разработки. В первую очередь это Controls-kt — фреймворк для сбора данных с приборов и управления оборудованием (можно назвать это SCADA-системой, хотя трактовка этого термина у разных людей очень разная).

Фреймворк для визуализации VisionForge хотя все еще находится в экспериментальной стадии, тоже получил свои внедрения сразу в нескольких проектах. И под конец года у нас появился проект, где мы внедряем в банке наш самый старый проект: KMath (на самом деле самый старый — это DataForge, с него все начиналось, но он в основном составляет основу для других проектов). Есть и новые проекты: Maps-kt, по сути, появился только в этом году. И это, пожалуй, первая разработка, которая была сделана не под фундаментальную науку и не под «а почему бы нет», а под конкретный коммерческий проект (проект пока в полной мере не запустился, но разработка оказалась удачной и обрела свою собственную жизнь).

И отдельный интерес представляет маленький и очень экспериментальный, но идейно важный для нас проект snark. Когда мы начинали его, мы не очень понимали, зачем он нужен (впрочем, с остальными фундаментальными проектами то же самое), и главное его использование на сегодняшний день — это сайт центра. Но я не удивлюсь, если через 10 лет выяснится, что это самое главное, что мы сделали. Дело в том, что в этом проекте мы пытаемся понять, как должен выглядеть «научный журнал будущего» и как технически это обеспечить. Подробнее об этом можно почитать в дипломе Сергея Терентьева.

Переход к «режиму внедрения» — это в чем-то и плохо. Наши open-source проекты во многом — наши кормильцы, и мы теперь уже не можем себе позволить развивать все подряд. Каким-то проектам мы уделяем больше внимания, каким-то (например, tables-kt) — меньше. Да и наши флагманы часто получают кусок рабочего времени, только когда их надо куда-то «воткнуть». Это не тот режим, в котором нравится работать над проектами.

Но пока нет какого-то целевого финансирования под open source разработку, мы имеем то, что имеем. Хуже всего, конечно, с документацией. На нее вообще не хватает времени. А документация очень важна для расширения комьюнити. У нас обычно очень непростая архитектура, и понять ее без описания может далеко не каждый.

В какой момент вы приняли решение о развитии ваших проектов в open source-формате? С какими сложностями вы столкнулись на первых порах? Как решали их?

Наши проекты никогда не были закрытыми (не считая времен, когда мой mercurial-репозиторий существовал у меня на флешке). Почти все наши проекты начинались как части фундаментальных исследований. Их просто не было смысла делать закрытыми.

Тут, скорее, обратная история: в прошлом году у нас начали появляться закрытые проекты. То, что делается на заказ. Разумеется, мы стараемся, чтобы закрытые проекты основывались на наших открытых.

Самым больным ударом за последнее время было, разумеется, блокирование аккаунтов, ассоциированных с МФТИ гитхабом (в частности, моего персонального аккаунта, хотя с МФТИ он вообще-то никак не связан). Это никак не помешало нашей разработке технически (мы сейчас отлично живем на собственной gitea). Но психологически это было очень обидно. И коммуникация (а github — это, в первую очередь, социальная сеть) усложнилась. Я уверен, что в будущем появятся системы федераций для репозиториев с кодом, комментариев и «звездочек» (хотя напомню, что звездочки ничего не говорят о качестве и о востребованности, только об интересе). Но, к сожалению, пока этого нет.

Вы используете лицензию Apache 2.0 для большинства проектов — почему выбор пал именно на неё? Какие еще лицензии вы считаете востребованными?

Apache 2.0 — это одна из наиболее используемых permissive-лицензий, и она используется в Kotlin-сообществе. Я неоднократно говорил о том, что являюсь категорическим противником GPL-идеологии. Когда эта идеология создавалась, целью было не дать «корпорациям» зарабатывать на сообществе. Но с тех пор ситуация радикально поменялась. Корпорации являются главным финансовым двигателем open source.

Ставя заградительные вирусные лицензии, разработчики блокируют самую эффективную модель монетизации и развития своего кода. Корпорациям давно уже не выгодно «воровать» код, им лучше прийти к разработчику и заплатить за поддержку. История о том, что можно просто обратиться к держателю GPL-лицензии и заплатить, не работает. Потому что надо найти всю цепочку всех держателей лицензий транзитивных зависимостей.

Мы стараемся не делать зависимостей от GPL-проектов или делать их «отцепляемыми». Мы уже неоднократно сталкивались с ситуациями, когда нас специально просят подобрать открытые решения, в которых не было бы GPL-зависимостей.

Участвуют ли в open source-инициативах другие сотрудники вашего центра? Или же не все коллеги погружены в open source специфику?

Наши проекты полностью открыты. Мы приглашаем в них всех желающих. Ограничение есть, но оно скорее «естественное»: дело в том, что проекты, которыми мы занимаемся, как правило, очень сложные с точки зрения архитектуры и реализации. У сторонних контрибьютеров просто не всегда получается разобраться с ними, чтобы внести туда какой-то ощутимый вклад. Есть и те, кому это удавалось. Часть из них теперь в командах JetBrains, а часть мы взяли к себе на работу в коммерческие проекты.

Своего рода квалификационное испытание. По мере того, как уменьшается разрыв в квалификации между нашими самыми опытными и не самыми опытными сотрудниками, я надеюсь, что проектов и «контрибуций» будет становиться больше.

В какой момент вы начали системно развивать сообщество? Какие вы используете инструменты в онлайне (новостной канал, чат, что-то еще) и оффлайне (конференции, встречи)? Планируете ли вы расширять этот список?

Для того, чтобы определить момент, пришлось лезть в историю. Мы начали развивать комьюнити в районе 2017-2018 года. Практически сразу было понятно, что это очень важная часть функций тогда еще даже не лаборатории, а рабочей группы без какого-то юридического оформления. Причины, почему это важно, я кратко описал в статье.

Для создания своего комьюнити я опирался на опыт сообщества Kotlin. Опыт показывает, что организация комьюнити — это тоже своего рода «наука». Есть многие мелочи, которые надо учитывать. Нельзя пускать все на самотек, надо постоянно подкидывать какие-то идеи и мысли на обсуждение, чтобы у сообщества была «пища».

Кроме телеграм канала, есть еще YouTube. Это тоже очень важная площадка, которой уделяется (точнее, уделялось до последнего времени) недостаточно много внимания. Есть еще LinkedIn, которым вообще не занимались и занялись только в последний месяц.

В нашей сфере деятельности публичность — это не просто приятный бонус, но и вопрос денег и буквального выживания. Наш источник дохода — выполнение исследований и разработок на заказ. Для этого, у нас должна быть известность и репутация. В каком-то смысле можно сказать, что мы зарабатываем репутацию и потом ее монетизируем. Тем и живем. То, что наши сообщества полезны для людей — это тоже важный фактор роста. Так что работа сообщества и публичная активность была и будет одним из ключевых аспектов нашей работы.

Как бы вы объяснили управленцам российских научных центров и университетов ключевые преимущества работы в формате open source? Зачем им это? С чего стоит начинать подобные эксперименты и как оценивать их эффективность?

Правда в том, что мы пока не объяснили. Наши разработки на данный момент являются только нашими, университет не вложил туда ни капли. Я с начала года довольно активно лоббирую эту тему в МФТИ и надеюсь, что рано или поздно процесс увенчается результатом. Я написал несколько программных документов и «питчей» на эту тему.

Помимо очевидных слов об улучшении репутации и встраивании open source в образовательный процесс есть один специфический для России аспект. Промышленность столкнулась с тем, что надо разрабатывать многие решения, которые все привыкли покупать. Сейчас компании пытаются заниматься совершенно, на мой взгляд, дурной работой, связанной с попыткой самостоятельно «заместить» эти решения (например, в области АСУ) и монополизировать рынок. 

Разумеется, ресурсов на это ни у кого нет, да и мало кто хочет сменить одного монополиста на другого. Тут, казалось бы, надо собраться и силами нескольких больших компаний сделать общее открытое решение (открытость тут критична, потому что других способов коллабораций больших компаний нет). Но сразу возникает вопрос — а какая компания организует платформу для такой разработки? Как об этом договориться?

В России всего полторы компании, которые имеют опыт открытой разработки собственных проектов с нуля. Да и работать на платформе чужой компании многим религия не позволяет. И вот тут вузы, казалось бы, являются идеальной платформой. Они нейтральны, они уже имеют связь со многими компаниями, есть хороший источник кадров (бесплатных! дипломы и практики сами себя не сделают) и идей.

Все, что нужно — немного вложиться в эту историю. Но нет, все время встает вопрос «а что нам с этого будет до конца года и как это отразится в KPI».

Не буду тут приводить полный текст аналитических записок, которые писал на эту тему (кому надо, приходите — все контакты открытые), но приведу очень краткую «дорожную карту» действий, которые вуз мог бы сделать для развития open source экосистемы:

1. Информационная поддержка. Реклама среди промышленных компаний, организация хакатонов, семинаров и конференций (можно на деньги тех же компаний).

2. Программная инфраструктура — репозитории кода, общие чаты, хранилище для файлов (например, для MLщиков это очень важно, им модели хранить надо), CI/CD. А также single sign on и техподдержка этих систем.

3. Стипендии и гранты.

Обращаю внимание, что гранты тут на третьем месте, они нужны, когда система уже создана и развивается. Начать можно с совсем маленьких вложений. Достаточно просто признать существование такого направления.

Оценка эффективности — это всегда сложный вопрос. Царица всех оценок — экспертиза. Хотя экспертов по open source в России и немного. Из простых (и зачастую неправильных) критериев можно взять количество вовлеченных людей как внутри вуза, так и снаружи.

Справедливо ли говорить о том, разработки в научном программировании и решения для науки развивают исключительно ученые? Как вы оцениваете корпоративную активность в этой сфере? Можем ли вы увидеть больше вовлеченности со стороны компаний?

Я бы сказал так, если бы это двигали только ученые, то всю идею можно было бы класть в гроб и закапывать. Ученые — отличные генераторы идей и кадров, чтобы эти идеи реализовать. Но как только мы выходим за рамки чистой идеи, и становится нужен минимальный менеджмент ресурсов, все оказывается плохо.

К счастью, интерес со стороны компаний огромный. У них есть потребность и ресурсы, чтобы заниматься разработкой open source и научного программирования. Чего нет — это умения работать с учеными и с комьюнити, а также умения этому учиться (которое как раз характерно для ученых). Я думаю, что в каком-то скором времени в компаниях возникнут должности научных и open source амбассадоров. Точно так же, как возникли должности developer relations и developer advocate. О том, как я вижу это будущее, я подробно писал в статье.

Как только это случится, движение станет стремительным.

Людей, которые могут стать такими амбассадорами, сейчас немного. Но тут уже я очень рассчитываю на те сообщества, которые мы создаем, на наших студентов, которых мы обучаем в магистратуре, да и сам готов предложить свои услуги.

Если говорить об open source в России в целом, в каких сферах деятельности наиболее вероятно — на ваш взгляд — появление новых открытых проектов?

Сейчас самыми горячими мне видятся системы менеджмента (в разных сферах), управления ресурсами и управления процессами. Это ниша была занята проприетарными решениями, которые стали недоступны. Я ожидаю в ближайшее время очередного прорыва в области open hardware (переход его с любительского на индустриальный уровень) и соответствующего софта. Ожидаю чего-то интересного в системах управления знаниями. Возможно что-то в области мультиплатформенной разработки приложений и «возврата на desktop». Возможно, что-то связанное с полиглотным программированием на Wasm и смежными технологиями.

Какие еще российские open source-технологии были бы полезны для страны? В каком формате можно было бы организовать коллективную работу над ними?

Я глубоко убежден, что не может быть никакого «национального open source». Так же как не может быть в 21 веке сугубо национальной науки. И то, и другое развивается настолько успешно, насколько много участников процесса и связей между ними. Возможно, Китай может себе позволить что-то подобное, просто потому что там живет очень много людей, но мы видим, что даже Китай пытается интегрироваться в мировую систему разработки и науки, а не изолироваться от нее. Поэтому историю о том, что «нам не нужен американский open source, мы сделаем свой» я считаю исходно бредовой. Продвигать ее могут только совершенно далекие от реальности политики. 

Тем не менее, есть ряд действий, которые можно предпринять, чтобы open source-разработки и их внедрение в России шли активнее. В первую очередь речь об информационной политике. В России у компаний нет культуры собственной разработки, много лет они занимались тем, что покупали готовые (в основном американские) продукты, чем снимали с себя все риски.

Сейчас до многих внезапно (а что случилось?) дошло, что зависимость от проприетарных решений, у которых нет альтернатив — вещь опасная. А разрабатывать свои не умеем. Да и не то, что разрабатывать, адаптировать готовый open source не умеем. Потому что для адаптации тоже надо иметь какую-то свою разработку и брать на себя риски за нее.

Считаю, что (как минимум) в больших компаниях должны появиться офисы по исследованиям и разработкам, которые бы, в том числе, занимались развитием и адаптацией open source решений. Эти офисы могут работать с вузами и, возможно, другими типами инжиниринговых хабов, которые станут поставщиками новых решений. 

Я категорически против того, чтобы какую-то активную роль в процессе занимало государство. Государство может говорить, что это полезно. Но любая регуляция тут будет мешать. Все превратится в рисование отчетности и коррупцию. Чисто теоретически возможно создание налоговых льгот для R&D-компаний, которые подстегнут и науку, и разработку открытых проектов, но я не верю, что российское государство в нынешнем виде способно сделать такой механизм эффективным, а не очередным «попилом».

В целом, для развития open source (и исследований тоже, тут очень много общего) главным требованием является наличие квалифицированного заказчика, который понимает, как использовать результаты этих разработок. Вот с этим и надо в первую очередь работать. Сейчас в России таких квалифицированных заказчиков очень мало.

В одном из комментариев по теме вы говорили о необходимости поддержки малых open source-проектов. Как вы видите этот процесс? Требуется ли здесь участие государства или сообщество может обойтись своими силами?

Спасибо за этот вопрос. На мой взгляд очень важный момент в том, что open source-решения бывают разные. Когда люди начинают говорить об open source-решениях, в первую очередь приходят в голову такие монстры, как Linux, Postgres, Hadoop или Kafka. Огромные индустриальные решения, над которыми работают сотни человек по всему миру. Как правило, каждый разработчик добавляет очень небольшую модификацию, и самое сложное тут — пройти все этапы согласования и тестирования такого изменения. В России довольно много компаний, которые занимаются этими решениями. То есть адаптируют и интегрируют их для индустрии со сравнительно небольшими изменениями.

Но есть и совсем другой open source — сравнительно небольшие проекты, которые создаются «с нуля» группами до пяти человек, как правило, не афиллированными с компанией. Такие решения очень важны как сами по себе (детали, из которых потом можно создавать какие-то индустриальные конструкции), так и как технологическая база, на которой строится развитие всей технологии и людей, которые в ней задействованы. 

Действительно, ведь главным капиталом, как ни крути, являются люди. На добавлении двух строчек в Postgres (при всей важности этих двух строчек для индустрии) многому не научишься. Для того, чтобы люди становились высококлассными специалистами и создавали новые сложные системы, надо практиковаться на каких-то проектах с меньшим фактором риска. Также не надо забывать, что есть отдельные проекты, а есть экосистемы. Экосистемы (наборы инструментов для разных целей на определенных языках и фреймворках) сейчас куда важнее, чем, скажем, языки программирования. Потому что напрямую влияют на эффективность разработки.

Так вот с этими малыми проектами в России очень плохо. Буквально пара компаний вообще делает какой-то чисто свой open source, а не только патчи к чему-то «большому». Народные умельцы, разумеется, есть везде, и куча небольших библиотек делается такими умельцами из России. Но тут нет никакой системности. Нет фондов наподобие Apache, которые бы спонсировали бы подобные проекты, и нет хорошей поддержки со стороны компаний. Даже правила хакатонов обычно устроены так, что нормальный свой проект на них не поднимешь. Или вообще забирают код себе по итогу, или делают призы в виде купона на пользование облачными услугами компании (серьезно?!).

Я опять же категорически против вмешательства государства в эту область. Но создание некоммерческих фондов для развития независимых проектов и open source-хабов в вузах (например, для продвижения студенческих разработок) было бы очень полезным.

Могли бы вы порекомендовать пару книг материалов или ресурсов иного формата для погружения в специфику и тренды научного программирования?

Я бы не сказал, что сейчас есть какие-то тренды в данной области. Просто потому, что тема, как это не смешно, совершенно новая. Обычно, когда люди приходят с вопросами в первую очередь мы их отправляем смотреть, как делать НЕ надо. Например, ROOT. Про его проблемы я могу говорить часами. Люди, которые его писали, ставили перед собой задачу уйти от фортрановского кода предыдущего фреймворка PAW на более современный на тот момент (а это конец 90-х) С++. Проблема в том, что учились программировать они параллельно с написанием.

Огромное количество ошибок проектирования (например нарушение single responsibility практически везде), варварская работа со структурами данных (достаточно сказать, что основная структура TTree — это не дерево, а таблица, в ячейках которой могут быть другие таблицы) и многое другое. Самая большая проблема — сериализация. Формат представления данных (как говорит Алексей Худяков, испорченный дамп памяти). Я думаю, что его исходно делали в основном для тестирования, но в какой-то момент оказалось, что практически все физические эксперименты завязаны на этот формат. Он нормально читается только самим рутом, ломается при практически любых изменениях кода и, вопреки заявлениям любителей фреймворка, довольно неэффективен. Но убрать его уже никуда нельзя, потому что это означает перелопатить петабайты данных и переучить тысячи людей пользоваться человеческими системами. Но обучение от противного — это, вероятно, плохая практика.

Весной прошлого года я сделал некоторую первую попытку немного систематизировать мой опыт в проектировании API для библиотек в виде мини-курса лекций. Это все еще не систематизированный подход, которого бы мне хотелось, но какой-то первый шаг к осмыслению проблемы.

Мы стараемся обсуждать вопросы, связанные с научным программированием (а также с наукой вообще и с программированием вообще) здесь. И любой вклад в коммуникацию будет полезен. Наука состоит не из ответов, а из вопросов, так что приходите со своими вопросами.