Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Заголовок неправильный. На Rust надо переписывать. /s
Особенно хорошо переписывать на раст с питона)
Обычно с питона переписывают сначала на go (и, собственно, для этого он и создавался)
А мы до сих пор на Фортране такое пишем. Как в старину учили, как отцы наши писали :D
Фортран кстати нормальный язык. У него по ABI совместимость с Си, поэтому если функции на Фортране работают - их не стоит трогать. Я в свое время выучил Фортран в 8 классе (1984), а потом, уже в Америке, в 1995 году видел продукт (Microtech XRAY, сейчас часть Siemens EDA) который автоматически сконвертирован с Фортрана на Си.
В эпоху АИ языки с автоматическим управлением памятью не нужны - в ОСРВ они недопустимы. С++ и быстрее и машино сгенеренный код безопасен. остается typscript и С++.
Не пишите приложухи для ОСРВ на пайтоне
Это вы зря. Образ мышления llm сделан с человеческого, и ошибки они могут делать точно такие же. Особенно если там нечто большее конструктора в начале и деструктор а в конце.
Это как с малыми детьми разговаривать.
Конечно, Лёшенька/Петенька/Серёженька. Конечно, ты прав. Возьми с полки пирожок и иди играться с ИИ. Не мешай взрослым разговаривать. Иди уже.
Самое неприятное, когда после такого будешь иметь дело с протекшими абстракциями. Когда вроде при взляде издалека все красиво и абстрагировано. Но выясняется, что вот тут надо сделать именно вот так, тут именно вот так (а не так как казалось бы нужно по абстракциям). Потому что под капотом находится "стройная система костылей и подпорок"...
Переписать только половину приложения, получив 2 полуработающих приложения? Нет.
Вероятно, более правильно было бы использовать паттерн миграции "strangler fig": новое приложение проксирует запросы к старому, постепенно заменяя его функции. Это классика для микросервисов, сгодится для CLI, но вот для GUI это труднореализуемо.
Для разработчика написание кода это способ, которым он познает мир. В желании переписать незнакомый проект на знакомый язык нет ни чего неожиданного. Практический аспект тут вторичен, а неудачный опыт не менее ценен, чем положительный результат.
Завидую белой завистью тем, кто способен писать экраны скриптов, использовать файловую систему для метапрограммирования и поддерживать кодогенерацию на десятки платформ без тестов.
Один в один всё равно не переписать. А как доказать, что ничего не сломалось?
Ну и смысл переписывания или рефакторинга в том что будущие изменения или исправления будут легче, а вероятность ошибок меньше. Но если продукт меняться не будет то и рефакторинг без толку
Как я понял там что-то типа фреймворка, где можно в папках создавать референсы на типовые скрипты в разных комбинациях, собирая нужный функционал. То есть речь шла про использование. В версии на питоне как будто проглядели ключевые абстракции, поэтому она получилась ещё более запутаной. Но могу ошибаться, сильно не вчитывался.
Особенно экстравагантное решение получается когда старый проект оборачивают в новый фреймворк на новом языке, не особо вдаваясь в то, что там под капотом. Чтобы исправить баг в таком решении разработчику теперь требуется знать два языка и два фрейморка. Дебажить такое - особый вид удовольствия. И таких решений в современном мире - чуть ли не каждое второе.
За примерами далеко ходить не надо. Linux Kernel с версии 7.0 теперь вполне официально подерживает код на Rust и этого кода уже там прилично понатыкано. Чтобы исправить баг, да или просто собрать бинарник, мне теперь требуется знать два языка, иметь два тулчейна и знать особенности каждого из них. Так и хочется высунуться в окно по пояс и выкрикнуть на всю округу: Торвальдс - ты п#$@рас! Только вот не услышет же. Да, я знаю, что пока что эта "фича" еще отключаема, но это совсем не на долго.
Что отдельный разработчик, что компания целиком - должны своей работой приносить ценность (value) в экономическом смысле. От этого и надо отталкиваться.
Круг пользователей софта сидит на 45 платах? Значит софт должен поддерживать все 45, и разработчики должны его отладить для всех случаев.
Вот эта вот рутинная работа как раз таки принесет экономический value. Когда любой пользователь с платой из списка поддерживаемых - просто без лишних заморочек запускает ваш софт, и он работает без проблем.
Вы по сути поработали для всех своих пользователей, чтобы им уже прыгать с бубном не приходилось, и не приходилось бы тратить своё время на это. За свои дела - вы получаете деньги.
В принципе LiteX на питоне по сути SoC из IP собирает под разные таргеты - так что пример успешного применения для близких задач есть, расширять питоновою инфрастуктуру будет попроще, чем набор bash скриптов.
LiteX не является заменой BGM (Basics-Graphics-Music). Он отображает пины платы на пины модуля (например для платы TangNano 9K) и позволяет строить SoC из компонент, но не делает по умолчанию одну параметризуемую юзерную конфигурацию, как это делает BGM (с LED, Switch, 7-segment, микрофоном, графическим дисплеем и звуковым выходом). Все такие конфигурации юзер на Litex-е должен строить сам. На питоне.
Переписать, но только на brainfuck. Все остальное от лукавого.
Здравствуйте, Юрий. Подскажите, пожалуйста, оптимально ли начинать изучение fpga с такой последовательности: цифровая схемотехника (Харрисы), цифровой синтез, школа синтеза цифровых схем?
Все три стоит изучать параллельно. Читать вперемешку Харрисов и Синтез и закреплять лекциями Школы и упражнениями с FPGA платами.
До начала Школы Синтеза в октябре стоит пробежать глазами по главам 1-3 Харрисов и внимательно прочитать главу 4 Харрисов (верилог), тогда лекции Школы будут хорошо усваиваться.
И параллельно главы по комбинационной и последовательностной логике Цифрового Синтеза
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«А давайте перепишем все на питон!»