на чем программирование в 80е годы

Рефал, Эль и Рапира. Куда пропали советские языки программирования?

О советских языках программирования сегодня говорят редко. Машины, которые их понимают, стали экспонатами технических музеев или решают секретные задачи для оборонки и в закрытых НИИ. А ведь некоторые из них не уступали по мощности более популярным аналогам и содержали очень смелые идеи. Посмотрим на самые знаменитые языки программирования Made in USSR.

Рефал

В шестидесятые годы в промышленности и науке уже активно применяли высокоуровневые языки. Учёные в США и Канаде писали программы на Fortran, в Европе и СССР — на Algol. Даже у бизнеса был свой язык программирования — COBOL. Все они поддерживали императивную парадигму: программист подробно описывал каждый этап вычислений с помощью переменных и операторов. Императивная парадигма считалась перспективной и единственно верной.

На этом фоне декларативный Рефал казался львом Бонифацием в Сибири. Его создал в 1966 году Валентин Турчин — математик, кибернетик, философ, правозащитник и поэт (Тони Старк, ты ли это?).

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

Турчин считал, что человек — это кибернетическая система, а сознание — управляющая программа. Наши кожа, кости и другие ткани постоянно обновляются. А значит, когда-нибудь люди заменят этот материал на кремний или металл, а сознание будет жить неограниченно долго.

Чтобы понять концепцию Рефала, необходимо понять философские воззрения его создателя. Для него эволюция — это череда переходов от мелких систем к более сложным, высокоуровневым. Они воспроизводят системы предыдущего уровня, а потом, в свою очередь, объединяются в системы более высокого порядка. Турчин назвал эти превращения «метасистемными переходами».

Пример из промышленности: раньше у нас были строительные инструменты, потом появились станки для производства инструментов, а потом сделали ПО для проектирования таких станков.

Пример из ИТ: раньше сайты писали на чистом HTML и CSS, потом появились конструкторы сайтов, а затем — no-code-платформы вроде Bubble, на которых можно создавать сами конструкторы сайтов.

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

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

Приятно, что Рефал до сих пор жив и развивается. Он стал тем самым метаязыком, на котором учёные создают новые языки программирования. Но не удивляйтесь, если не знаете ни одного из них: эти языки создают специально для военных компьютеров, а не для «Hello, World!». Только вот зачем военным ещё одна армия — армия языков программирования, — известно только самим военным. Гостайна 🙂

Информацию о Рефале можно найти в русскоязычном комьюнити.

Источник

Привет от программистов 80-х

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

Осторожно, под катом много фотографий!

В середине 80-х государство прилагало немало усилий для популяризации информационных технологий. Публиковались научные статьи, в журналах появлялись целые разделы, посвящённые ИТ-тематике. Для профессионалов (которые в то время были в основном учёными) Академия наук СССР выпускала журнал «Программирование». Не забыли и про любителей. Например, в журнале «Техника — молодёжи» появилась рубрика «Человек и компьютер», которая была посвящена разъяснению новых терминов и обзорам новых устройств. Там же публиковались советы по борьбе с вирусами, использованию носителей и т.п.

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

15 млн) призывал женщин осваивать компьютер наравне с мужчинами, а ещё — учить этой науке дочерей. В сентябре 1986 года на обложке издания появилась маленькая девочка перед монитором.

Хотя компьютер стоил довольно дорого, его реально было собрать из деталей, купленных на радиорынке. Поэтому простенькие статьи о компьютерах и программировании появлялись даже в «Мурзилке»!

Такая популяризация компьютерных устройств иногда приводила к казусам. Например, в газете «Труд» от 1987 года появилась заметка о предприимчивом начальнике АСУ цементного завода, который вынес деталей на 6 000 рублей, чтобы собрать дома личный компьютер. По тем временам шесть тысяч рублей стоила небольшая квартира в Москве, хотя ВАЗ-2106 стоил ещё больше — 9 124 рублей.

Тема любительского программирования неоднократно поднималась на страницах популярного научного издания, как «Наука и жизнь» (тираж — 3 млн). С 1985 года там стали публиковать статьи в рамках цикла «Школа начинающего программиста». В этих статьях читателя обучали основам создания программ для микрокалькуляторов. Сейчас это может показаться удивительным, но в то время программирование называли искусством. Как сильно такой подход разнится с часто встречающимся сегодня «индусским» кодом!

Чтобы ещё больше погрузиться в ламповую атмосферу программирования конца 80-х, предлагаем вашему вниманию сканы из чудом сохранившегося у одного из сотрудников Cloud4Y журнала «Наука и жизнь» за 11.1988. Это занятие №22 пресловутой «Школы начинающего программиста».

Чуть более удобный вариант для чтения есть в Archive.org. Если хочется получить ещё больше информации о программировании на калькуляторах, то вот хорошая статья.

Пока в СССР развивали любительское программирование, в США строили прогнозы на будущее. Так, Apple провела конкурс идей о том, какими будут компьютеры в 2000 году. В конкурсе победила группа студентов Иллинойского университета. О том, что они предположили, рассказано в заметке из журнала «Наука и жизнь» от 1988 года. Её ещё в 2009 году нашёл sultee, но менее интересной она от этого не становится, правда?

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

Cloud4Y предлагает разработчикам и DevOps инженерам сервера IaaS на платформе VMware + Объектное S3 хранилище в аренду со скидкой 40%. Вы получите хостинг, инфраструктуру под тестирование и размещение проектов/приложений/web-сервисов.

Благодаря VMware сокращается до минимума необходимость конфигурирования как отдельных инструментов, так и конвейера разработки в целом. Используйте технологии виртуализации и объектное хранилище S3 для максимальной автоматизации CI/CD, чтобы упростить жизнь специалистам, вовлечённым в процесс разработки.

Источник

Как выглядела разработка… ну скажем, в 80-х годах прошлого века

Уже много раз в исторических постах на Хабре я видел вопросы такого плана: «А как вообще выглядела разработка тогда, когда машины были большими»? Как был построен процесс, как устроена сборка, существовал ли отладчик (заменить на любой другой инструмент), как происходило взаимодействие в команде, и т.п.

Попробую рассказать об этом на своем примере.

Итак, 80-е годы прошлого века.

На фото — заставка с терминала IBM 3270, система VM/370.

Как выглядела разработка тогда, ну скажем, скажем в 1989 году. Для определенности, опишу ту среду, в которой работал сам, это была VM/SP (известная также как СВМ/ПДО), версии с 3 по 6.

У этой ОС долгая история, она носила другие названия, например CP-40, CP-67, VM/370, и начиналось все еще с моделей S/360, для которых эта ОС была изначально разработана, как первая система не для пакетной работы, а с разделением времени. Официально считается, что VM существует с 1972 года, то есть уже 48 лет. Последний релиз был кажется в 2018 под названием z/VM.

Первой же реально работавшей ОС с виртуализацией всего железа пожалуй была CP-40, это 1964-1967 годы.

Теперь немного про саму ОС. Собственно VM/SP — это система, основа которой виртуальные машины. Т.е., для ОС пользовательские задачи выглядят как виртуальные машины S/370, где могут выполняться любые ОС, предназначенные для этой системы. В том числе — и сама VM/SP. А для пользовательских задач VM/SP выглядит как предоставленная им реальная машина, на которой можно работать так, как будто это просто S/370, с ограниченными ресурсами.

То есть, ОС предоставляет пользователю ресурсы в форме виртуальной аппаратуры — процессора, памяти, дисков, и других устройств. А дальше это оборудование загружает с одного из устройств гостевую операционную систему, любую из тех, что могут работать на реальной машине, и уже с ней работает пользователь. Например, можно было загрузить другие ОС от IBM, такие как MVT. Для гостевой же ОС виртуальная машина идентична реальной, выполняет те же команды, точно так же осуществляется и ввод-вывод — путем запуска канальных команд.

Иными словами, роль API для взаимодействия между ОС и программой тут играет набор команд S/370. И никакого другого API, похожего скажем на POSIX, не существует. Ну или, если быть точным, то была такая команда DIAG, которая на реальной машине выполняла функции диагностики оборудования, а на виртуальной — позволяла выполнять команды ОС, например. Но у нее было всего-то 6 функций, т.е. на API уровня POSIX, или Win32 это никак не тянет все равно.

ОС состоит из так называемой управляющей программы, или CP, загрузчика, драйверов устройств. Конфигурация устройств описывается при генерации системы в виде макрокоманд ассемблера. Это типично для большинства ОС на этой архитектуре, поскольку с точки зрения процессора все периферийные устройства одинаковы, и отличаются только запускаемыми канальными программами. То есть, мы (системный программист) должны сообщить ОС, какие устройства ей доступны, и под какими адресами они подключены.

CP выполняет загрузку и запускает виртуальные машины, какие-то автоматически, например машину оператора, какие-то — когда пользователь осуществляет вход в систему. Прикладное же ПО выполняется уже в виртуальных машинах, в той или иной гостевой ОС.

Работа в VM/SP

Как уже сказано, это была ОС с разделением времени. Т.е. для работы с терминала в интерактивном режиме. После загрузки самой ОС оператор мог ввести команду ENABLE, и сделать подключенные терминалы доступными для входа в систему. После этого на них появлялась та самая заставка, какую вы видели выше. Заставку, кстати, можно было и поменять.

С экрана заставки вы вводите логин (название виртуальной машины) и пароль — и ваш реальный терминал становится одновременно консолью виртуальной машины. Вы можете, вводя с него команды, изменять ее конфигурацию, подключать или отключать устройства. А заодно делать все вещи, которые делают с консоли машины реальной — отлаживаться, т.е. ставить точки останова, смотреть и менять память, регистры и т.п.

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

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

Виртуальные машины

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

Для машины естественно выделяется некоторый объем памяти. Значение по умолчанию задается в оглавлении, как минимум и максимум. С определенного момента стало можно указывать архитектуру, которую должна поддерживать машина (от этого, в частности, зависит максимально адресуемый объем памяти). S/370 имела 32 битовые адреса, из которых только 24 бита использовались, далее появилась архитектура XA с поддержкой 31 битовых адресов, а затем и ESA с 32-битовыми.

У машины могут быть собственные диски. Обычно это так называемые минидиски, которые представляют из себя несколько цилиндров реального тома (и не более тома целиком). Но можно также прикрепить к машине реальное устройство с установленным на нем томом, которое будет использоваться монопольно.

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

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

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

Отображение виртуальных ресурсов на реальные происходит по-разному, в зависимости от типа ресурса. Процессор выделяется реальный, в виде квантов. Память выделяется виртуальная, можно при этом зарезервировать некоторый объем реальной. Устройства — в зависимости от типа. Выполняемые канальные программы модифицируются, чтобы например преобразовать номера цилиндров минидиска в цилиндры диска реального, а для устройств печати и перфокарт — полностью эмулируются.

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

По умолчанию гостевая ОС описывается в виде устройства, с которого происходит загрузка виртуальной машины. Как правило это диск (минидиск). Кроме того, ОС позволяет создавать снимки памяти уже загруженной системы, с которых потом можно загружаться существенно быстрее. Это именуется хранимыми сегментами (saved segments), и они являются именованными и глобальными. То есть, если у нас имеется сегмент CMS, то загрузка ОС CMS (не следует их путать) может быть выполнена как в виде IPL 190, с минидиска, так и IPL CMS, из хранимого сегмента.

Специально для целей разработки была создана однопользовательская и однозадачная ОС, которая могла работать только на виртуальной машине. Эта ОС называлась CMS (Conversational Monitor System/Cambridge Monitor System), в разных вариантах, по назначению и по месту разработки. Это не британский Кембридж, если что, а тот что в Бостоне.

Эта ОС предназначена для того, чтобы один пользователь мог работать в ней, пользуясь дисплеем и клавиатурой, разрабатывать программы, или допустим набирать и форматировать тексты. Дисплей с клавиатурой представляет из себя консоль управления виртуальной машиной, с которой можно вводить как команды VM/SP (относящиеся к т.н. Control Program, CP), так и команды самой CMS. У вас есть командная строка, есть строка состояния, где отображается текущий статус, и строки вывода результатов. В этом режиме дисплей моделирует поведение пишущей машинки. Вы можете также запустить программы, использующие все возможности дисплея, например, для редактирования текста или для просмотра файлов.

Если вы видели MS DOS, то многое вам будет привычно. Причем речь идет про MS DOS до версии 2.

Рассмотрим некоторые типовые (не все, разумеется) задачи, которые пользователю нужно выполнять при разработке:

Файлы

В качестве места для хранения файлов у ОС есть диски, они именуются буквами от A до Z. Буква не обозначает физический том с определенным набором файлов, и может быть изменена. Обычно диски S и Y были системными, где располагались файлы CMS, а диск A был свой, с доступом на запись, и там хранились файлы пользователя.

То есть, с дисками мы можем делать примерно следующее:

Соответственно, структура файловой системы плоская (это не совсем так, но главное что она не древовидная, как мы привыкли сегодня). Папок с файлами не предусмотрено. Имеются файлы типа «библиотека», содержащие например макросы ассемблера — но на этом сложные структуры пожалуй заканчиваются (хотя в какой-то степени поддерживались файлы от OS/360, типа MVT).

Просмотр дисков осуществляется в порядке алфавита. То есть, если мы ищем ABC ASSEMBLE *, и файл с таким именем и типом найден на диске A, то поиск на этом прекращается. Как вы уже догадались, были так называемые wildcards, но достаточно ограниченные.

Чтобы работать с файлами, имеется широкий набор команд. Они могут быть реализованы как бинарные скомпилированные программы (тип MODULE), так и на нескольких скриптовых языках, например EXEC2 или REXX. И те, и другие запускаются из командной строки путем ввода имени файла (т.е. происходит автоматический поиск файлов с этими типами).

Разумеется, можно посмотреть список файлов — командой LIST, можно просмотреть содержимое — командой BROWSE, можно вызвать текстовый редактор — XEDIT. Чтобы напечатать файл, существует команда PRINT. Скриптовые языки позволяют наборы команд автоматизировать и оформить как одну команду. Для обмена данными между командами имеется такая структура, как стек — так что вызвав скажем команду LIST * * * (STACK, вы получите в этом самом стеке список файлов, который скрипт может прочитать, и обработать.

Хочу Нортон коммандер!

Чтобы работать со списком файлов интерактивно, имеется также команда FLIST. Это и было ближайшим аналогом Norton Commander, только панель тут была одна.

Первая строка — данные о диске, включая заполненность, в данном случае мы видим диск с буквой A, он же — устройство 191.

Мы видим тут колонку имени, типа и буквы диска. Далее идут формат файла — фиксированной длины строки или переменной (F/V), длина строки, размер в блоках, дата изменения.

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

У команд разрешаются параметры, обозначающие текущий файл или компоненты его названия: /, /N, /T, /M, т.е. полный ID файла, имя, тип, mode (так именуется буква диска).

Например, команда PRINT / в третьей строке выполнится с подстановкой полного ID, т.е. PRINT DTRYLST LISTING A. Если у файла тип скажем PRINT, то ввод просто /T / приведет к выполнению команды PRINT «имя» «тип» «буква диска», т.е. к печати текущего файла. То есть, тип файла тут используется как имя команды.

А в последней строке вы видите подсказку по функциональным клавишам (PF), которых было ровно 12: HLP — справка, BRW — BROWSE, END — выход, XED — XEDIT, SPL — разделить экран по строке курсора, /SB — сортировать по размеру, SCB — лдистать назад, SCF — листать вперед, /SD — сортировать по дате, /ST — сортировать по типу, >I — увеличить строку команды, CAN — убрать разделение.

А вот скриншот с экрана ПДО. Все в общем тоже самое, только некоторые надписи переведены:

И на этот раз перед вами содержимое системного диска S, с файлами самой CMS.

Обмен файлами

Если нужно передать файлы между виртуальными машинами, первым очевидным способом является предоставление доступа к диску другому пользователю. Он может присоединить диск к своей виртуальной машине командой LINK, и открыть доступ к файлам командой ACCESS, а далее работать с ними как со своими (с учетом ограничения доступа только чтением, или чтением и записью).

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

Очевидно, тот факт, что это как бы перфокарты, не ограничивает возможности передачи файлов любого формата — все мы знаем это по сегодняшней электронной почте, BASE64 и другие методы кодирования никто не отменял, и они существовали.

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

XEDIT

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

Поэтому про него — коротко.

Во-первых, файл должен был полностью помещаться в память. Это позволяло работать быстро. Ограничение — примерно объем памяти виртуальной машины. Напомню, что адресация у S/370 была лишь 24-битовая, расширена до 31 и далее 32 она была позже в VM/XA и ESA.

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

Функциональные клавиши

Почему важны функциональные клавиши? Дело в том, что терминал IBM 3270 (ЕС-7927) имел собственный экранный буфер размером 24 строки на 80 символов. Нажатие обычных клавиш алфавита, пунктуации и т.п. приводили к изменению содержимого буфера. А вот в программу буфер передавался только по нажатию клавиш Enter, PF1-PF12, т.е. специальных. Только они вызывали прерывания ввода-вывода. То есть, с одной стороны, терминал брал на себя многие функции редактирования (вставки, удаления, замены), а с другой — гибкость взаимодействия обеспечивали только функциональные клавиши, только они могли программироваться. Не было и такого, чтобы вы могли запрограммировать сочетания клавиш, такие как ctrl-буква, например.

Максимум что было доступно — это терминалы с 24 функциональными клавишами.

Плюсами такой архитектуры была низкая нагрузка на процессор. Фактически, за счет этого машина типа ЕС-1046, например, всего с 4 мегабайтами памяти, могла обслуживать несколько десятков терминалов (в нашей практике — до 60), при условии, что пользователи занимаются набором и редактированием текста.

Принципы редактирования

Буфер терминала IBM 3270 мог быть программно разбит на поля, каждое из которых имело определенные атрибуты, например доступность для редактирования. Или яркость, например (а в более новых моделях и цвет).

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

Набор команд? Ну, если вы знакомы с чем-то типа vi, или скажем sed знаете, то в вы вполне сможете сориентироваться в XEDIT довольно быстро. Я бы сказал, что в XEDIT все даже проще в некотором роде, например потому, что нет такой вещи, как состояния. Текст сам по себе, командная строка — сама по себе, чтобы ввести команду — нужно перейти в строку команд, в строке текста вы вводите или редактируете текст (режим вставки или замены реализован аппаратно). Удобнее ли это в целом — не знаю, но в среднем это проще.

Перейти на строку, или найти строку, выполнить замену подстроки, удалить или вставить строки, скопировать или переместить — в общем, вполне обычный набор. Префиксные команды немного интереснее. Скажем, пара команд CC в разных строках файла, и третья команда (Before/aFter), указывающая куда скопировать — практически это было максимально близко к тому, что есть и на сегодня, с учетом отсутствия GUI.

Компиляция, сборка, версионирование

Собственно, в этом месте ничего необычного не было. Командная строка (или FLIST), команда компиляции в зависимости от языка, дальше файл (или файлы), и после круглой скобки — параметры (так было принято в CMS). В итоге получается объектный файл с типом TEXT, который потом линкуется с другими такими же файлами и библиотеками командой LOAD, и строится файл MODULE при помощи GENMOD. Или можно загруженный код просто запустить, например. Библиотеки макросов или модулей для линкера описываются командой GLOBAL.

Самих компиляторов было множество. Интерпретаторов тоже. В CMS были реализации для множества языков, как широко распространенных, так и довольно экзотических. Наиболее распространенными в моем окружении были FORTRAN (сначала IV, а позже 77), PL/1, ассемблер, REXX, LISP (в форме REDUCE), PASCAL/VS от IBM. Позже появился C, но широкого распространения тогда не получил, по ряду причин (в первую очередь наверное различия в парадигмах между UNIX и ОС от IBM, что в итоге приводило к некоторым неудобствам). Были и такие экзотические штуки, как PL/S, эдакий «ассемблер высокого уровня», то есть по сути — C, но для для S/370.

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

Никакой инструмент типа make мне лично не был известен, но интуитивно понятно, что реализовать какой-то механизм для автоматизации сборки можно было, например на REXX (и такие попытки предпринимались). Насколько я знаю, на сегодня make в CMS есть совершенно обычный.

Документация

Для подготовки документации было минимум два похожих инструмента. Один — это продукт SCRIPT UW, разработка университета Ватерлоо, Канада (собственно, UW — это он и есть). Второй, очень похожий инструмент — это разработка IBM под названием Script/VS.

Из того, что мы знаем сегодня, оба продукта больше всего похожи пожалуй на TeX. Т.е. вы пишете текст, и расставляете внутри него разметку, например :p. для обозначения параграфа. Потом текст обрабатыватся программой SCRIPTVS, и мы получаем файл, который можно напечатать на принтере. Поддержка принтеров — ограниченная. Поскольку обычный принтер для S/360 не умел делать ничего специфического, в частности, не имел загружаемых или сменных шрифтов, то максимум, что нам было доступно — это повторная печать строки поверх предыдущей, и получение шрифта bold. И весьма ограниченное позиционирование текста на странице. Заголовки, сбор оглавления, колонтитулы, фрагменты предформатированного текста… это все было. В общем, было довольно много чего, что вы можете представить сегодня также и по HTML, например.

Теоретически (и практически) оба продукта расширялись, например, разметка была реализована как пользовательские макросы, можно было в какой-то степени реализовать поддержку других принтеров. Но я бы сказал, что уже Word for DOS версии примерно 5 умел делать все тоже самое сильно лучше. Ну и массовые лазерные принтеры, конечно, произвели окончательную революцию в этом вопросе.

Главное — и трава была зеленее.

Вот как-то так в целом выглядела тогда разработка. Обычный и на сегодня цикл — создание кода в текстовом редакторе, сохранение, компиляция, линковка, запуск, отладка. Далее — редактирование, и все снова. Разумеется, XEDIT — это не IDE. Да и FLIST это даже не FAR. Все несколько попроще, и масштабируется немного похуже.

Ну так и железки были слегка другие — не забудьте, что в нашем распоряжении только текстовый экран 24*80, такой же чисто текстовый принтер, порядка 16 мегабайт памяти у виртуальной машины, и столько же, если не меньше — у машины реальной. Ну и для полноты картины — самые большие диски, что я застал, были 317 мегабайт, и это были несменные устройства, и у нас их было порядка 8 штук максимум. То есть, вся дисковая память типовой EC-1046 была по порядку примерно пару гигабайт + сколько-то сменных пакетов, которые можно было установить при необходимости. Диски для персоналок по-моему доросли до этого объема примерно к 2000, когда появились модели емкостью порядка гигабайта.

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

Но тогда, уже давненько, многое из этого все равно казалось чудом…

Источник