Разработчики любят спорить о языках программирования и инструментах. Если опустить типичные претензии, обычно все сводится к тому, что люди просто защищают свой выбор. Это проявление тенденции оправдывать и защищать свои инвестиции - время потраченное на изучение используемых языка и инструментов. И в этом есть смысл. Но не всегда это поведение является рациональным.
(оригинал)
Эта запись, в основном, посвящена инструментам для таких платформ, как Zephyr (west) и ESP-IDF (idf.py). Но большинство замечаний справедливы и для многих других одноразовых и специальных инструментов.
Вложенные инвестиции
В отличие от того что нам порой говорят или продают, для уверенного владения языком программирования требуются годы. Обычно мне требуется 3-4 года применения языка программирования, прежде чем смогу сказать, что я знаю этот язык. Некоторым людям, вероятно, нужно меньше времени чтобы достичь того же уровня. Как бы то ни было, изучение языка программирования требует значительных затрат вашего личного времени.
И поскольку изучение языка программирования это затратно, весьма ожидаемо, что люди подсознательно стремятся защитить свой выбор. Если вы потратили 4-5 лет на язык X, потребуется немало времени чтобы убедить вас переключиться на язык Y. В такой ситуации легко стать жертвой заблуждения - соглашаясь, обесцениваю свои инвестиции.
Модные языки
Сегодня многие люди изучают Python. Python очень моден и часто можно услышать, что если вы изучите Python, вам будет легко найти работу. Вероятно, так оно и есть. Python предлагает низкий порог входа, богатый набор достойных библиотек для всего, от веб-программирования до машинного обучения, и не строгий язык, который позволит вам расслабиться и не задумываться о типах перемнных и многом другом. Или, если быть более точным: Python - язык, который позволяет вам быть чуть неряшливым.
Два с половиной десятилетия назад существовал язык, игравший аналогичную роль. Perl был Python своего времени. Какое-то время, большая часть интернет-индустрии работала на Perl. Для многих, Perl был предпочитаемым языком для веб-программирования и системного администрирования. Вы бы встретили много программистов Perl в таких местах, как финансовый сектор или развед. службы. Места, где у людей было много данных для обработки и анализа.
Если не обращать внимание на косметические различия, Perl мало чем отличался от Python с точки зрения практики разработки программного обеспечения. Он позволял быстро писать неряшливый код, и у него было масса плюсов для быстрого создания решений.
Perl и Python имеют одни и те же проблемы. Наиболее очевидным является то, что ни один из них не является компилируемым языком и не имеет статической типизации. Это не имеет большого значения, когда вы быстро склеиваете прототип, но становится серьезной проблемой, когда проект начинает расти в сложности, охватываемая аудитория увеличивается и люди начинают зависеть от вашего кода. Поддержка кода без помощи компилятора и отсутствие простого способа распространения программного решения имеют высокую цену при растущих масштабах.
Конечно, вы можете попытаться компенсировать это, написав тесты которые попытаются покрыть то, что вам дали бы статическая типизация и компилятор, но это скорее принятие желаемого за действительное. Признайтесь: вы не будете настолько скрупулезны. В противном случае, вероятно, вы бы изначально не стали использовать динамический язык.
Антисоциальное поведение
Этот параграф может спровоцировать разработчиков на Python, но Python — антисоциальный язык. Он фокусируется в первую очередь на потребностях разработчика, а не на пользователях программного обеспечения. Это, не очень красиво.. и если честно, то даже весьма высокомерно.
Вполне нормально чувствовать несогласие с подобными высказываниями. Как указывалось ранее: вы, вероятно, потратили много времени на Python. Вы будете склонны оправдывать и защищать вложенные инвестиции. Призываю вас обдумать написанное и постараться подавить немедленное желание выразить несогласие. Постарайтесь взглянуть на это с другой стороны - ведь именно так многие пользователи воспринимают программное обеспечение написанное на Python.
Итак, что же я имею в виду, когда говорю, что Python антисоциален?
Если вы используете язык, который может выдавать бинарные файлы, задача по установке всех зависимостей с правильными версиями является одноразовой: это происходит во время сборки. Это не происходит каждый раз при запуске программы. Более того: этот процесс можно автоматизировать, чтобы результат можно было распространять. Вы можете создать статически связанный бинарный файл, который просто нужно скачать и поместить в соответствующее место.
Это должно быть задачей разработчиков программного обеспечения, а не пользователей.
Каждый раз, когда вы запускаете программу на Python, все зависимости должны присутствовать. Если один из них внезапно пропал, был обновлен или требуемая версия Python недоступна, ваша программа скорее всего не запустится. А что еще хуже, это может привести к неочевидным, на первый взгляд, последствиям и не очень внятным ошибкам.
Это случается нередко. На самом деле, каждый год мы теряем недели разработки из-за того, что программы на Python внезапно перестают работать. Каждое обновление в цепочке зависимостей любых из используемых нами инструментов, сопряжено со значительными рисками сломать нашу среду сборки. Нам приходится тратить время на починку нашего инструментария, прежде чем мы сможем вернуться к основным задачам. Если честно, все настолько плохо, что если я склонирую встраиваемый код через несколько недель после того как это было закоммичено, и попытаюсь собрать, вероятность того, что не соберется - примерно 50/50.
Многие встроенные зависимости неприемлемо хрупкие. Если вы профессиональный инженер-программист и вас это не беспокоит, вам, вероятно, следует пересмотреть свои стандарты качества. Воспроизводимость и повторяемость имеют огромное значение. Особенно, если вы считаете себя профессионалом.
Переосмысление инструментов
Понятно, что люди не особенно склонны отказываться от своего привычного языка программирования и не стремятся переписывать программное обеспечение, которое работает. Вы вложились в изучение языка, а затем в создание инструментов или приложений на этом языке. Это представляет собой инвестиции и часто значительные, невозвратные затраты. Начинать сначала, может показаться не очень привлекательным решением.
Но вам стоит рассмотреть этот вариант серьезней. Как вы хотите проводить время в долгосрочной перспективе? Хотите решать проблемы, возникшие из-за выбора Python? Выяснять, как заставить приложения на Python работать предсказуемо, надежно и без необходимости постоянных действий со стороны пользователя? Или все таки сосредоточиться на создании продукта?
Если вы используете Python сегодня, я думаю, что вы просто обязаны попробовать сделать несколько небольших проектов на языках, более подходящих для создания простых инструментов, которые работают независимо от того, как настроена ваша система. Начните с выбора современного компилируемого языка. Два отличных кандидата — Rust и Go. Но подойдет любой язык, который имеет статическую типизацию, достойную стандартную библиотеку и компилируется в (предпочтительно статически связанные) бинарные файлы.
В крайнем случае, даже Java представляет лучшую альтернативу, поскольку у вас есть возможность создавать файлы «jar», содержащие все зависимости. Не модный, но объективно куда менее хрупкий вариант.
Перепишите небольшое приложение или утилиту на один из таких языков. Возможно, придется сделать это пару раз: сначала просто повторить функционал, а затем посмотреть, есть ли более идиоматические способы структурирования кода. Основная цель – научиться создавать более качественные приложения и тулинг.
Когда вы начнете чувствовать себя более комфортно с любым языком, который вы выберете, начните думать о том, как вы можете создавать кодовые базы «двойного назначения»: постарайтесь структурировать любой код, который вы пишете, в виде библиотеки, которую можно использовать для создания новых инструментов, включающих эту функциональность. Попробуйте подумать о том, как вы можете повысить продуктивность других. (Если вы ищете варианты роста как программист, это именно то как это достигается: начните помогать другим разработчикам своим вкладом).
Заключительные мысли
Иметь сочувствие к своим пользователям - важно. Написание кода может быть очень эгоцентричным занятием, когда легко сосредоточиться только на своих собственных потребностях. Если другим людям сложно использовать ваши программы, то это ваша вина. Не говорите им, что они используют его неправильно. Не тратьте время на выдумывание причудливых способов справиться с вашим ненадежным кодом. Не ждите, что они спокойно воспримут, то что вы не хотите упрощать им жизнь.
И вы можете быть совершенно эгоистичным в том что: если вы создадите что-то, что сделает ваших пользователей счастливее, это хорошо отразится и на вас.
Я понимаю, что просить людей не использовать Python — это провокация. Но я говорю это не назло или чтобы кого-то обидеть. Я говорю это, потому что потратил слишком много недель на то, чтобы заставить плохо продуманные инструменты работать, я не увидел значительных улучшений за последние годы, и я думаю, что пришло время начать относиться к этому немного серьезней.
Автор: Artyom Sukharev
