Alexey

В 1969 году NASA высадила людей на Луну, используя компьютер с примерно 4 килобайтами оперативной памяти и 72 килобайтами ПЗУ, который выполнял около 85 тысяч инструкций в секунду.
Этого «калькулятора» хватало, чтобы в реальном времени вести навигацию, управлять двигателями и не дать кораблю убиться об Луну.

В 80‑х я, вооружившись программируемым калькулятором МК‑61 с 105 шагами программы и 15 регистрами памяти, тоже «сажал» лунный модуль — и иногда даже успешно.
То есть бытовой калькулятор, живущий от трёх батареек и со скромным вакуумно‑люминесцентным дисплеем, позволял играть в те же сценарии, что когда‑то решались на бортовом компьютере «Аполло».

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

Да, железо подешевело, но по‑прежнему ли оно того стоит?

В какой момент мы свернули не туда?

От «железа на Луну» к «браузеру на всё»

Долгое время я был фанатом MacOS, начиная ещё с System 7.0, активно пользовался почти всеми версиями Windows, начиная с 3.0, и немало часов потратил на настройку удобного окружения в Linux.
За эти годы я наблюдал, как каждое новое поколение железа оказывалось быстрее лишь для того, чтобы интерфейс систем и приложений работал «как‑то так же, но с анимациями и телеметрией».

Бортовой компьютер «Аполло» был буквально соткан: код вшивался в так называемую core rope memory — провода протягивали через магнитные сердечники вручную, и изменение прошивки означало месяцы физического труда.
Сейчас мы перекатываем сотни мегабайт браузерного фронтенда в продакшен по несколько раз в день — и всё равно получаем интерфейсы, которые умудряются лагать при печати в текстовом поле.

Чем мы платим за удобство

Аргумент «железо дешёвое, можно не оптимизировать» звучит красиво только до тех пор, пока не начнёшь считать реальные издержки.
Каждый лишний гигабайт RAM — это не только стоимость планки, но и рост энергопотребления, тепла, шума кулера и утилизации всего этого хлама через пару лет.

В исследованиях по программной «раздутости» показывают, что устранение лишней функциональности и неоправданных накладных расходов может давать до 40% экономии энергии и заметный выигрыш в производительности на серверных приложениях.
То есть мы буквально сжигаем электричество в коде, который никому не нужен, — в лишних слоях абстракций, временных объектах и «на всякий случай» включённых фичах.

Когда на машине, которая по мощности превосходит лунный компьютер на порядки, браузер с тремя вкладками и мессенджером уже создаёт ощущение «чего‑то тормозит», становится немного стыдно за профессию.
Особенно если вспомнить, что тот самый лунный компьютер не имел вообще никакого графического интерфейса — только текстовый DSKY с «глаголами» и «существительными», и тем не менее делал свою работу лучше многих наших «удобных» интерфейсов.

Почему всё раздувается

Есть хорошее слово — software bloat: когда каждое новое поколение программы требует больше памяти, диска и CPU, а польза для пользователя растёт куда медленнее или почти не растёт вовсе.
Фичи прибывают, зависимости множатся, минимальные системные требования растут — и всё это ради пары косметических улучшений и очередной «интеграции с облаком».

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

К этому добавляются бизнес‑инцентивы: нужно быстрее выпускать фичи, собирать метрики, вшивать аналитику и «улучшать пользовательский опыт», который на практике часто превращается в прокрутку бесконечных скриптов и отслеживающих пикселей в фоне.
Реальная функциональность — та самая, ради которой пользователь вообще открыл программу, — по объёму зачастую меньше, чем обвязка вокруг неё.

Что можно сделать

Проблема не только техническая, но и культурная. Но именно поэтому у неё есть несколько вполне конкретных технических решений.

1. Перестать оправдывать раздутость

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

Исследования напрямую связывают программный bloat с потерей пропускной способности, перерасходом энергии и ростом системных bottleneck’ов.
Если мы считаем себя инженерами, а не только сборщиками фреймворков, мы обязаны помнить, что ресурсы конечны — даже если счёт за них пока приходит не лично нам.

2. Вводить «перформанс‑бюджет»

В вебе давно существует концепция performance budget — явные лимиты на вес страницы, размер JS‑бандла, время до интерактивности и т.д.
Если новый pull‑request выбивается из бюджета, его либо пересматривают, либо режут, либо не принимают вообще.

То же самое можно делать и за пределами веба:
ограничивать размер бинарников, время старта, потребление памяти в типичных сценариях и считать превышение не «побочным эффектом», а регрессией.
Performance перестаёт быть «побочным эффектом хорошего кода» и превращается в такую же целевую метрику, как аптайм или количество ошибок.

3. Деблоатинг и целевая оптимизация

Существует целое направление — software debloating: статический и динамический анализ, который находит и вырезает из приложения неиспользуемый код, мёртвые пути исполнения, лишние объекты.
Практика показывает, что даже в относительно аккуратных системах можно вырезать заметную долю функциональности и тем самым уменьшить размер, потребление памяти и атакующую поверхность.

Вместо тотального «оптимизируем всё» имеет смысл выбирать критические пути:
горячие циклы, частые запросы, UI‑операции, которые пользователь реально замечает.
Туда и направлять профилировщики, туда же — усилия по переписыванию на более эффективные решения.

4. Возвращаться к простым интерфейсам

Не все задачи требуют «богатого» GUI.
Большую часть повседневной работы — особенно разработческой и админской — прекрасно закрывают CLI и простые TUI‑интерфейсы.

Лунный компьютер управлялся через примитивный текстовый терминал, но его интерфейс был точен и предсказуем.
Современные CLI‑утилиты и минималистичные окружения (тот же CoreOS без GUI) дают те же преимущества: скорость, прозрачность, отсутствие лишнего визуального шума — и куда более скромные требования к железу.

Это не значит «отказаться от графики везде».
Но это значит честно задавать вопрос: «Здесь правда нужен ещё один Electron‑окно, или хватит нормальной консольной утилиты с хорошей документацией?»

5. Учить эффективности как части инженерии

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

Это можно и нужно менять:
включать профилирование, анализ bloat’а, работу с performance‑бюджетами в стандартный набор практик так же, как тестирование и code review.
Считать неоправданный bloat не «издержкой прогресса», а техническим долгом.

Я всё чаще думаю, что выход не только в более лёгких ОС и минималистичных интерфейсах, но и в возвращении к другим языковым идеям. К языкам, где выполнение программы остаётся понятным, где ошибка — это не магический прыжок через полстека, а явная часть модели. Поэтому мне всё ближе подходы, в которых меньше скрытых механизмов, меньше «умного» runtime и больше контроля со стороны программиста. Возможно, exceptions тоже пора отправить обратно в разряд аварийных инструментов, а не универсального способа управлять логикой программы.

Зачем всё это

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

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