За годы в разработке я всё чаще ловлю себя на мысли, что современные программы - словно построены из пластмассы: аккуратные, масштабируемые, но холодные. И когда я читаю старые исходники - с комментариями, с юмором, с уважением к читателю - понимаю: там был человек. Эта статья - не попытка идеализировать прошлое, а скорее разговор о том, почему код, написанный сорок лет назад, часто выглядит честнее и человечнее, чем многое из того, что мы создаём сегодня.
Когда код пах железом
Первый раз я увидел 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 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы:
что здесь писал человек, не инструмент.
Комментарии (59)
usiqwerty
23.10.2025 13:11Хочется, чтобы через 30 лет кто-то, открыв наши исходники, почувствовал то же самое, что чувствовал я, читая эти старые программы: что здесь писал человек, не инструмент.
Сколько там процентов AI кода в гугле?
Huchlers
23.10.2025 13:11Думал, что аналогия с пластмассой будет о том, что они ломаются под нагрузкой, а тут опять луддитские тейки про "душу".
Lizdroz
23.10.2025 13:11Ну, аналогия с пластмассой тут как раз к месту. Современный софт собирается из готовых "пластмассовых" компонентов (библиотек, фреймворков) - это быстро, дешево, масштабируемо. Но когда что-то ломается внутри такого компонента, починить это почти невозможно - ты просто меняешь "деталь" целиком. А раньше, когда все было "из железа", ты мог починить что угодно, потому что сам это сделал
Keeper22
23.10.2025 13:11Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.
T700
23.10.2025 13:11Посмотрел. И странно, нет пробелов операторов в if, for и т. д. Это плохо и странно для меня. I don't know, так делать.
cher-nov
23.10.2025 13:11Один из лучший примеров кода, с которым мне довелось поработать -- библиотека SQLite. Желающие могут причаститься.
У SQLite ещё и очень интересный этический кодекс: https://sqlite.org/codeofethics.html. Без него, боюсь, впечатление может оказаться несколько неполным. :)
PereslavlFoto
23.10.2025 13:11через 30 лет кто-то, открыв наши исходники
Это запрещено авторским правом.
ArtyomOchkin
23.10.2025 13:11Значит, через 70 лет :).
Если к тому времени исходники ещё будут лежать где-то в цифровых архивах
shurutov
23.10.2025 13:11Open source? Не, нет такого...
PereslavlFoto
23.10.2025 13:11Open source
Open source бывает не через тридцать лет, а сейчас. Поэтому здесь речь не про open source.
smart_pic
23.10.2025 13:11Когда код был лицом инженера
У каждого программиста был свой почерк. Настоящий, узнаваемый.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.Когда писал программы на ПЛ1 для ЕС1035 , то операторы по одному виду листинга программы определяли кто автор.
Я не ностальгирую по перфокартам
Но согласитесь в них что то есть. Когда сидишь и набираешь программу на перфокарты на перфораторе. а потом проверяешь правильность набора . перенабиваешь заново ошибочные строки , и только потом отдаешь колоду карт на исполнение.
saag
23.10.2025 13:11отдаешь колоду карт на исполнение
Какие там девушки-операторы были, с одной по имени Аэлита я работал:-)
Di-den
23.10.2025 13:11Закладки из перфокарт (отец был динозавром СУБД на ЕС ЭВМ) до сих пор встречаю в книгах, перекочевавших из его библиотеки... Сам застав понятия "машинное время" и "пакетное выполнение" вспоминаю, что тоже когда-то умел писать код на несколько сотен строк без копипастов, автоподстановок и синтаксического контроля без единой ошибки. И да, оставлял комментарии. Я не любитель рассматривать старые фотографии (у меня даже детские видео сына-уже-студента ещё лежат на MiniDV кассетах в коробке), но знаю, где лежит моя коробка с дискетами 5.25" Dyson (да пребудет с ними сила).Пожалуй пойду в выходные присмотрю на барахолке антикварный Пентиум с флоппи-дисководом.
Hrodvitnir
23.10.2025 13:11Обожаю я вот это мужицкое "серьезно фоткаюсь с семьей" и "я самый счастливый мужик в мире, я поймал карася"
Ваш комментарий мне прям вот это напомнил
MkIV007
23.10.2025 13:11Ну не знаю, цепляться за прошлое - нафиг нужно то? Были и у меня дискеты 5.25 и даже одна 8 дюймовая. Продал на ибее, как и все старье. А древние глюкавые машины (ЕС, СМ и прочая) без дрожи вспоминать не хочу.
Yak52
23.10.2025 13:11Я как то раз свой недельный труд в виде почти полтыщи перфокарт понес из перфораторской на машину. По пути споткнулся и вся стопка рассыпалась по полу коридора. Поскольку я их не пронумеровал, да и перфоратор был самый простой, он только дырки пробивал, а не печатал на перфокарте дополнительно текст, то еще день потратил на приведение всей колоды в правильный порядок. Даже с распечаткой.
Frogy_F
23.10.2025 13:11Вот если бы в наса, космическую программу по полёту на луну, сохранили бы на перфокартах, она бы не потерялась. А то эти ваши новомодные дискеты, ищи их теперь.
Hemml
23.10.2025 13:11хахаха, так они были не на дискетах и даже, существенная часть, не на перфокартах, а в виде таких здоровенных косиц проводов с вплетенными в них ферритовыми кольцами:
kneaded
23.10.2025 13:11Я сам и раньше и сейчас пытаюсь поддерживать человечность. Помню как кто-то открыл мой код, а там "если не пришла жёлтая курица - то ничего страшного" и всё было понятно. Логика такая, что можно не бояться, что какие-то данные не пришли. Оно дальше как надо отработает. Но было весело это спустя время услышать что вот, мой код прочитали и эта строчка их зацепила
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 ..." и т.п.
GidraVydra
23.10.2025 13:11Я сейчас вспоминаю расчетные программы 80х, написанные на Коболе, Фортране и Паскале настоящими инженерами, и у меня волосы на жопе шевелятся. Такого зубодробительно нечитаемого и неосмыслимого кода большинство ныне живущих и не видело. Если говорить про "человечность", то этот код был больше похож на некроморфов из DS.
З.Ы. Погромисты, перестаньте называть себя инженерами.
PereslavlFoto
23.10.2025 13:11Там были непонятные имена переменных? И не было циклов?
Пожалуйста, подробности. Что такое нечитаемое было на фортране-то?
Hlad
23.10.2025 13:11PDP-11 это хорошо. Могу привести пример с MSP430, который вроде на неё похож. Было первое семейство MSP-шек. Там всё просто и понятно. Было второе - практически то же самое. И было пятое. В котором надо было напихать множество функционала так, чтобы сохранить совместимость с предыдущими семействами. Поэтому новый функционал был, как бы это сказать, вставлен перректально. Нет, там не костыли, просто по сравнению с первыми семействами всё было устроено заметно сложнее и неудобнее. А потом я полез в ARM-ы. Там тоже аналогичная ситуация: в Cortex-M0...M3 всё просто и понятно. А когда пытаешься на низком уровне разобраться, как работает USB на каком-нибудь Cortex A53, становится неудобно сидеть, потому что волосы на седалище начинают шевелиться.
Современный хард слишком сложен, чтобы под него можно было писать простой и понятный софт.
Aggle
23.10.2025 13:11Поддерживаю двумя руками. Касательно почерка (хотя и не про чисто программирование):
В своё время, при пусконаладке одного из наших объектов, по-быстрому сваял расчётную схему процесса в excel. Разрисована схема процесса, все операции, стрелочки, кружочки, таблички с параметрами, все дела. Вбиваешь нужные исходные данные - рассчитываются показатели процесса. Прошло 15 лет, многое поменялось (из показателей), и вот, в очередной раз решили что-то изменить. Присылают мне на почту файлик, - посмотри, мол, так сможем нормально работать? И я вижу, что файлик-то мой, тот самый (почерк в таких делах уже тогда был выработан - имена, обозначение операций, форматы стрелок, ячеек, цветовые схемы и т. п.). Звоню на производство кому-то из "старичков":
- Пацаны, это что, тот самый файл, который я вам тогда на пусконаладке рисовал?
- Ну да.
- Так это 15 лет назад было!
- А что, там всё красиво, удобно, понятно - мы постоянно пользуемся, нафига чего-то менять?
Честно скажу, было приятно от того, что когда-то сделал полезную для людей вещь, которой до сих пор пользуются и менять не хотят.Ну и на днях прислали для анализа производственной статистки сводку с предприятия, которым я очень давно не занимался. Открываю - очень знакомая. Смотрю, кто автор - а это я эту форму делал 11 лет назад.
Panzerschrek
23.10.2025 13:11Комментарии в каждой строчке были необходимостью, ибо без них чёрт ногу сломит. Писали ведь на ассемблере или чём-то другом, не очень высокоуровневом. Сейчас же абстракции современных языков программирования позволяют показывать намерения программиста средствами самого языка, так что комментарии редко нужны.
Hlad
23.10.2025 13:11Нет, по крайней мере, в низкоуровневой разработке. Средства языка позволяют показать, что мы делаем. И возможно, даже зачем мы делаем. Но не позволяют показать, почему мы делаем именно так.
Условно говоря: по коду можно понять, что "вот тут - пауза в 100 мсек". Если писали качественно, то можно даже понять, что "мы ждём инициализации узла XXX". Но нельзя понять, что "при включении устройства надо проводить инициализацию узлов A, B и C последовательно, хотя они друг с другом никак не связаны, либо выждать паузу. Потому что если мы их врубим сразу - то у нас при подсевшей батарейке просядет питание, и устройство может уйти в перезагрузку".
5Coins
23.10.2025 13:11С языка снял! Мы писали комментарии, превращая машинный код в алгоритм, описанный человеческим языком. Код легко читался, пока ты его помнишь и пока ты в нем варишься — я про ассемблер. «Прочитать» забытый код — это исполнить его в голове. Одна строчка когда сегодня — это (условно) могло занять несколько экранов на TASM. Без реперных точек в виде комментариев было просто невозможно работать. Ладно ещё написать, но поддерживать-тот иначе как!
sepulkary
23.10.2025 13:11Все эти милые кусочки программ на ассемблере хороши и ламповы, когда рассматриваешь их изолированно, с подробным комментарием и в ностальгическом контексте. А вот когда пытаешься пытаешься написать на ассемблере относительно сложную, контролируемую и сопровождаемую систему, то литературного слога очень скоро начинает не хватать...
user-book
23.10.2025 13:11за комментарии могу ответить
лично для себя всегда все комментирую "на лету" что бы потом когда вернусь было проще разбираться
но по работе пишу без коментариев, максимум формальные к методам. Очень часто сначала пишется и отлаживается кусок "для себя", а затем он вычесывается, сливается в один коммит и уже так пушится в работу
просто потому что командная работа. Это себе я могу написать "ебаный пиздец но оно работает, не лезть!" или "скопипащенно из решения http://..., вроде работает но надо погонять". Для публики или в команде это нормальная вежливость, как не присоединятся на видеосозвон в одних трусах. Вот только вычитка всех коментариев это время и силы, потому для економии я просто их удаляю. Для вещей которые еще не закончены, развожу по разным веткам для удобства.
iiwabor
23.10.2025 13:11Я однажды, в пятилетней давности коде, наткнулся на комментарий с дружеским приветствием и сочувствием от автора к тому, кто будет в его коде разбираться через года. Улыбнуло)
ALexKud
23.10.2025 13:11Система разработанная мною в в 2001 г. на SQL SERVER и DELPHI для одного дилера и содержащая CRM для менеджеров ,ЗАКАЗЫ,Снабжение,Отгрузки, Склад , хранилище документов в SQL Server и имеющая по тому времени много таких иновационных вещей как вычисляемые складские остатки , изменение приоритеов заказов с учетом скадских запасов и оплат и учетом частичных отгрузок , автоформирование спецификаций для комплектации заказов для снабжения , формирование счетов предложений и счетов на оплату, счетов фактур и накладных, импорт документов 1С бухгалтерию и т п. Система прожила 10 лет без особых проблем в связи с тем что логика все была в хранимых процедурах на сервере и клиент на DELPHI . Но к тому времени и контора стала хиреть и разваливаться, вернее стали разваливать, так как функцию дойной коровы она выполнила. Недавно посмотрел свой SQL код . В общем все неплохо выглядит, а прошло больше 20 лет.
event1
23.10.2025 13:11Сегодня register ничего не даёт. А тогда — это был сигнал компилятору: "я знаю, что делаю".
Разработчик не надеялся на оптимизатор. Он думал, где переменная лежит, как устроен стек, что делает процессор.
Не из гордости — из необходимости. Это была настоящая инженерия, не программирование «на удачу».Сегодня компилятор лучше вас знает, что надо делать. Требования выравнивания, иерархия кэшей, предсказание ветвления и тому подобное зашито в компилятор добрыми разработчиками процессора. Раньше не было ни таких навороченных процессоров, ни таких мощных компиляторов.
Я видел проекты, где можно было определить автора по тому, как он выстраивает отступы, как ставит комментарии, как называет переменные.
Спасибо, не надо. Пусть лучше весь проект будет в одном стиле, чем кто-то сможет определить автора
А там — живая связь между людьми через код.
О, да. Когда-то переписывал на сях код эквалайзера с DSP ассемблера с комментариями на немецком. Такая живая связь была, до сих пор побаливает.
А вот ещё другой случай: взяли на поддержку код на джаве от японской компании с комментами на японском. Почему-то японская компания не сумела в utf-8 и кодировка была какая-то японская. Коллега открыл код в редакторе, после чего ХР упала и подняться не смогла. Пришлось переустанавливать. В общем, ну её нафиг эту вашу живую связь.
Lizdroz
23.10.2025 13:11Все это очень мило, но автор упускает из виду масштаб. Код для PDP-11, который управляет одним устройством, и код современного веб-сервиса, который обслуживает миллионы пользователей - это задачи разного порядка сложности. Абстракции, фреймворки, линтеры - не от хорошей жизни, это инструменты, которые позволяют десяткам и сотням разработчиков не поубивать друг друга и хоть как-то поддерживать огромные кодовые базы. Человечность принесена в жертву масштабируемости
victor_1212
23.10.2025 13:11масштаб это конечно дорого, но он был так примерно с середины 50х, когда в одном проекте уже участвовали не одна сотня программистов, системы реального времени sage и др.
cdriper
23.10.2025 13:11да, да, давайте ностальгировать по тупым копиляторам Си, которым надо было указывать какую локальную переменную стоит в регистр засунуть
и вообще, давайте писать на одном ассемблеер ради совсем уж полной "человечности"
Zotann
23.10.2025 13:11Верх идиотизма писать комментарий к каждой строчке кода. Код должен быть понятен и читаем без комментариев (если это не касается супе сложной бизнесс логики) Т.е. мне как программисту нужно дважды читать одно и тоже : 1) сперва строку кода 2) потом строку комментария. Ведь и так понятно a = a + b что это сложение двух переменных. Зачем подобное комментировать?
Зачем разработчику знать про такты? Что они решают, когда современные процессоры,ОЗУ, диски имеют несколько уровней кэшей и в миллиард раз быстрее оптимизируют циклы, условия и от посчитанного количества тактов ничего не останется потому что cpu умеет предсказывать результат или поместит в кэш часть функций и будет их использовать.
Не нравится фреймворк - пиши в блокнотике. Да и вообще можно ручкой в тетраде писать код. Но насколько это эффективно?
Зачем в примерах используется сортировка? В любом современном языке все сортировки уже давным давно реализованы наилучшими способами - вызывай нужный метод и наслаждайся.
Сиди прокалывай дырочки в перфокартах и чувствуй себя инженером без инструментов мучающимся с сортировками массивах , а я буду наслаждаться автоматически генеративных кодом и творить мегаархиважные оптимизированные системы за считанные минуты.
Ну вот как часто кому-либо приходится оптимизировать сортировки? Есть sql, есть spark и другие инструменты где все это оптимизировано и реализовано. Зачем придумывать велосипед? Я не спорю что это нужно и важно , но менее чем в 5% случаев требуется самостоятельно реализовать собственный алгоритм поиска максимума, сортировки и т.п. Надо понимать что такое алгоритмическое программирование ,но если в твоей специализации или текущем месте работы оно не нужно то зачем его использовать?
Да, если разработка ПО ускорится в десятки раз от того что я куплю железяку на 128ГБ (256, 512) ОЗУ и забуду обо всех проблемах - то я ее куплю и буду наслаждаться и использовать везде Int32, а не мучаться с Int16 гонять байтики туда сюда , писать собственные оптимтзаторы и ради чего ? Чтобы сэкономить 2байта? Ну не смешите.
Автор предлагает деградировать и переместиться во время 640кб? Вернуться к дискетам?
Зачем столько раз повторять "душа" и "душевный"?
spbrus
23.10.2025 13:11Я сегодня резал овощи просто ножом. Обычным бездушным массовым продуктом. А ведь раньше были ножи с душой. Хороший нож месяцами затачивается и полировался, наносился декор вручную. Вот бы все ножи были такими, чтобы через 30 лет все резали овощи ножами в которые вложена душа мастера. Это краткий пересказ статьи в лёгкой интерпретации, если кто не понял )))
gres_84
23.10.2025 13:11Конечно, у каждого свой опыт, но я работал в военке с инженерами прошлого. И код, который они писали (а некоторые до сих пор пишут), никто не мог поддерживать. Бывали случаи, когда они сами не могли поддерживать свой "человечный" код. И даже случаи, когда принималось решение полностью переписать большой кусок кода, потому что поддерживать и модернизировать его стало невыносимо сложно.
PereslavlFoto
23.10.2025 13:11сами не могли поддерживать
Что именно мешало? В чём были проблемы?
Спасибо.
gres_84
23.10.2025 13:11Основная, на мой взгляд, проблема указана в заголовке статьи - эти люди прежде всего инженеры, а не программисты.
Код рабочий, эффективный, местами даже красивый. Но о его поддержке особо не задумывались - функции на несколько сотен строк, однобуквенные переменный, побитовые трюки, куча глобальных переменных, магические константы и т.д. Как результат, код тяжело читать и в какой-то момент любая правка в одном месте ломает что-то в другом, код становится хрупким.
Расскажу историю из своего опыта. Переписывали кусок такого кода. Обнаружили функцию, которая переставляет местами две строки в распечатке результата. Стали разбираться, что за магия. Оказалось, автору было проще переставить итоговые строки, чем искать в собственном коде место, почему результаты оказались не на своем месте.
Другой пример - функция с шестью goto. Маленкькая, компактная, переписанный вариант был в 2.5 раза больше. Зато править его было в разы легче.
PereslavlFoto
23.10.2025 13:11Спасибо!
Похоже, что авторы таких программ стояли перед выбором. Или программа, которая будет понятной и которую легко поддерживать. Или программа, которая выполнится сегодня и результат расчётов можно получить уже к вечеру. В этих условиях они старались уменьшить машинное время.
victor_1212
23.10.2025 13:11вероятно не стоит обобщать, для больших систем код писали качественно, включая документацию, вплоть до разработки отдельных стандартов специально под проект, бывало что наиболее важные компоненты делали разные команды, дублирование со сравнением результатов, все зависит от области применения
T700
Возможно раньше программировали по призванию, а сегодня на волне хайпа, программируют ради денег, плюс требования рынка, фреймворки и стандарты, в которых есть рамки фрейворков, оформление кода и комментариев. Творчество возможно, есть в пет проектах, и даже в них, код для себя и код для публикации, отличаются по оформлению.
Были ли люди раньше более человечны?
K0tm4n
Более чем. В литературе разных времён хорошо отражено как менялся человек и нормы морали. Да и в кино заметны изменения. Сравните финалы оригинальных фильмов "Ограбление по-итальянски" и "11 друзей Оушена" с финалами римейков. Думаю ещё найдутся такие пары.
zhuravlevanastia
Творчество это именно пет-проекты и не более, потому что в бизнесовых задачах тебе особо никто и не даст эксперименты свои в жизнь воплощать, по-крайней мере по той причине, что есть сроки и базовые потребности клиентов, которые достаточно шаблонные
T700
А это интересная грань понимания. С одной стороны, сотрудник этовинтик, ведь он пишет на готовом фреймворке, где стиль уже определён, где за него всё сделали. Работа где ему ставят задачи и контролируют его код. Работа где нет творчество, есть пустая работа.
Другая позиция, когда разработчик, сам строит архитектуру проекта, выбирает компоненты системы. Создаёт её сам, в том числе и дизайн и функционал админ панелей. Где он решает бизнес задачи. Это другая грань. Творческий подход имеет место быть.
Пет проект, в большинстве случаев, не про бизнес.
Lizdroz
Дело не столько в хайпе, сколько в специализации. Раньше программист был человек-оркестр, сейчас есть фронтендер, бэкендер, девопс, QA... Каждый работает в своем узком коридоре, по своим стандартам. Места для личного почерка просто не остается, потому что твой код должен быть понятен десятку других специалистов
Moog_Prodigy
Я могу привести свой пример, в 2011 году я писал свою систему учета домашних финансов на VB. Но она настолько прозрачно показала траты семьи, что и я и жена решили что ну его нафиг. Потому что у всех есть свои небольшие слабости) Но это ладно. Меня впечатляет - то как я это сделал тогда. Я писал на VB, с DB Acsess , и там все настолько вылизано что спустя время я не знаю что добавить. Я бы сказал, что это писал совсем другой чел, если бы у меня не остались бумажки про архитектуру этой штуки. И вот... Кем был я тогда в то время, когда это все разрисовал, закодил? Сам собой? А сейчас я кто? Смотрю на это как полный бездарь на произведение гения, и такое странное ощущение. Отупел? Вроде нет, даже много больше стал знать и уметь. Но такой код я уже хрен бы написал. Старею или просто сам себя лишний раз критикую?
T700
Я сохраняю свой код в бекап, и часто также думаю, что как круто все сделано, неужели это делал я. Этот эффект, когда с прошествием времени, ты забываешь весь тот контекст в котором создавал программу, и когда смотришь снова на прошлый код, у тебя появляется страх, из-за того что ты забыл контекст, код и как ты это делал. Тема сложная на, самом деле. Есть состояние потока, это когда ты работаешь без времени, полностью в процессе, когда мозг оперирует огромными объемами информации. Поток, это не, всё, откуда он, если ясно что мозг не может по физическим каналам, передавать такие обьемы информации в голове, есть дугой принцип передачи. Если смотреть ещё глубже, станет ясно, что мы обращаемя к информации, куда-то в другое место, и получаем ответы и видения процесса, образа своих шагов (далее вопрос, открыт, куда и как (есть эксперимент, с лягушками, в полностью закрытом металлическом резервуаре и немного открытом)).
Moog_Prodigy
Может быть в изоляции все дело. Когда я ту штуку делал, у меня была почти полная изоляция от остального мира. Именно когда писал, а не вообще. Сейчас такого нет. Но можно сделать.