Почти три года назад, когда я начал митапы Verilog Mettup в Hacker Dojo, на них пришел Владимир Чурюкин и когда посмотрел на мою инфраструктуру Basic‑Graphics‑Music, где баш‑скрипты по имени платы строят проект, сразу сказал «А давайте перепишем все на питон». И переписал! С оговоркой что это PoC, то бишь Proof of Concept, то есть он это проверил только на 5-ти платах, а не на всех 45-ти, как мой исходный репозиторий.
А теперь посмотрим что из этого получилось.
Так как я в это индустрии 40 лет и читал книжки Брукса и других еще когда ездил в трамвае в физматшколу и работал у мамы на работе на СМ-4, то я знаком с этой ситуацией более чем. Разработчик приходит в новый проект. Ковыряться в том что есть ему неинтересно, то что есть ему видится отвратительным, а аргументы, что существующее решение достаточно он отвергает. На предложение заняться новой фичей поверх существующей инфраструктуры он исчезает на некоторое время, а потом возвращается с «вот, смотрите, как нужно!» и показывает переписанную инфраструктуру.
Существующие люди на проекте на это смотрят, пару раз в это тыкают и говорят: «а вот оно не поддерживает это и это, а также вводит неудобство для пользователя вот тут и тут». Тут в воздухе повисает неудобное молчание, потому что становится непонятно что именно хочет новый человек:
Лично сесть и написать все фичи, а не только proof of concept.
Указать другим, что они должны остановить все свои проекты, срочно выучить новый язык и библиотеки и переписать весь проект под его руководством.
Уломать прользователей смириться, что отныне программа поддерживает не 45 плат, а только 5, а также теперь программа не умеет находить где установлены тулчейны, и их пользователь должен ручками ввести в YAML файл. А также пользователь должен сам отлаживать случаи когда не работает драйвер в Linux, потому что новая программа не сказала пользователю сделать update в /etc/udev. Или случаи когда macOS объявляет файл от FPGA вендора malware.
Уломать прользователей смириться с двумя несовместимыми системами вместо одной: для одних плат они пользуются первой, для других второй, причем новая инфраструктура не запоминает последней выбраной платы. Зато все на питоне.
Сразу скажу, что я в своей карьере видел все 4 сценария, причем и с одной, и с другой стороны.
Также интересно, что спор как правило ведется в двух плоскостях. Старый разработчик говорит что новый подход требует преобразования проприетарных форматов от нескольких вендоров и ad‑hoc файлов для мэппинга чего‑то в один формат, но при этом новая преобразовалка недостаточно умна чтобы например парсировать ifdef‑ы в преобразуемых файлах, а мануальное преобразование займет либо время, либо необходимость построчно проверять что там натворило AI с этими ifdef‑ами, что нудно и противно. И непонятно ради чего, так как существующая инфраструктура и так работает, а что под капотом пользователю наплевать.
Новый разработчик отметает это как несущественную деталь и вещает о важности абстракций. Я книжки про важность абстракций стал читать еще когда СССР правил Генсек Константин Устинович Черненко (да, в СССР переводили в издательстве Мир книжки по программированию в том числе на эти темы), поэтому для меня важность абстракций разбивается в один момент: кто должен править вывод программ, которая написана на абстракциях, но не обрабатывает все случаи для пользователя, которые обрабатывает старая программа — я или он?
А вы что думаете?
Комментарии (23)
hssergey
15.09.2026 16:36Самое неприятное, когда после такого будешь иметь дело с протекшими абстракциями. Когда вроде при взляде издалека все красиво и абстрагировано. Но выясняется, что вот тут надо сделать именно вот так, тут именно вот так (а не так как казалось бы нужно по абстракциям). Потому что под капотом находится "стройная система костылей и подпорок"...
Akon32
15.09.2026 16:36Переписать только половину приложения, получив 2 полуработающих приложения? Нет.
Вероятно, более правильно было бы использовать паттерн миграции "strangler fig": новое приложение проксирует запросы к старому, постепенно заменяя его функции. Это классика для микросервисов, сгодится для CLI, но вот для GUI это труднореализуемо.
funca
15.09.2026 16:36Для разработчика написание кода это способ, которым он познает мир. В желании переписать незнакомый проект на знакомый язык нет ни чего неожиданного. Практический аспект тут вторичен, а неудачный опыт не менее ценен, чем положительный результат.
Завидую белой завистью тем, кто способен писать экраны скриптов, использовать файловую систему для метапрограммирования и поддерживать кодогенерацию на десятки платформ без тестов.
Dhwtj
15.09.2026 16:36Один в один всё равно не переписать. А как доказать, что ничего не сломалось?
Ну и смысл переписывания или рефакторинга в том что будущие изменения или исправления будут легче, а вероятность ошибок меньше. Но если продукт меняться не будет то и рефакторинг без толку
funca
15.09.2026 16:36Как я понял там что-то типа фреймворка, где можно в папках создавать референсы на типовые скрипты в разных комбинациях, собирая нужный функционал. То есть речь шла про использование. В версии на питоне как будто проглядели ключевые абстракции, поэтому она получилась ещё более запутаной. Но могу ошибаться, сильно не вчитывался.
checkpoint
15.09.2026 16:36Особенно экстравагантное решение получается когда старый проект оборачивают в новый фреймворк на новом языке, не особо вдаваясь в то, что там под капотом. Чтобы исправить баг в таком решении разработчику теперь требуется знать два языка и два фрейморка. Дебажить такое - особый вид удовольствия. И таких решений в современном мире - чуть ли не каждое второе.
За примерами далеко ходить не надо. Linux Kernel с версии 7.0 теперь вполне официально подерживает код на Rust и этого кода уже там прилично понатыкано. Чтобы исправить баг, да или просто собрать бинарник, мне теперь требуется знать два языка, иметь два тулчейна и знать особенности каждого из них. Так и хочется высунуться в окно по пояс и выкрикнуть на всю округу: Торвальдс - ты п#$@рас! Только вот не услышет же. Да, я знаю, что пока что эта "фича" еще отключаема, но это совсем не на долго.
LiamBlue
15.09.2026 16:36Что отдельный разработчик, что компания целиком - должны своей работой приносить ценность (value) в экономическом смысле. От этого и надо отталкиваться.
Круг пользователей софта сидит на 45 платах? Значит софт должен поддерживать все 45, и разработчики должны его отладить для всех случаев.
Вот эта вот рутинная работа как раз таки принесет экономический value. Когда любой пользователь с платой из списка поддерживаемых - просто без лишних заморочек запускает ваш софт, и он работает без проблем.
Вы по сути поработали для всех своих пользователей, чтобы им уже прыгать с бубном не приходилось, и не приходилось бы тратить своё время на это. За свои дела - вы получаете деньги.
unreal_undead2
15.09.2026 16:36В принципе LiteX на питоне по сути SoC из IP собирает под разные таргеты - так что пример успешного применения для близких задач есть, расширять питоновою инфрастуктуру будет попроще, чем набор bash скриптов.
YuriPanchul Автор
15.09.2026 16:36LiteX не является заменой BGM (Basics-Graphics-Music). Он отображает пины платы на пины модуля (например для платы TangNano 9K) и позволяет строить SoC из компонент, но не делает по умолчанию одну параметризуемую юзерную конфигурацию, как это делает BGM (с LED, Switch, 7-segment, микрофоном, графическим дисплеем и звуковым выходом). Все такие конфигурации юзер на Litex-е должен строить сам. На питоне.
unreal_undead2
15.09.2026 16:36Я же написал "близких задач", понятно что это другое, но в смежной области.
KuznetsoV1
15.09.2026 16:36Здравствуйте, Юрий. Подскажите, пожалуйста, оптимально ли начинать изучение fpga с такой последовательности: цифровая схемотехника (Харрисы), цифровой синтез, школа синтеза цифровых схем?
YuriPanchul Автор
15.09.2026 16:36Все три стоит изучать параллельно. Читать вперемешку Харрисов и Синтез и закреплять лекциями Школы и упражнениями с FPGA платами.
До начала Школы Синтеза в октябре стоит пробежать глазами по главам 1-3 Харрисов и внимательно прочитать главу 4 Харрисов (верилог), тогда лекции Школы будут хорошо усваиваться.И параллельно главы по комбинационной и последовательностной логике Цифрового Синтеза
Dovgaluk
Заголовок неправильный. На Rust надо переписывать. /s
Akon32
Особенно хорошо переписывать на раст с питона)
allter
Обычно с питона переписывают сначала на go (и, собственно, для этого он и создавался)
InsiderCrush
А мы до сих пор на Фортране такое пишем. Как в старину учили, как отцы наши писали :D
YuriPanchul Автор
Фортран кстати нормальный язык. У него по ABI совместимость с Си, поэтому если функции на Фортране работают - их не стоит трогать. Я в свое время выучил Фортран в 8 классе (1984), а потом, уже в Америке, в 1995 году видел продукт (Microtech XRAY, сейчас часть Siemens EDA) который автоматически сконвертирован с Фортрана на Си.
envionx
В эпоху АИ языки с автоматическим управлением памятью не нужны - в ОСРВ они недопустимы. С++ и быстрее и машино сгенеренный код безопасен. остается typscript и С++.
netricks
Не пишите приложухи для ОСРВ на пайтоне
kuza2000
Это вы зря. Образ мышления llm сделан с человеческого, и ошибки они могут делать точно такие же. Особенно если там нечто большее конструктора в начале и деструктор а в конце.
EgorSharin
Это как с малыми детьми разговаривать.
Конечно, Лёшенька/Петенька/Серёженька. Конечно, ты прав. Возьми с полки пирожок и иди играться с ИИ. Не мешай взрослым разговаривать. Иди уже.