За годы в разработке я всё чаще ловлю себя на мысли, что современные программы - словно построены из пластмассы: аккуратные, масштабируемые, но холодные. И когда я читаю старые исходники - с комментариями, с юмором, с уважением к читателю - понимаю: там был человек. Эта статья - не попытка идеализировать прошлое, а скорее разговор о том, почему код, написанный сорок лет назад, часто выглядит честнее и человечнее, чем многое из того, что мы создаём сегодня.

Когда код пах железом

Первый раз я увидел PDP-11 не в музее, а на складе старого НИИ. Она стояла под слоем пыли, с выпавшими переключателями, но внутри — идеально чистые платы, где каждая дорожка нарисована как вручную. Тогда я впервые понял, что когда-то инженер знал каждый байт своей машины, буквально.

Когда я разбирал старые исходники, то ощущение было странным: будто читаешь личные записи. Всё было просто, почти интимно)) Ни фреймворков, ни ORM, ни абстракций. Только человек и процессор.

Например, в коде на ассемблере PDP-11, который я когда-то переписывал ради эксперимента, всё дышало прямотой:

; Ввод символа и вывод обратно
MOV $3, R0          ; номер устройства (консоль)
JSR PC, GETCHAR     ; получить символ
MOVB R0, BUF        ; сохранить
JSR PC, PUTCHAR     ; вывести
HALT

Ни одной лишней строчки. Даже комментарии - короткие.
Когда работаешь с таким кодом, невозможно не уважать человека, который его писал. Он не прятался за слоями абстракций - он говорил с машиной на одном языке.

Когда комментарии были личными

Сейчас комментарии — редкость. А если они есть, то в духе // TODO: когда-нибудь переписать.
Но когда я впервые прочитал исходники на Fortran IV (нашёл их в архиве старой космической программы, если честно — случайно), то был поражён тем, насколько в них много… человечности.

C  ВЫЧИСЛЕНИЕ ОРБИТАЛЬНОЙ СКОРОСТИ
      V = DSQRT(G * M / R)
C  ЕСЛИ ТЫ ЧИТАЕШЬ ЭТО — ПРОВЕРЬ, НЕ ЗАБЫЛ ЛИ Я ПРО КИЛОМЕТРЫ
      IF (UNIT.EQ.'MILES') V = V * 1.60934
      PRINT *, 'ORBITAL VELOCITY =', V
      STOP
      END

Эта строка ЕСЛИ ТЫ ЧИТАЕШЬ ЭТО… меня зацепила. Человек писал не ради ревью, не ради KPI, а ради того, кто когда-нибудь откроет этот код и продолжит работу. В этом был какой-то теплый профессиональный этикет — уважение к следующему инженеру.

Сейчас у нас для этого есть issue-трекеры, документации, CI-логика. Но всё это мёртвое. А там — живая связь между людьми через код.

Когда оптимизация была делом чести

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

Помню, как читал исходники на С конца 70-х — и удивлялся, насколько аккуратно всё устроено. Каждый байт, каждый такт, всё под контролем.

int sum_array(int *arr, int n) {
    register int s = 0;
    while (--n >= 0)
        s += *arr++;
    return s;
}

Сегодня register ничего не даёт. А тогда — это был сигнал компилятору: "я знаю, что делаю".
Разработчик не надеялся на оптимизатор. Он думал, где переменная лежит, как устроен стек, что делает процессор.
Не из гордости — из необходимости. Это была настоящая инженерия, не программирование «на удачу».

Иногда я думаю, что вместе с потерей ограничений мы потеряли часть уважения к своей работе.

Когда код был лицом инженера

У каждого программиста был свой почерк. Настоящий, узнаваемый.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.

Это было как графика: чистая, искренняя, без шаблонов.

В одном проекте на Pascal я нашёл перед каждой подпрограммой ASCII-рамку из символов *. Просто украшение, но с какой любовью!
Код был не просто функциональным. Он выражал личность.

А теперь — линтер, форматер, CI, eslint, prettier… всё привели к общему знаменателю.
Да, стало чище. Но когда смотришь на старые исходники, где каждая строка — отпечаток автора, начинаешь скучать по временам, когда код ещё пах человеком, а не регламентом.

Когда разработчик чувствовал свою программу

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

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

Но именно это знание делало инженеров прошлого ближе к железу.
Когда ты понимаешь, что каждая переменная имеет вес — физически — ты начинаешь писать иначе. Бережнее. Честнее.

И, возможно, именно поэтому их код был человечным: в нём было уважение к машине, к читателю и к себе.

Заключение

Я не ностальгирую по перфокартам и не предлагаю писать на Fortran вместо Python.
Но иногда стоит вспомнить, что код — это не только синтаксис. Это форма общения между людьми, разделёнными временем.

Хочется, чтобы через 30 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы:
что здесь писал человек, не инструмент.

Комментарии (52)


  1. T700
    23.10.2025 13:11

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

    Были ли люди раньше более человечны?


    1. K0tm4n
      23.10.2025 13:11

      Более чем. В литературе разных времён хорошо отражено как менялся человек и нормы морали. Да и в кино заметны изменения. Сравните финалы оригинальных фильмов "Ограбление по-итальянски" и "11 друзей Оушена" с финалами римейков. Думаю ещё найдутся такие пары.


    1. zhuravlevanastia
      23.10.2025 13:11

      Творчество это именно пет-проекты и не более, потому что в бизнесовых задачах тебе особо никто и не даст эксперименты свои в жизнь воплощать, по-крайней мере по той причине, что есть сроки и базовые потребности клиентов, которые достаточно шаблонные


      1. T700
        23.10.2025 13:11

        А это интересная грань понимания. С одной стороны, сотрудник этовинтик, ведь он пишет на готовом фреймворке, где стиль уже определён, где за него всё сделали. Работа где ему ставят задачи и контролируют его код. Работа где нет творчество, есть пустая работа.

        Другая позиция, когда разработчик, сам строит архитектуру проекта, выбирает компоненты системы. Создаёт её сам, в том числе и дизайн и функционал админ панелей. Где он решает бизнес задачи. Это другая грань. Творческий подход имеет место быть.

        Пет проект, в большинстве случаев, не про бизнес.


    1. Lizdroz
      23.10.2025 13:11

      Дело не столько в хайпе, сколько в специализации. Раньше программист был человек-оркестр, сейчас есть фронтендер, бэкендер, девопс, QA... Каждый работает в своем узком коридоре, по своим стандартам. Места для личного почерка просто не остается, потому что твой код должен быть понятен десятку других специалистов


    1. Moog_Prodigy
      23.10.2025 13:11

      Я могу привести свой пример, в 2011 году я писал свою систему учета домашних финансов на VB. Но она настолько прозрачно показала траты семьи, что и я и жена решили что ну его нафиг. Потому что у всех есть свои небольшие слабости) Но это ладно. Меня впечатляет - то как я это сделал тогда. Я писал на VB, с DB Acsess , и там все настолько вылизано что спустя время я не знаю что добавить. Я бы сказал, что это писал совсем другой чел, если бы у меня не остались бумажки про архитектуру этой штуки. И вот... Кем был я тогда в то время, когда это все разрисовал, закодил? Сам собой? А сейчас я кто? Смотрю на это как полный бездарь на произведение гения, и такое странное ощущение. Отупел? Вроде нет, даже много больше стал знать и уметь. Но такой код я уже хрен бы написал. Старею или просто сам себя лишний раз критикую?


      1. T700
        23.10.2025 13:11

        Я сохраняю свой код в бекап, и часто также думаю, что как круто все сделано, неужели это делал я. Этот эффект, когда с прошествием времени, ты забываешь весь тот контекст в котором создавал программу, и когда смотришь снова на прошлый код, у тебя появляется страх, из-за того что ты забыл контекст, код и как ты это делал. Тема сложная на, самом деле. Есть состояние потока, это когда ты работаешь без времени, полностью в процессе, когда мозг оперирует огромными объемами информации. Поток, это не, всё, откуда он, если ясно что мозг не может по физическим каналам, передавать такие обьемы информации в голове, есть дугой принцип передачи. Если смотреть ещё глубже, станет ясно, что мы обращаемя к информации, куда-то в другое место, и получаем ответы и видения процесса, образа своих шагов (далее вопрос, открыт, куда и как (есть эксперимент, с лягушками, в полностью закрытом металлическом резервуаре и немного открытом)).


  1. usiqwerty
    23.10.2025 13:11

    Хочется, чтобы через 30 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы: что здесь писал человек, не инструмент.

    Сколько там процентов AI кода в гугле?


  1. Huchlers
    23.10.2025 13:11

    Думал, что аналогия с пластмассой будет о том, что они ломаются под нагрузкой, а тут опять луддитские тейки про "душу".


    1. Lizdroz
      23.10.2025 13:11

      Ну, аналогия с пластмассой тут как раз к месту. Современный софт собирается из готовых "пластмассовых" компонентов (библиотек, фреймворков) - это быстро, дешево, масштабируемо. Но когда что-то ломается внутри такого компонента, починить это почти невозможно - ты просто меняешь "деталь" целиком. А раньше, когда все было "из железа", ты мог починить что угодно, потому что сам это сделал


  1. Keeper22
    23.10.2025 13:11

    Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.


    1. T700
      23.10.2025 13:11

      Посмотрел. И странно, нет пробелов операторов в if, for и т. д. Это плохо и странно для меня. I don't know, так делать.


      1. ef_end_y
        23.10.2025 13:11

        Чем плохо?


        1. Rive
          23.10.2025 13:11

          Символы считываются медленнее, если не выглядят знакомо.


          1. ef_end_y
            23.10.2025 13:11

            Наоборот. Пример:

            print( ... )
            func( ... )

            Но почему

            if (...)
            for (...)


            1. TeaDove
              23.10.2025 13:11

              Потому что первое - вызов функции, а второе - управление потоком


        1. T700
          23.10.2025 13:11

          В целом это жесть. Всё слиплось воедино. Нет культуры написания кода. Там где необходимы пробелы их нет. Код поход на "индус код". Короче я был удивлен когда открыл случайный файл с котом на Си.


    1. cher-nov
      23.10.2025 13:11

      Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.

      У SQLite ещё и очень интересный этический кодекс: https://sqlite.org/codeofethics.html. Без него, боюсь, впечатление может оказаться несколько неполным. :)


  1. PereslavlFoto
    23.10.2025 13:11

    через 30 лет кто-то, открыв наши исходники

    Это запрещено авторским правом.


    1. ArtyomOchkin
      23.10.2025 13:11

      Значит, через 70 лет :).

      Если к тому времени исходники ещё будут лежать где-то в цифровых архивах


    1. MainEditor0
      23.10.2025 13:11

      Наши исходники только на небесах


    1. shurutov
      23.10.2025 13:11

      Open source? Не, нет такого...


      1. PereslavlFoto
        23.10.2025 13:11

        Open source

        Open source бывает не через тридцать лет, а сейчас. Поэтому здесь речь не про open source.


  1. smart_pic
    23.10.2025 13:11

    Когда код был лицом инженера

    У каждого программиста был свой почерк. Настоящий, узнаваемый.
    Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.

    Когда писал программы на ПЛ1 для ЕС1035 , то операторы по одному виду листинга программы определяли кто автор.

    Я не ностальгирую по перфокартам

    Но согласитесь в них что то есть. Когда сидишь и набираешь программу на перфокарты на перфораторе. а потом проверяешь правильность набора . перенабиваешь заново ошибочные строки , и только потом отдаешь колоду карт на исполнение.


    1. saag
      23.10.2025 13:11

      отдаешь колоду карт на исполнение

      Какие там девушки-операторы были, с одной по имени Аэлита я работал:-)


      1. Di-den
        23.10.2025 13:11

        Закладки из перфокарт (отец был динозавром СУБД на ЕС ЭВМ) до сих пор встречаю в книгах, перекочевавших из его библиотеки... Сам застав понятия "машинное время" и "пакетное выполнение" вспоминаю, что тоже когда-то умел писать код на несколько сотен строк без копипастов, автоподстановок и синтаксического контроля без единой ошибки. И да, оставлял комментарии. Я не любитель рассматривать старые фотографии (у меня даже детские видео сына-уже-студента ещё лежат на MiniDV кассетах в коробке), но знаю, где лежит моя коробка с дискетами 5.25" Dyson (да пребудет с ними сила).Пожалуй пойду в выходные присмотрю на барахолке антикварный Пентиум с флоппи-дисководом.


        1. Hrodvitnir
          23.10.2025 13:11

          Обожаю я вот это мужицкое "серьезно фоткаюсь с семьей" и "я самый счастливый мужик в мире, я поймал карася"

          Ваш комментарий мне прям вот это напомнил


        1. MkIV007
          23.10.2025 13:11

          Ну не знаю, цепляться за прошлое - нафиг нужно то? Были и у меня дискеты 5.25 и даже одна 8 дюймовая. Продал на ибее, как и все старье. А древние глюкавые машины (ЕС, СМ и прочая) без дрожи вспоминать не хочу.


    1. Yak52
      23.10.2025 13:11

      Я как то раз свой недельный труд в виде почти полтыщи перфокарт понес из перфораторской на машину. По пути споткнулся и вся стопка рассыпалась по полу коридора. Поскольку я их не пронумеровал, да и перфоратор был самый простой, он только дырки пробивал, а не печатал на перфокарте дополнительно текст, то еще день потратил на приведение всей колоды в правильный порядок. Даже с распечаткой.


    1. Frogy_F
      23.10.2025 13:11

      Вот если бы в наса, космическую программу по полёту на луну, сохранили бы на перфокартах, она бы не потерялась. А то эти ваши новомодные дискеты, ищи их теперь.


      1. Hemml
        23.10.2025 13:11

        хахаха, так они были не на дискетах и даже, существенная часть, не на перфокартах, а в виде таких здоровенных косиц проводов с вплетенными в них ферритовыми кольцами:


  1. kneaded
    23.10.2025 13:11

    Я сам и раньше и сейчас пытаюсь поддерживать человечность. Помню как кто-то открыл мой код, а там "если не пришла жёлтая курица - то ничего страшного" и всё было понятно. Логика такая, что можно не бояться, что какие-то данные не пришли. Оно дальше как надо отработает. Но было весело это спустя время услышать что вот, мой код прочитали и эта строчка их зацепила


  1. Sirion
    23.10.2025 13:11

    Не надо пах железом...


  1. VADemon
    23.10.2025 13:11

    «Сколько тактов займёт эта операция?» — и получаю в ответ улыбку.

    А можно, нахмурившись, про спекулятивное исполнение вне очереди на конвеере пофантазировать, инженер точных наук мой. (:

    Я думаю, раньше программирование было в меньшей мере поставлено на поток как сегодня. Т.е. провожу параллель вплоть до конвееризации и разделения труда. Ядро Линукс выхолощено до максимума. Старые комментарии делали "шаги в сторону", сейчас вряд ли факи в комментариях пропустят? (делаю предположение на основе их уменьшающегося числа в коде). А где есть лишнее время, там работается легче и человечней. Был code owner, не только как ревьювер, а вообще единоличный автор всей или части программы.

    Для меня человечность ныне измеряется в удобстве пользования и документации. Комментарии по-прежнему пишу мало (т.е. современное мышление), но из-за подобных статей иногда задумываюсь. А выражаю человечность через stdout. Можно сухо "Invalid input". Но почему бы машине не "разговаривать" с пользователем? "Did you forget XY?". "I can't bind to the configured port, maybe because ..." и т.п.


  1. GidraVydra
    23.10.2025 13:11

    Я сейчас вспоминаю расчетные программы 80х, написанные на Коболе, Фортране и Паскале настоящими инженерами, и у меня волосы на жопе шевелятся. Такого зубодробительно нечитаемого и неосмыслимого кода большинство ныне живущих и не видело. Если говорить про "человечность", то этот код был больше похож на некроморфов из DS.

    З.Ы. Погромисты, перестаньте называть себя инженерами.


    1. PereslavlFoto
      23.10.2025 13:11

      Там были непонятные имена переменных? И не было циклов?

      Пожалуйста, подробности. Что такое нечитаемое было на фортране-то?


  1. Hlad
    23.10.2025 13:11

    PDP-11 это хорошо. Могу привести пример с MSP430, который вроде на неё похож. Было первое семейство MSP-шек. Там всё просто и понятно. Было второе - практически то же самое. И было пятое. В котором надо было напихать множество функционала так, чтобы сохранить совместимость с предыдущими семействами. Поэтому новый функционал был, как бы это сказать, вставлен перректально. Нет, там не костыли, просто по сравнению с первыми семействами всё было устроено заметно сложнее и неудобнее. А потом я полез в ARM-ы. Там тоже аналогичная ситуация: в Cortex-M0...M3 всё просто и понятно. А когда пытаешься на низком уровне разобраться, как работает USB на каком-нибудь Cortex A53, становится неудобно сидеть, потому что волосы на седалище начинают шевелиться.

    Современный хард слишком сложен, чтобы под него можно было писать простой и понятный софт.


  1. Aggle
    23.10.2025 13:11

    Поддерживаю двумя руками. Касательно почерка (хотя и не про чисто программирование):
    В своё время, при пусконаладке одного из наших объектов, по-быстрому сваял расчётную схему процесса в excel. Разрисована схема процесса, все операции, стрелочки, кружочки, таблички с параметрами, все дела. Вбиваешь нужные исходные данные - рассчитываются показатели процесса. Прошло 15 лет, многое поменялось (из показателей), и вот, в очередной раз решили что-то изменить. Присылают мне на почту файлик, - посмотри, мол, так сможем нормально работать? И я вижу, что файлик-то мой, тот самый (почерк в таких делах уже тогда был выработан - имена, обозначение операций, форматы стрелок, ячеек, цветовые схемы и т. п.). Звоню на производство кому-то из "старичков":
    - Пацаны, это что, тот самый файл, который я вам тогда на пусконаладке рисовал?
    - Ну да.
    - Так это 15 лет назад было!
    - А что, там всё красиво, удобно, понятно - мы постоянно пользуемся, нафига чего-то менять?
    Честно скажу, было приятно от того, что когда-то сделал полезную для людей вещь, которой до сих пор пользуются и менять не хотят.

    Ну и на днях прислали для анализа производственной статистки сводку с предприятия, которым я очень давно не занимался. Открываю - очень знакомая. Смотрю, кто автор - а это я эту форму делал 11 лет назад.


  1. Panzerschrek
    23.10.2025 13:11

    Комментарии в каждой строчке были необходимостью, ибо без них чёрт ногу сломит. Писали ведь на ассемблере или чём-то другом, не очень высокоуровневом. Сейчас же абстракции современных языков программирования позволяют показывать намерения программиста средствами самого языка, так что комментарии редко нужны.


    1. Hlad
      23.10.2025 13:11

      Нет, по крайней мере, в низкоуровневой разработке. Средства языка позволяют показать, что мы делаем. И возможно, даже зачем мы делаем. Но не позволяют показать, почему мы делаем именно так.

      Условно говоря: по коду можно понять, что "вот тут - пауза в 100 мсек". Если писали качественно, то можно даже понять, что "мы ждём инициализации узла XXX". Но нельзя понять, что "при включении устройства надо проводить инициализацию узлов A, B и C последовательно, хотя они друг с другом никак не связаны, либо выждать паузу. Потому что если мы их врубим сразу - то у нас при подсевшей батарейке просядет питание, и устройство может уйти в перезагрузку".


    1. 5Coins
      23.10.2025 13:11

      С языка снял! Мы писали комментарии, превращая машинный код в алгоритм, описанный человеческим языком. Код легко читался, пока ты его помнишь и пока ты в нем варишься — я про ассемблер. «Прочитать» забытый код — это исполнить его в голове. Одна строчка когда сегодня — это (условно) могло занять несколько экранов на TASM. Без реперных точек в виде комментариев было просто невозможно работать. Ладно ещё написать, но поддерживать-тот иначе как!


  1. sepulkary
    23.10.2025 13:11

    Все эти милые кусочки программ на ассемблере хороши и ламповы, когда рассматриваешь их изолированно, с подробным комментарием и в ностальгическом контексте. А вот когда пытаешься пытаешься написать на ассемблере относительно сложную, контролируемую и сопровождаемую систему, то литературного слога очень скоро начинает не хватать...


    1. Aggle
      23.10.2025 13:11

      Словарь ограничивается mov, call, int ?


  1. user-book
    23.10.2025 13:11

    за комментарии могу ответить

    лично для себя всегда все комментирую "на лету" что бы потом когда вернусь было проще разбираться

    но по работе пишу без коментариев, максимум формальные к методам. Очень часто сначала пишется и отлаживается кусок "для себя", а затем он вычесывается, сливается в один коммит и уже так пушится в работу

    просто потому что командная работа. Это себе я могу написать "ебаный пиздец но оно работает, не лезть!" или "скопипащенно из решения http://..., вроде работает но надо погонять". Для публики или в команде это нормальная вежливость, как не присоединятся на видеосозвон в одних трусах. Вот только вычитка всех коментариев это время и силы, потому для економии я просто их удаляю. Для вещей которые еще не закончены, развожу по разным веткам для удобства.


  1. iiwabor
    23.10.2025 13:11

    Я однажды, в пятилетней давности коде, наткнулся на комментарий с дружеским приветствием и сочувствием от автора к тому, кто будет в его коде разбираться через года. Улыбнуло)


  1. ALexKud
    23.10.2025 13:11

    Система разработанная мною в в 2001 г. на SQL SERVER и DELPHI для одного дилера и содержащая CRM для менеджеров ,ЗАКАЗЫ,Снабжение,Отгрузки, Склад , хранилище документов в SQL Server и имеющая по тому времени много таких иновационных вещей как вычисляемые складские остатки , изменение приоритеов заказов с учетом скадских запасов и оплат и учетом частичных отгрузок , автоформирование спецификаций для комплектации заказов для снабжения , формирование счетов предложений и счетов на оплату, счетов фактур и накладных, импорт документов 1С бухгалтерию и т п. Система прожила 10 лет без особых проблем в связи с тем что логика все была в хранимых процедурах на сервере и клиент на DELPHI . Но к тому времени и контора стала хиреть и разваливаться, вернее стали разваливать, так как функцию дойной коровы она выполнила. Недавно посмотрел свой SQL код . В общем все неплохо выглядит, а прошло больше 20 лет.


  1. event1
    23.10.2025 13:11

    Сегодня register ничего не даёт. А тогда — это был сигнал компилятору: "я знаю, что делаю".
    Разработчик не надеялся на оптимизатор. Он думал, где переменная лежит, как устроен стек, что делает процессор.
    Не из гордости — из необходимости. Это была настоящая инженерия, не программирование «на удачу».

    Сегодня компилятор лучше вас знает, что надо делать. Требования выравнивания, иерархия кэшей, предсказание ветвления и тому подобное зашито в компилятор добрыми разработчиками процессора. Раньше не было ни таких навороченных процессоров, ни таких мощных компиляторов.

    Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.

    Спасибо, не надо. Пусть лучше весь проект будет в одном стиле, чем кто-то сможет определить автора

    А там — живая связь между людьми через код.

    О, да. Когда-то переписывал на сях код эквалайзера с DSP ассемблера с комментариями на немецком. Такая живая связь была, до сих пор побаливает.

    А вот ещё другой случай: взяли на поддержку код на джаве от японской компании с комментами на японском. Почему-то японская компания не сумела в utf-8 и кодировка была какая-то японская. Коллега открыл код в редакторе, после чего ХР упала и подняться не смогла. Пришлось переустанавливать. В общем, ну её нафиг эту вашу живую связь.


  1. Lizdroz
    23.10.2025 13:11

    Все это очень мило, но автор упускает из виду масштаб. Код для PDP-11, который управляет одним устройством, и код современного веб-сервиса, который обслуживает миллионы пользователей - это задачи разного порядка сложности. Абстракции, фреймворки, линтеры - не от хорошей жизни, это инструменты, которые позволяют десяткам и сотням разработчиков не поубивать друг друга и хоть как-то поддерживать огромные кодовые базы. Человечность принесена в жертву масштабируемости


    1. victor_1212
      23.10.2025 13:11

      масштаб это конечно дорого, но он был так примерно с середины 50х, когда в одном проекте уже участвовали не одна сотня программистов, системы реального времени sage и др.


  1. cdriper
    23.10.2025 13:11

    да, да, давайте ностальгировать по тупым копиляторам Си, которым надо было указывать какую локальную переменную стоит в регистр засунуть

    и вообще, давайте писать на одном ассемблеер ради совсем уж полной "человечности"


  1. Zotann
    23.10.2025 13:11

    Верх идиотизма писать комментарий к каждой строчке кода. Код должен быть понятен и читаем без комментариев (если это не касается супе сложной бизнесс логики) Т.е. мне как программисту нужно дважды читать одно и тоже : 1) сперва строку кода 2) потом строку комментария. Ведь и так понятно a = a + b что это сложение двух переменных. Зачем подобное комментировать?

    Зачем разработчику знать про такты? Что они решают, когда современные процессоры,ОЗУ, диски имеют несколько уровней кэшей и в миллиард раз быстрее оптимизируют циклы, условия и от посчитанного количества тактов ничего не останется потому что cpu умеет предсказывать результат или поместит в кэш часть функций и будет их использовать.

    Не нравится фреймворк - пиши в блокнотике. Да и вообще можно ручкой в тетраде писать код. Но насколько это эффективно?

    Зачем в примерах используется сортировка? В любом современном языке все сортировки уже давным давно реализованы наилучшими способами - вызывай нужный метод и наслаждайся.

    Сиди прокалывай дырочки в перфокартах и чувствуй себя инженером без инструментов мучающимся с сортировками массивах , а я буду наслаждаться автоматически генеративных кодом и творить мегаархиважные оптимизированные системы за считанные минуты.

    Ну вот как часто кому-либо приходится оптимизировать сортировки? Есть sql, есть spark и другие инструменты где все это оптимизировано и реализовано. Зачем придумывать велосипед? Я не спорю что это нужно и важно , но менее чем в 5% случаев требуется самостоятельно реализовать собственный алгоритм поиска максимума, сортировки и т.п. Надо понимать что такое алгоритмическое программирование ,но если в твоей специализации или текущем месте работы оно не нужно то зачем его использовать?

    Да, если разработка ПО ускорится в десятки раз от того что я куплю железяку на 128ГБ (256, 512) ОЗУ и забуду обо всех проблемах - то я ее куплю и буду наслаждаться и использовать везде Int32, а не мучаться с Int16 гонять байтики туда сюда , писать собственные оптимтзаторы и ради чего ? Чтобы сэкономить 2байта? Ну не смешите.

    Автор предлагает деградировать и переместиться во время 640кб? Вернуться к дискетам?

    Зачем столько раз повторять "душа" и "душевный"?


  1. spbrus
    23.10.2025 13:11

    Я сегодня резал овощи просто ножом. Обычным бездушным массовым продуктом. А ведь раньше были ножи с душой. Хороший нож месяцами затачивается и полировался, наносился декор вручную. Вот бы все ножи были такими, чтобы через 30 лет все резали овощи ножами в которые вложена душа мастера. Это краткий пересказ статьи в лёгкой интерпретации, если кто не понял )))