Skip Navigation
79 символов: архаизм или инженерный дзен?



79 символов: архаизм или инженерный дзен?

Каждый, кто хоть раз видел, как линтер (или коллега с синдромом вахтёра) подсвечивает красным 80-й символ, задавался вопросом: мы до сих пор живём в 1970-х?

Спойлер: отчасти да.

👻 Призраки прошлого
Перфокарты IBM на 80 колонок — это "легаси" в самом чистом виде. Мы давно не пробиваем дырки в картоне, но наши инструменты до сих пор живут в рамках этих ограничений. Это тот случай, когда форма определила содержание на десятилетия вперёд.

🛠 Почему это всё ещё актуально:

1. Side-by-side diffs. Когда вы открываете два файла в IDE рядом (или в GitHub/GitLab), узкие строки позволяют видеть код без постоянного скролла влево-вправо. Если у вас "портянка" на 200 символов, то уже неудобно.
2. Когнитивная нагрузка. Узкие блоки кода читаются быстрее. Глаз меньше скачет по строке. Внимательный разраб заметит баг быстрее, если код не "размазан" по ширине вашего 32-дюймового монитора.

В реальности всё прагматичнее:
🔵Если вы используете Black (а вы должны его использовать), он по умолчанию ставит 88. Это золотая середина между "классикой" и реальностью современных мониторов.
🔵Если вы работаете в команде, где в конфигах flake8 прописано 120 символов — окей, ставьте 120. Главное — чтобы это было единообразно.

В общем, не фанатейте от 79 символов ради самих 79 символов. Но и не пишите колбасы на полтора экрана. Хороший код должен быть читаемым, а не длинным.

#так_сложилось

Telegram
Как астрономы чуть не раскололи Python, а один разработчик всех спас 🔭


Как астрономы чуть не раскололи Python, а один разработчик всех спас 🔭

Сейчас вы пишете import numpy as np на автомате, даже не задумываясь, что за этой строчкой стоит опенсорс-драма, которая могла похоронить Питон как язык для Data Science еще в зародыше. Если бы в начале нулевых всё пошло по другому сценарию, сегодня мы бы грустно ворочали тензоры в R или мучились с плюсами.

В 1995 году Джим Хагунин написал Numeric — первый вменяемый C-экстеншн для работы с многомерными массивами. До него Python в математике был просто медленным скриптовым языком.

Но Numeric отвратительно справлялся с большими файлами. Это стало критичной проблемой для разработчиков, которым нужно было процессить гигантские снимки с «Хаббла». Ребята не стали контрибьютить в Numeric, а написали свой инструмент — Numarray. Он круто работал с гигантскими объемами данных телескопа, но безбожно сливал по производительности на мелких массивах.

⛓️‍💥 Итог: классический опенсорсный раскол экосистемы. Часть пакетов жестко зависела от Numeric, часть — от Numarray. Скрестить их в одном пайплайне было настоящим инженерным адом, так как их API были несовместимы.
В 2005 году Трэвис Олифант посмотрел на это болото и... сел и практически в одиночку переписал ядро, жестко скрещивая производительность Numeric с гибкими фичами Numarray.

Так появился NumPy.

Ради этого релиза Трэвис забил на написание научных статей, что в итоге стоило ему академической карьеры и постоянной должности профессора. Университетская бюрократия не оценила открытый исходный код. Но без этого не было бы Pandas, который Уэс Маккинни напишет позже поверх NumPy. Не было бы современного бума машинного обучения, PyTorch и TensorFlow, которые идеологически выросли из тех самых N-мерных массивов.
Да что там, первая в истории фотография черной дыры тоже собиралась скриптами, завязанными на этот стек.

#так_сложилось