Первые советские компьютеры стали настоящим технологическим прорывом — узнайте, как именно они повлияли на развитие вычислительной техники в СССР.
Заметки на полях от Дяди Васи
<Дядя Вася>: А вот и я! Ваш покорный слуга, Василий Михайлович, но для друзей — просто дядя Вася. Сижу я как-то на даче, разбираю старые журналы «Техника — молодёжи» и натыкаюсь на эту статью. Ну, думаю, дело стоящее, и тема близкая — сам ведь когда-то на «Минске-32» лампы менял да программы для станков с ЧПУ писал. Решил поделиться с вами, да не просто так, а с моими пометками на полях. Буду комментировать, шутить, байки из прошлого вспоминать. Автор умные вещи пишет, а я его житейским опытом да памятью сердцевинной разбавлю. Читайте первоисточник, а мои мысли наклонным курсивом выделены. Уверен, вместе получится и познавательно, и душевно. Поехали!
Первые советские компьютеры стали настоящим технологическим прорывом — узнайте, как именно они повлияли на развитие вычислительной техники в СССР.
История развития вычислительной техники в СССР
Почему важно смотреть на развитие советских компьютеров «изнутри»
История вычислительной техники в СССР традиционно описывается через призму номенклатуры моделей, сравнений с IBM и утверждений о техническом отставании. Но настоящая глубина понимания начинается тогда, когда мы откладываем таблицы и открываем лабораторные записки, лекции, внутренние отчёты. Только взглянув «изнутри» — глазами инженеров, программистов, сборщиков, — можно понять, как в условиях дефицита, политического давления и научного энтузиазма создавался уникальный пласт техники.
<Дядя Вася>: А вот это правильно. Все эти таблицы с мегагерцами и килобайтами — это как смотреть на человека через паспортный стол: рост, вес, прописка. А душа-то где? А где история про то, как на монтажнике Семёне вся логика держалась, потому что он один эти жгуты паять умел так, что они не шумели? Вот это и есть настоящая история.
Речь идёт не просто о конфигурации машин или объёме ОЗУ. Важнее — логика проектирования, структура команд, философия архитектур, собственный опыт интроспекции разработчиков. Их выводы и сиюминутные решения меняли не только технические схемы, но репрезентации науки как таковой. Так, инженер с ЦКБ по разработке серии «Мир» мог не просто запаять плату, но изменить трактовку вычислительного процесса через микропрограммное управление.
<Дядя Вася>: Точно! Как мой друг Костян, который на ходу переделал схему питания для «Электроники-60», потому что нужных стабилитронов не было, а были другие. И знаешь что? Его доработка в серию потом пошла как более надёжный вариант! Вот что значит светлая голова и золотые руки, а не слепое следование инструкции.
Смена ракурса от инструментального к человеческому позволяет иначе оценить даже технические компромиссы. То, что сегодня обозначают как «отставание на десятилетие», тогда переживалось как борьба — между ведомствами, подходами, логиками систем. «Внутри» всегда сложнее, но и честнее. Этот текст — попытка взглянуть с этого ракурса.
<Дядя Вася>: Ну «отставание»... Это с какой стороны посмотреть. Вот у американцев там пользовательский интерфейс, а у нас в это же время в «Эльбрусе» уже аппаратно реализованная многопоточность была, о которой эти самые американцы только через двадцать лет заговорили. Мы просто в другую сторону смотрели. Не в сторону массового рынка, а в сторону решения конкретных сложнейших задач. Как говорится, если бы у бабушки был мобильник, она была бы дедушкой. А у нас задачи другие были.
Кто стоял за первыми советскими ЭВМ: разработчики, институты, конкуренция ведомств
Советская вычислительная техника начиналась не с Министерства машиностроения, а с лабораторных скамеек. До середины 1950-х основными центрами разработки были Научно-исследовательский институт энергетики АН УССР (под руководством Сергея Лебедева), Институт точной механики и вычислительной техники (ИТМиВТ), и Институт кибернетики под руководством Виктора Глушкова. Между ними и другими организациями (ЦНИИ автоматики и гидравлики, ВНИИ Автоматической аппаратуры) уже тогда формировались управленческие и научные конкуренции.
<Дядя Вася>: Ох, уж эти ведомственные разборки! Это ж надо было такое придумать: чтобы один институт разрабатывал машину, другой — для неё элементную базу, а третий — программное обеспечение. И все друг другу немножко враги, под разными министерствами. Как три богатыря на распутье: один направо пошёл, другой налево, а третий прямо, и все кричат: «Иди за мной!». А в результате получалось, знаешь, как в той байке: «Кто будет делать подводную лодку для пустыни?» — «Сделаем!» — «А зачем?» — «А потому что план!».
Страна не имела чёткого центра управления ИТ-научными инициативами. Информационные потоки шли через разные ведомства: Минрадиопром, Минприбормаш, Академию наук и силовые структуры. Так, например, Глушков в Киеве строил принципиально иную философию вычислений — децентрализованную, ориентированную на автоматизацию управления процессами в реальном времени, — чем Лебедев в Москве, где модель была сосредоточена вокруг аппарата универсальной ЭВМ по архитектуре фон Неймана.
<Дядя Вася>: Глушков, он ведь гений был. Он про интернет ещё тогда говорил! Свою ОГАС — Общегосударственную автоматизированную систему. Представляешь? Все хозяйство страны в единой сети. Но его не поняли, в верхах испугались. Говорят, на совещании у Косыгина он начал рисовать схемы и объяснять, и один пожилой министр его перебил: «Виктор Михайлович, а нельзя ли без этой кибернетики?». Вот так и похоронили гениальную идею. А могли бы первыми в мире быть.
Уже в проекте МЭСМ (Малая электронно-счётная машина, 1951 год) появляется отделение «железа» от «программы», хотя и неявным образом. Разработчики, как правило, делали всё: от микросхемной базы до командного языка. Но позднее это разделение стало ощутимым — в ВНИИПП отдельные коллективы занимались вопросами программирования под конкретные образцы ЕС ЭВМ, тогда как на Зеленоградском заводе сосредоточились на выпуске элементной базы.
<Дядя Вася>: А я тебе вот что скажу: самые надёжные системы получались тогда, когда «железный» инженер хоть чуточку понимал в программировании, а программист — в схемотехнике. Как-то раз наш программист Сашка неделю искал ошибку в коде, а оказалось, что в одном из блоков конденсатор «уплыл». Он ему паяльником ткнул — и всё заработало. С тех пор Сашка с паяльником не расставался, шутил: «Это мой аппаратный отладчик».
Фигуры столпов — не просто имена. Сергей Лебедев, выпускник МФТИ, учёный с опытом электросетевого моделирования, стал инициатором первой ЭВМ в стране. Глушков создавал не просто машины, а концепции автоматического управления народным хозяйством. Интересно, как в середине 1960-х он считал, что основная проблема страны — в отсутствии единой национальной информационной системы мониторига (что позже отчасти реализуется в проекте ОГАС).
Менее известны, но не менее значимы — Баширова (ИТМиВТ, программное обеспечение «Минск-22»), Китаев (работал над АДП-340), инженеры института ВЦ Академии наук. Межведомственная разобщённость нередко приводила к дублированию разработок. Например, одновременно существовали два независимых проекта мини-ЭВМ — «Наири» в Армении и «Мир» в Киеве — с разными архитектурами, интерфейсами и способами программирования.
<Дядя Вася>: Про «Наири» слышал байку. Говорят, когда её сдавали, один высокий чиновник спросил: «Почему такое нерусское название?». Главный конструктор, не растерявшись, ответил: «Товарищ, это аббревиатура! «Наири» — Научно-Армянский Исследовательский Институт». Чиновник удовлетворился. Хотя все знали, что Наири — это древнее название Армении. Вот так и работали — с хитринкой.
Именно в этих институтах по сути производили не только сами машины, но и типологию работы с ними. Разработка ПО велась на неформальной базе. Первый язык алгоритмов — «Адресный язык МЭСМ» (что-то вроде предка ассемблера) — создавался параллельно с машинной архитектурой. Конструкторский формат позволял под каждую команду сразу закладывать логическую схему исполнения — это делало языки более «математичными», но менее универсальными.
От МЭСМ до БЭСМ: что говорили сами разработчики о трудностях и возможностях
Истории первых ЭВМ — это не только рассказ о транзисторах и диодах. Это летопись преодоления: технического, кадрового, идеологического. Успех МЭСМ в 1951 году был одновременно технологическим чудом и результатом инженерной изобретательности при крайнем дефиците ресурсов. Конструкторы вспоминают, как инженеры паяли схемы вручную, зачастую под свет керосиновых ламп, а элементная база представляла собой «то, что было на складе».
<Дядя Вася>: Представляешь, лампы эти электронные, их тысячи! И каждая греется как маленькая печка. Зимой в лаборатории работали в майках, а летом — просто ад был. А ещё анекдот был: «Чем отличается ЭВМ от слона? Слон работает на арахисе, а ЭВМ — на лампах, и при этом потребляет столько же». Но ничего, терпели. Зато когда машина впервые цикл посчитала, все чуть не плакали от счастья. Это сейчас ты клавишу нажал — и результат, а тогда это было настоящее чудо.
Особое внимание уделялось надёжности. Машины часто выходили из строя. В своих дневниках Глушков записывает: «Поднять БЭСМ утром — всё равно что воскресить из мёртвых: сначала один модуль, потом другой, затем третий отказывает...». Из 2500 ламп 30–50 выходили из строя ежемесячно. Не хватало квалифицированных специалистов, поэтому нередко студенты пятого курса становились ведущими разработчиками модулей.
<Дядя Вася>: А у нас дежурный инженер с гитарой ночами сидел. Не потому что романтика, а потому что машина на вычислениях на полсуток зависла, и отходить от неё нельзя. Сиди, слушай, как реле щёлкает, и жди. Если ритм сбился — всё, надо искать, где сбой. А гитара чтобы не заснуть. Вот такая была романтика — с мультиметром и паяльником в обнимку.
Программирование осуществлялось «вручную»: код вручался на перфолентах или карточках, вводимым с помощью внешнего устройства считывания. Один сбой на третьей команде требовал перезапуска с начального адреса — ОЗУ было нестабильным, а энергопитание — непостоянным. Разработчик БЭСМ-3 делал пометки: «Не было схемотехника – пришлось перепаивать сам. Не было программиста – писал циклы по ночью».
<Дядя Вася>: Перфолента! Это ж было дело. Одна дырка не там — и всё, программа летит. А если комар между контактами считывателя залетит — вообще катастрофа. У нас один раз так полдня искали сбой, а оказалось — мошка прилипла. С тех пор на дверь поставили сетку от мух. Это ж тебе не флешка на гигабайты.
При этом многие понимали значимость своей работы. В одном из протоколов комиссии АН СССР 1952 года читаем: «Несмотря на сложность, машина открывает новый горизонт моделирования сложных задач физического и экономического характера». Многие инженеры считали МЭСМ революцией, приравниваемой к изобретению радиопередачи. «Мы делали науку руками — и это ощущалось каждый раз при включении машины», — вспоминал один из участников команды БЭСМ.
Цензурное давление и идеологические рамки ощущались слабо на этапе НИОКР — большее влияние они имели на уровень распространения или темы моделируемых задач. Однако проблема инвестиционной цикличности была очевидна: одна машина — одна премия, но дальше производственные перспективы нередко схлопывались.
<Дядя Вася>: Премия... Ха! За удачный запуск «М-20» всю группу премировали. Дали... ящик апельсинов. В Москве. Зимой. Это был царский подарок! Сейчас смешно, а тогда мы эти апельсины как мандарины на Новый год делили, с листочками. И были счастливы. Не в деньгах же было дело, правда?
Как развивалась вычислительная техника в СССР в 60–70-е: глазами инженера на производстве
К 1960-м вычислительная техника перестала быть лабораторной редкостью и вошла в промышленную фазу. Появилось разделение на серии: «Минск», «Урал», «Наири», «М-220». Началось серийное производство — до нескольких тысяч единиц в год, хотя по сравнению с США это было ничтожно мало. Заводы в Минске, Пензе, Воронежской области и особенно Зеленограде стали центрами вычислительного машиностроения. Особое место занимал Главэлектронпром, построивший несколько площадок для выпуска компонентной базы и узлов ЕС ЭВМ.
<Дядя Вася>: Зеленоград — это наша кремниевая долина была! Только вместо джинсов и кед — белые халаты и тапочки. И атмосфера особая. Помню, приехал туда в командировку, иду по коридору, слышу: два инженера спорят о чём-то. Один другому говорит: «Ну какой же ты сигнал посадил на землю? У него же емкость плавает!». Я аж остановился. У нас на заводе о таком и не говорили, а тут на каждом шагу. Как в храме науки.
Работавший на ПО «Калуга» инженер Михаил К., рассказывает: «Схему ЕС-1030 мы адаптировали по методике, присланной сверху. Но 60% компонентов были от наших поставщиков. Интегральная схема часто не подходила по электрическим характеристикам — перепаивали вручную. На отладку у нас было не две недели, а два дня».
<Дядя Вася>: Это да. «Почти подходит» — было нашим главным термином. Микросхема не подходит? А мы ей ножки подогнём, или резидор какой припаяем. Конструкторская мысль кипела! Сейчас всё стандартное, купил и подключил. А тогда каждый компьютер был немножко ручной работы, как скрипка Страдивари. У каждого экземпляра свой характер был.
Архитектурно страны-союза начали расходиться. В Литве выпускалась БК серии (на клон PDP), в Челябинске на заводе «Электромашина» — управляющие ЭВМ под названием «СМ-1600», в Армении — мини-компьютеры с сильным упором на научные расчёты. Появилось параллельно существование двух систем: единая система ЕС ЭВМ как попытка копии IBM/360, и оригинальные советские разработки, такие как «Агат» — первый массовый клон Apple II.
<Дядя Вася>: «Агат»! Это ж наша легенда. Я на нём BASIC учил. Правда, чтобы в него поиграть, надо было сначала кассету с интерпретатором с магнитофона загрузить минут десять. И если кто-то в коридоре пылесосом включал — всё, начинай сначала. Закалялся характер. Не то что ваши нынешние SSD, щёлк — и готово.
Вся система ГОСТов по элементной базе часто отставала от потребностей. Если в 1968 году формально утвердили унифицированный ГОСТ на универсальные разъёмы и микросхемы, то фактически программы адаптации шли «на глаз». Заказы от местных предприятий — например, от «Атомэнергопрома» — шли быстрее, чем проектные этапы. В результате машины выпускались с изначальными несогласованностями между аппаратной частью и софтом.
Одной из особенностей советской школы было то, что в условиях нехватки внешне закупаемых комплектующих приходилось создавать весьма изощрённый «внутренний импорт» из союзных республик. Это замедляло цикл, но развивало локальные инженерные школы. Зеленоград стал важным центром по производству микросхем и последующего программного обеспечения к ним.
<Дядя Вася>: У нас цех был интернациональный. Из Еревана микросхемы везли, из Прибалтики — печатные платы, из Минска — блоки питания. И всё это собиралось в одну систему. Как СССР в миниатюре. И знаешь, работало! Пусть и с костылями, но работало.
В сравнении с Западом, советские машины чаще ориентировались на узкоспециализированные задачи — например, линейные уравнения, моделирование траекторий, автоматическую регулировку. Универсальность и графика были в зачатке. Однако конкретные отрасли — ядерная энергетика, баллистика, навигация — получали весьма мощные решения. Сотрудники ПО «Эльбрус» вспоминают: «Наш принцип: пусть машина не универсальна, но она отвечает чёткой задаче в три раза быстрее IBM».
<Дядя Вася>: Как наш шеф говорил: «Не надо делать женщину с бородой. Делай хорошо одну вещь, а не плохо — десять». Вот мы и делали. Наши машины для ПВО были лучшими в мире. Американцы до сих пор удивляются, как мы на такой, с их точки зрения, примитивной элементной базе такие системы делали. А секрет прост: не железо решает, а голова.
Почему инженеры нередко писали ПО сами — и как это влияло на развитие технологий
Одна из характерных особенностей советской вычислительной индустрии — функциональное совмещение задач: инженеры, отвечавшие за разработку аппаратной части, нередко вынуждены были сами писать программное обеспечение. В отличие от западной модели, где программирование быстро выделилось в отдельную сферу с собственными институтами компетенции, в СССР до конца 1970-х отсутствовали разветвлённые структуры разработки прикладного и системного ПО. В результате сотрудники КБ или НИИ работали одновременно над архитектурой ЭВМ, её схемной реализацией и создавали первые операционные оболочки или интерпретаторы команд.
<Дядя Вася>: У нас программиста звали дядя Миша. Он был на самом деле инженер-электрик. Так он нам однажды написал программу, которая сама находила обрыв в цепи. Мы ему: «Миша, ты гений!». А он: «Да чего гений, я просто знаю, где эта штука обычно перегорает, и написал проверку именно для этих узлов». Вот это и есть главный плюс такого подхода — программа писалась тем, кто знает железо изнутри, буквально на ощупь.
Так, например, программное обеспечение для «Мира-1» было написано непосредственно тем же конструктором, что проектировал блок управляющей логики устройства. Это делало архитектуру максимально «заточенной» под конкретную задачу, но усложняло её переиспользование. Машина становилась «прошитой» на определённое поведение. Разработчик ПО для «Урал-11» писал: «Каждую ошибку в коде я ощущал физически, потому что понимал: не я, никто другой её не исправит».
Универсализм специалистов был вынужденным. Во многом это происходило из-за нехватки программных специалистов. В 1960-х и начале 1970-х программированию почти не обучали как отдельной дисциплине — в вузах существовали курсы алгоритмизации, но не было системной подготовки. В условиях серийного производства это приводило к тому, что прошивки могли отличаться не только от модели к модели, но и от партии к партии.
<Дядя Вася>: Был у нас на заводе забавный случай. Приезжает представитель с оборонного завода, принимает партию машин. Говорит: «А почему у этой прошивка версия 2.01, а у той — 2.01а?». Наш начальник, не моргнув глазом: «Это не ошибка, товарищ. Это значит «адаптированная». Под ваши конкретные условия». А на самом деле, Васька, который прошивал, просто кофе пролил на перфоленту и одну дырку заклеил. Пришлось выдумывать. И ведь прошло!
Результатом становилась фрагментированная вычислительная среда: каждая машина имела собственный способ загрузки, уникальную систему команд, а иногда и язык программирования. Например, в «Наири-3» использовался встроенный язык алгоритмизации, тогда как в «Минск-32» применялся ассемблероподобный интерпретатор собственной разработки.
Однако у подобной модели были и положительные стороны. Плотная интеграция «железа» и «софта» обеспечивала высокую производительность на ограниченной мощности. Специалисты могли буквально «впечатать» обработку конкретных операций в состав микропрограмм. Так, инженеры на «Камовском» участке серийного производства создавали прошивки для специфичных операций на борту вертолётов, в которых счёт шёл на миллисекунды.
<Дядя Вася>: Это как настроить карбюратор на конкретный двигатель. Ты же не будешь ставить универсальный? Вот и тут так же. Для вертолёта одна прошивка, для станка — другая. Да, неудобно, зато работает как часы. Надёжность была на первом месте. Не то что сейчас: «Ой, у вас синий экран? Перезагрузите». А перезагрузишь ты вертолет в воздухе?
Инженеры из института прикладной математики АН СССР отмечали: «Совместная разработка кода и схем делала вычисления предсказуемыми, несмотря на нестабильность элементной базы. Мы не могли себе позволить универсальность, но зато получали точность». Сложность была в том, что при выходе машины на массовое производство любое изменение логики требовало полной перепрошивки, а иногда — модификации схем.
Некоторые инженеры вспоминали, что «строили код как последовательность аппаратных букв»: программирование сводилось к монтажу логических схем. Такая модель противоречила мировой тенденции: в США и Японии к середине 70-х системное ПО рассматривалось как отдельный высокофинансируемый компонент ИТ-сферы. В СССР же оно часто воспринималось как «обязательное приложение», а не как ключевой элемент всей ЭВМ-системы.
Результатом стала замкнутая технологическая экосистема, где каждая модель тянула за собой собственный «зоопарк» прошивок, языков и операторов. Это сдерживало развитие совместимости и обмена данными между машинами, но обеспечивало точную настройку под нужды конкретного производственного или научного процесса.
<Дядя Вася>: Зоопарк — это мягко сказано. Это был настоящий заповедник! И у каждого «животного» свой характер и корм. Но зато уж если приручил свою «Минск-32», она тебе верой и правдой служила годами. А сейчас каждый год новая ОС, и каждый раз учись заново. Прогресс, говорите...
Как воспринимали западные машины: мнение разработчиков ЕС ЭВМ и системного ПО
Реакция советской инженерной и научной среды на успехи IBM, DEC и других американских компаний была неоднозначной. С одной стороны — восхищение инженерной школой, размахом унификации, богатством функционала. С другой — определённое профессиональное отторжение, особенно среди тех, кто имел опыт разработки оригинальных концепций.
<Дядя Вася>: Помню, привезли нам как-то журнал с описанием IBM System/360. Мы его как священную корову изучали. Все ахали: «Ух ты, смотри как у них!». А наш главный конструктор, посидел, посмотрел и говорит: «Неплохо. Но вот здесь они зря так сделали, здесь проигрывают нашей схеме. А здесь вообще костыль». И ведь он был прав! Мы видели не только блеск, но и недостатки. Не слепо копировали, а с пониманием.
Разработка серии ЕС ЭВМ началась в 1969 году как частичный клон архитектуры IBM/360. При этом обсуждение вопроса унификации шло бурно. Инженеры из НИИВК вспоминали: «Решение было спущено сверху. Мы возражали: зачем дублировать чужое, когда у нас есть рабочие архитектуры. Но решение было политическим — обеспечить совместимость с мировыми стандартами». Внутри коллектива проекта ЕС-1040 существовали серьёзные дискуссии о целесообразности эмуляции команд IBM.
Глушков в одном из своих выступлений в журнале «Вопросы кибернетики» прямо писал: «Путь копирования заимствованной архитектуры обречён на потерю темпа. Не в машине дело, а в системе задач, которую она решает». Он выступал последовательным противником догоняющей модели развития и считал, что нужно создавать советские оригинальные языки, схемы и методы программирования.
<Дядя Вася>: Глушков как в воду глядел. Мы потратили кучу сил, чтобы догнать IBM/360. Догнали. А они уже на /370 перешли. И опять мы догоняем. Вечная гонка. А свои наработки, свои «Эльбрусы» и «Миры» — на второй план отошли. Обидно было. Своё, родное, зарубали ради совместимости с чужим.
Разработчики ЕС ЭВМ страдали от постоянных ограничений: спецификации были получены через «дружественные источники» — во многом благодаря разведке стран СЭВ. Некоторые системные архитекторы признавали: «Мы не знали всей логики IBM. Интерфейс мы клонировали, но не поведенческую модель. Потому часто не понимали, почему внутри заложено то или иное решение». Это приводило к ряду архитектурных и инженерных парадоксов, когда формально «клон» не был полностью совместимым с оригиналом.
<Дядя Вася>: Как с рецептом торта. Дали нам рецепт, но без всех секретов. Яйца, мука, сахар есть, а почему он не такой воздушный? Оказалось, там нужно взбивать при определённой температуре и влажности. А этого в рецепте нет! Вот и с IBM так же. Сделали вроде бы один в один, а работает иначе. Потому что душа системы не в железе, а в ноу-хау.
В инженерной среде преобладала концептуальная увлечённость мини-ЭВМ, особенно подобиями DEC PDP. Так, разработка семейства СМ (Система Мини) стала попыткой слиять лучшие решения IBM и PDP в единую платформу. Однако ограничения по комплектующим — отечественные процессоры уступали аналогу Intel 8086 по тактовой частоте в 1,5–2 раза — делали задачу изначально сложной.
Разработчик ПО для ЕС-1066 вспоминал: «Когда мы увидели Apple II, мы не завидовали. Мы понимали, что делаем другие машины для других задач. Там — массовый потребитель. У нас — аэродромная система, и она должна отвечать за безопасность». Такой прагматизм определял философию многих разработчиков ЕС, для которых политический фактор был вторичен относительно прикладного смысла.
<Дядя Вася>: Яблоки мы, конечно, в магазине покупали, а не на компьютерах считали. Шутка. Но вообще, да. Наши задачи были другие. Нам не нужен был компьютер в каждый дом. Нам нужен был компьютер, который точно выведет спутник на орбиту или рассчитает нагрузку на плотину. Надёжность, отказоустойчивость — вот что было главным. А красивый интерфейс — это уже потом.
Тем не менее была и доля разочарования. Многие хотели не копировать, а создавать. Сотрудники проекта «Эльбрус» предлагали собственную архитектуру команд, базирующуюся на глубоком анализе потока вычислений, но проекту постоянно мешало давление унификации — любая инициатива должна была быть «совместима» с сериями ЕС.
Таким образом, взгляды разработчиков были сложными: уважение к мощи IBM сочеталось с внутренним несогласием. Советская инженерная культура всё же была воспитана в духе поиска оригинальных решений и глубоких математических моделей, а не копирования финальной реализации. Это напряжение чувствовалось в каждом техпроцессе ЕС ЭВМ.
<Дядя Вася>: В общем, как говорится, «и хочется, и колется». С одной стороны, возможность использовать чужой софт — это здорово. С другой — осознание, что мы не своё дело делаем. Но народ у нас творческий, всегда находил лазейки. В ЕС ЭВМ же были свои «изюминки», которых не было у IBM. Так что не просто копировали, а улучшали на ходу. Наше русское ноу-хау.
Что советские разработчики считали главным барьером собственного прогресса
Если говорить о внутренних причинах торможения развития ЭВМ в СССР, то в большинстве воспоминаний и документов исследователи называют не технические ограничения, а структурные. Бюрократия, ведомственная разобщённость, циклы согласований и отсутствие единого управляющего центра становились серьёзными барьерами. Как отмечал один из разработчиков в журнале «Радио» за 1982 год: «Проблема не в элементной базе. Проблема в том, что никто не знает, кто должен дать добро на её внедрение».
<Дядя Вася>: Это стопроцентно! Главным врагом прогресса был не Госдеп США, а наш родной «Отдел 57» в министерстве. Сидят там дядечки, которые в компьютерах не шарят, но имеют право визу ставить. Принесёшь им новую разработку, а они: «А где письмо из ВПК? А согласование с Главснабом?». Пока все бумажки соберёшь — технология устареет. Мы иногда шутили: «Чтобы сделать шаг вперёд, нужно получить разрешение у того, кто стоит сзади».
Советская наука и промышленность страдали от дробления функций. Министерство радиопромышленности разрабатывало узлы, связанное с аппаратной частью, но само ПО утверждалось в Минприборпроме. Если какая-то система «не вписывалась» в приоритеты текущего плана Госкомитета, её просто «замораживали». Так произошло, например, с серией «Корвет», которая имела перспективу занять нишу массовых школьных компьютеров, но не получила фабричной поддержки.
Разработчики ЕС-1036 вспоминали: «Мы хотели выпустить модификацию с меньшим энергопотреблением и оптимизированным интерфейсом внешних ПУ, но не смогли получить квоту на новые микросхемы. Зато рядом утвердили проект куда менее функциональный, но с ‘правильным’ ведомством». Часто решения принимались не по техническим, а по политико-административным соображениям: кто поможет продвинуть проект вверх по структуре, тот и получит финансирование.
<Дядя Вася>: История про «Корвет» — это вообще боль. Отличная была машинка для обучения. Мы её в школе хотели ставить. Но нет, не срослось. Вместо этого получили партию БК-0010, которые постоянно ломались. А всё потому, что завод, делавший «Корветы», был в другом министерстве, и тому министерству наш заказ был как собаке пятая нога. Вот так и хоронили перспективные разработки.
Имел место и так называемый «эффект спущенных задач»: научная организация должна была отчитываться по номенклатуре, а не по прикладной ценности. Часто были случаи, когда машина уже собрана, но заказчик не определён, или наоборот — есть острая задача (например, расчёт кривых навигации), но под неё нет выделенной техники.
Плановость, несмотря на свою дисциплинарность, мешала гибкости. Реальные условия проекта — когда необходимо изменить архитектуру, сменить язык программирования, добавить переформатированный ввод — не отражались в «дорожной карте» Совета Министров. В итоге даже успешные машины, такие как «Наири-3» или «ДВК-2», не получали дальнейшего развития: кадры уходили, заводы переключались на другие приказы, документация оставалась закрытой.
Инженеры часто описывали свою деятельность как «борьбу через модули». Одни модули доходят до производства, другие «тонут» в кабинете согласования. Это вызывало не только профессиональное, но и эмоциональное разочарование. «Ты делаешь машину, которую никто не использует. Или используют не по назначению», — писал специалист из Казанского НИИ автоматики.
<Дядя Вася>: Был у нас станок с ЧПУ на базе своей микро-ЭВМ. Так его в итоге отдали в ПТУ для кружка юных техников, потому что завод-заказчик передумал. А мы над ним два года корпели! Дети, конечно, рады были, игрались с ним. Но обидно до слёз. Как будто гоночный болид отдали на детский картинг.
Таким образом, главный тормоз — не отсутствующая технология, а несогласованность между ведомствами, топ-менеджментом науки и производственными решениями. Это хорошо понимали разработчики, которые создавали машины, не имеющие прямого пути к задачам.
Что бы сказали учёные того времени о развитии компьютеров сегодня — и что нам понять из их опыта
Если бы инженер 1970-х оказался в сегодняшнем цифровом мире, его первые эмоции наверняка сочетали бы восторг и скепсис. Восторг — от мощности процессоров, миниатюризации устройств, многозадачных операционных систем и актуальности искусственного интеллекта. Скепсис — из-за поверхностности многих решений, низкой прозрачности архитектур, и потери инженерной культуры, где каждый бит имел значение.
<Дядя Вася>: Я вот иногда смотрю на своего внука, как он на планшете пальцем водит, и смеюсь. Я ему: «Вань, а ты знаешь, что за этим движением пальца стоит миллион операций?». А он мне: «Деда, а зачем это знать? Оно же работает». Вот в этом и есть разница. Мы копались в каждой инструкции, а сейчас главное — чтобы интерфейс был удобный. С одной стороны, это прогресс, с другой — потеря глубины понимания.
Многие из тогдашних учёных могли бы спросить: «Зачем столько слоёв абстракции, если можно сделать проще и точнее?» Разработчики системы «Алгол-М» в Институте кибернетики Глушкова тратили месяцы на оптимизацию библиотек, чтобы выполнение задач по математическому моделированию укладывалось в доступные 32 КОЗУ. Сегодня же 8 ГБ памяти уходят на видеоплеер. Для советского инженера это было бы немыслимо.
Но главное — это интерес к задаче, а не к интерфейсу. Тогда не было экранов в современном понимании — вся работа шла с командной строки, через код. Советские специалисты в основном писали на низкоуровневых языках — машинных кодах, Алголе, Фортране. Принцип «понимать, что делает каждая инструкция» был не просто нормой, а обязанностью. Это формировало мышление, построенное на контроле, понимании внутренней структуры вычислений.
<Дядя Вася>: Мы на машинных кодах писали! Шестнадцатеричными числами. И в голове держали, какой код какой команде соответствует. Это как таблицу умножения знать. Сейчас, я слышал, уже и ассемблер редко кто знает, не то что машинные коды. Жалко как-то. Это же основа основ! Как без знания нот музыку писать?
Исследователи проекта «Эльбрус» стремились к архитектурам, в которых одновременно можно было выполнять несколько потоков команд — предвосхищение современных многопроцессорных систем. Они уже в начале 1980-х реализовали защиту памяти и концепцию микрокERNEL-подхода. Идеи, которые спустя десятилетия стали стандартом индустрии. Это не было чудом, скорее — результатом науки, которая опережала индустрию, но не имела доступа к массовому производству и рынку.
Наверное, самые важные замечания учёных той эпохи относились бы не к технологиям, а к организации. Они увидели бы, как мощные инструменты не всегда ведут к развитию. Программы не становятся лучше от увеличения объёма оперативной памяти. А системы — не эффективнее от роста количества пользователей. Качество во многом по-прежнему зависит от логики проектирования, архитектурных решений, команды специалистов.
<Дядя Вася>: Это да. Сейчас гигабайты оперативки жрут, а тормозят так, что мама не горюй. А наша «М-20» с её 4Кб считала баллистические траектории для всего Союза. Потому что код был вылизан до блеска. Не было места для лишнего. Сейчас это называют «оптимизацией», а для нас это была обычная работа. Может, стоит поучиться у стариков бережливости? Не ресурсов железа, а ресурсов мысли.
Опыт разработки МЭСМ, ЕС ЭВМ и ПЭВМ «Агат» учит нас придавать значение каждому этапу: от схемы логического элемента до построения пользовательской среды. Особенно это актуально в 2020-х, когда ответственность за цифровую инфраструктуру выросла до уровня национальной безопасности. Уже в 1971 году Глушков предупреждал: «Информационная система не может быть построена без доверия к специалисту. Если мы не воспитаем кадры — мы получим только шум».
Ещё один урок — это системность мышления. Советские инженеры часто одновременно работали над оптимизацией микропрограммного аппарата, написанием трансляторов и созданием системы тестирования. Отдельные достижения, такие как аппаратная реализация трансляции с языка программирования или встроенные отладчики в римском проекте ЕС-1045, показывают уровень мультидисциплинарности, который сегодня встречается редко.
Если бы сегодня сесть с конструктором «Мира» или «Наири» за один компьютер, он, возможно, удивился бы интерфейсу. Но быстро бы задал другой вопрос: «А кто это всё спроектировал? Как устроен цикл синхронизации? Почему здесь нет защиты от переполнения командного стека?» Это вопрос инженерной культуры. Не о красоте, а о целостности и надёжности.
<Дядя Вася>: Вот именно! Надёжность. Я своему внуку говорю: «Ваня, твой телефон умный, но если его уронить — он умрёт. А наш «Спектр-001» с третьего этажа падал — и ничего, только корпус погнулся. Потому что внутри не плата с дорожками, а полноценные модули на лампах, прикрученные болтами!». Он, конечно, ржёт. Но в каждой шутке есть доля правды. Мы думали на десятилетия вперёд, а сейчас думают до следующей модели.
И наконец: взгляд разработчиков прошлого всегда был ориентирован в будущее. Они не пытались «догнать», они пытались понять, как следует развивать технику в контексте задач общества. Отсюда проекты систем управления промышленностью в реальном времени, автоматизации народного хозяйства (ОГАС), гибридных вычислительных комплексов для обработки экономической информации. Вычислительная мощь мысли опережала доступную ЭВМ.
Знать и понимать, как мыслили те разработчики — не ностальгия, а инвестиция в технологическую зрелость. Их опыт позволяет иначе воспринимать ценность архитектуры, смысл совместимости, и важность баланса между «можно» и «нужно». Не каждая мощная система эффективна. Но каждая система, построенная инженером с пониманием задачи, остается актуальной десятилетия спустя. Возможно, именно этого нам и стоит перенять.
<Дядя Вася>: Вот и я о том же. Не нужно ностальгировать по лампам и перфокартам. Нужно перенять главное — умение видеть задачу целиком, от идеи до железа, и делать свою работу на совесть. Чтобы через сорок лет какие-нибудь дяди Васи с теплотой и уважением вспоминали не только мощность наших процессоров, но и глубину нашей инженерной мысли. Ну, я возможно, немного увлёкся. Старость, знаешь ли. На этом всё, дружище! Было приятно пообщаться на умные темы.