Кратко

  • Вернувшись на службу в U.S. Navy в 1967 году, Grace Hopper помогла превратить идею стандартизации компиляторов в организованную программу испытаний. В устной истории 1980 года она приписала George Baird важный приём, позволявший запускать общие тесты COBOL и FORTRAN на разных компьютерах.
  • Испытания U.S. Navy делали наблюдаемыми отдельные свойства языка и результаты их выполнения. Они не доказывали полной корректности компилятора, охвата всех возможных комбинаций или того, что любое приложение можно перенести без изменений.
  • Стандарт, свидетельство прохождения компилятором названных тестов и доказательство работы конкретной программы в другой среде — связанные, но разные утверждения. Если объединить их понятием «переносимость», ограниченное свидетельство превращается в обещание без чётких границ.

Стандарт ещё не был результатом проверки

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

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

Именно на этом позднем этапе карьеры Hopper строится менее известная часть истории. Вместо ещё одного пересказа о «первом компиляторе» или представления COBOL как личного достижения одного человека здесь важен переход от стандартизации к проверке её реализации. Переносимость зависела не только от общей грамматики, но и от поведения конкретного компилятора и от того, что могли подтвердить тесты.

У этой работы была коллективная предыстория. В статье 1972 года о системе проверки компиляторов COBOL Department of Defense George N. Baird описал рабочую группу, созданную в 1963 году. Её программы проверяли наличие функций, заданных стандартом. Целью было не отлаживать каждый продукт и не перебрать все мыслимые сочетания, а выбрать свойства, проверить их отдельно и в некоторых комбинациях, а затем зафиксировать результат.

Сделать сбой видимым

По описанию Baird, первые процедуры U.S. Navy продолжали прежнюю работу, но выдавали более полезные отчёты: фактический вывод сравнивался с ожидаемым, а отчёт указывал процедуру, где возникала ошибка. Предварительный набор включал 12 программ и около 5 000 строк исходного кода.

Такая конкретика меняет смысл слова «совместимый». Вместо широкого заверения поставщика можно сформулировать ограниченное утверждение: эта версия компилятора приняла перечисленные конструкции и выдала такие результаты в заданных условиях. Другая команда могла повторить запуск и сравнить вывод. Это не заменяло профессиональную оценку, но делало её часть проверяемой.

Hopper создавала возможность для проверки, а не работала одна

В устной истории 1980 года Hopper вспоминала, что Norman Ream, отвечавший в U.S. Navy за автоматизированную обработку данных, попросил её вернуться на действительную службу в 1967 году. Она описывала задачу как разработку процедур испытаний и валидации, которые поддержали бы языковые стандарты и помогли сделать программное обеспечение переносимее. Потребность в такой работе она сравнивала с проверкой продукта на соответствие спецификации.

По словам Hopper, она попросила выделить программистов, чтобы не выполнять всё в одиночку. Среди названных ею участников были гражданский специалист Ed Ford, лейтенант и двое моряков, включая Baird; позже присоединился Arnold Johnson. Журнал Datamation в 1971 году писал о процедуре валидации U.S. Navy как о работе группы под руководством Captain Hopper. Это подтверждает её лидерскую роль, но не доказывает, что она единолично написала систему.

Важна и хронология. В январе 1971 года Datamation сообщал, что U.S. Navy требует проверки компиляторов COBOL, а Department of Defense и National Bureau of Standards в принципе договорились разработать общие процедуры по стандарту ANSI. Согласие «в принципе» ещё не означало появления завершённой общегосударственной службы. Публикация фиксирует направление институциональной работы на тот момент, а не её конечный результат.

Приём, который Hopper приписала Baird

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

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

Воспоминания Hopper — ретроспективный рассказ о проектировании и разделении труда. Статья Baird 1972 года независимо подтверждает существование системы проверки и описывает её техническую структуру. Вместе источники дают сдержанную картину: Hopper помогла организовать задачу и команду; Baird предложил важный механизм для работы на разных машинах; в стандартизации и создании тестов участвовали также другие люди, а сама работа опиралась на более ранние усилия.

Чего не доказывал успешный запуск

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

Эта граница была важна не только для COBOL. История NIST об отдельной работе по тестированию FORTRAN, которую вели Betty Holberton и Elizabeth Parker, объясняет, почему конечный набор проверок не может доказать полную корректность компилятора. Это был параллельный проект National Bureau of Standards, а не набор тестов COBOL U.S. Navy, связанный с Hopper. Различие важно и технически, и исторически: разные команды превращали проверку соответствия в институциональную практику для разных языков.

Соответствие компилятора стандарту и переносимость приложения — тоже разные уровни. Компилятор может пройти выбранные стандартные тесты, а приложение при этом зависеть от расширения конкретного поставщика, службы операционной системы, формата файла, поведения среды выполнения или представления данных. Это вывод из ограниченного охвата тестов, а не утверждение, что набор U.S. Navy проверял каждую такую зависимость. Для переноса нужны собственные прикладные тесты и описание среды, в которой программа действительно работает.

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

Наследие измеримых утверждений

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

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

Для программных систем с долгим сроком службы подтверждение должно сопровождать утверждение: какая редакция стандарта, какая сборка компилятора, какие тесты, какая конфигурация для машины и какие результаты? Работа U.S. Navy при Hopper не устранила различия между поставщиками. Она дала организациям способ выявить часть этих различий, сравнить реализации и принимать решения о закупках на более надёжной основе.

Источники