Кратко

  • LAP6 показывал длинную рукопись как движущийся свиток: пользователь добавлял или удалял строку в текущем месте и сразу видел изменение внутри текста.
  • Сохранение рукописи обновляло именованную запись на LINCtape; преобразование, загрузка, запуск и проверка эксперимента оставались последующими и разными операциями.
  • LAP6 написала Wilkes, но проверенные источники также связывают ленточную технику редактора с Mishell J. Stucki и Severo M. Ornstein, контекст LINC — с Wesley Clark и его командой, а требования и испытания — с пользователями и коллегами из Washington University.

На экране LINC появляется строка исходного текста. Оператор перемещается к ней, удаляет её и набирает замену. Следующие строки сдвигаются, их номера меняются, исправление видно в контексте. Для машины всего с 2 048 12-битными словами памяти это было не украшение интерфейса, а центр системы разработки.

В статье 1970 года «Conversational Access to a 2048-Word Machine» Mary Allen Wilkes описала LAP6 как интерактивную среду для редактирования текста, автоматического хранения, обслуживания файлов, подготовки и ассемблирования программ. Достижение состояло в том, что эти действия были связаны, но не выдавались за одно и то же доказательство.

Рукопись была видимым рабочим объектом

Рукопись LAP6 могла быть любой полезной последовательностью символов с клавиатуры. Обычно это был исходный текст программы, но система не навязывала такой формат. Стандартный свиток занимал 45 блоков ленты, или 23 040 символов; одновременно в оперативной памяти требовалось обрабатывать лишь небольшую часть.

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

В отдельной работе Wilkes о редактировании прокруткой раскрыт внутренний механизм. Текст оставался непрерывной строкой по фиксированным адресам ленты. Рабочая зона на 512 символов в точке разрыва принимала вставки и удаления; при движении свитка материал снова сшивался с основным текстом. Алгоритм изменял сам текст, а не накапливал скрытый список правок для будущего согласования.

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

Хранение создавало другое состояние и другую границу отказа

Файлами LAP6 управлял индекс из двух блоков. Запись могла быть рукописью или двоичной программой; это разные типы, способные иметь одно имя и при этом не быть одним объектом. Команда сохранения переносила текущую рукопись или выбранный диапазон в запись. Другие команды копировали между двумя лентами рукописи, двоичные файлы либо все записи, которых ещё не было у получателя.

LAP6 подбирал непрерывные свободные блоки рядом с индексом. При замене система не обещала использовать прежнее физическое место. Если имя уже существовало, появлялся вопрос REPLACE?, требующий явного решения. Подтверждение защищало имя от случайной перезаписи, но не удостоверяло атомарность операции.

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

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

Ассемблирование и запуск не были синонимами сохранения

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

LOAD был отдельным действием. Он переносил текущую или сохранённую двоичную программу в память и запускал её по документированной процедуре. Если лента LAP6 оставалась подключённой, можно было быстро вернуться к рукописи и таблице символов, внести исправление и снова выполнить сборку. Короткий цикл уменьшал необходимость править двоичный код, но не превращал изменение источника в результат выполнения.

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

Граница авторства тоже имеет значение

Согласно устной истории Computer History Museum, Wilkes написала основную часть LAP6 в 1965 году на LINC, установленном в гостиной дома её родителей в Baltimore. По её словам, система в значительной мере создавалась заново, хотя полезные прежние процедуры переиспользовались; версия LAP5 затем несколько месяцев работала в St. Louis до общего выпуска.

Это веское подтверждение авторства, но не повод стирать команду. Wesley Clark руководил проектом LINC и вместе с Wilkes написал «Programming the LINC». Руководство прямо благодарит Mishell J. Stucki и Severo M. Ornstein за технику работы с лентой, использованную редактором. Коллеги из Washington University испытывали предварительные версии; посещения лабораторий LINC формировали требования. MIT Lincoln Laboratory предоставила более раннюю среду, в которой появились LINC и его симулятор.

Вторичные пересказы иногда смешивают не только роли, но и имена. Изученные первичные документы называют Mishell J. Stucki и Severo M. Ornstein. Они не подтверждают отдельных вкладов в LAP6 людей по имени «Philip Mishell» или «Ted Severo». Ответственная история сохраняет эту неопределённость, а не придумывает совпадение личностей или перераспределяет заслуги.

Источники