Интервью с Эдсгером В. Дейкстрой (2001), часть 1: начало программирования и разница подходов в Европе и Америке

Изучение истории помогает понять, как формировались текущие концепции, как появлялись какие‑то решения, в чем была разница в культурных подходах различных стран.

Рассуждения Э. Дейкстры о роли программирования, научного подхода и этики дают пищу для размышлений, которые актуальны даже в наши дни.

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

Поэтому я решила проанализировать интервью 2021 года Ф. Франы с Э. Дейкстрой (ссылки на источники в конце). Это позволяет не только раскрыть мысли героя интервью, но и напомнить о начале истории программирования, почему оно получилось таким, а не другим.

В тексте:

• в скобках квадратных [ ] указаны примечания самого интервьюера Ф. Франы;

• в скобках фигурных { } указаны мои уточнения.

В этом блоке привожу пояснения.

Скрытый блок

В скрытом блоке тоже пояснения для экономии места.

С пояснениями текст получается достаточно длинным, поэтому публикую только готовую 1-ю часть.

---

Интервью с Эдсгером В. Дейкстрой

Интервьюер: Филип Л. Франа, Университет Джеймса Мэдисона

Дата: 2 августа 2001 года

Место: Остин, Техас

Архив: Институт Чарльза Беббиджа, Центр истории обработки информации, Университет Миннесоты

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

Э. Дейкстра: Все началось в 1951 году, когда мой отец дал мне возможность пройти курс программирования в Кембридже, Англия. Это был пугающий опыт {a frightening experience}: впервые я покинул Нидерланды, впервые мне пришлось понимать людей, говорящих по‑английски, и сразу же я остался один, пытаясь следить за курсом по совершенно новой теме. Но мне очень понравилось.

Нидерланды были такой маленькой страной, что Аад ван Вейнгаарден, директор вычислительного отдела Математического центра в Амстердаме, знал об этом {о том, что Дейкстра прошёл курс в Кембридже} и предложил мне работу, которую я смог принять только в марте 1952 года. И я стал программистом Математического центра на неполной ставке.

У них еще не было компьютеров, они пытались их построить. Я программировал до 1962 года, и первые восемь лет моей работы там я разрабатывал базовое программное обеспечение для серии компьютеров, которые строились в Математическом центре. И в эти начальные годы я был очень консервативным программистом. Способ записи программ, форма машинного кода на бумаге и организация библиотеки, ввод, вывод и т. д. — все это в значительной степени моделировалось по тому, что я видел в 1951 году в Кембридже, но все работало удовлетворительно.

Математический центр в Амстердаме (Mathematisch Centrum) был основан в 1942 году с целью помочь восстановить Нидерланды после Второй мировой войны. Как было написано в уставе, это должно было быть достигнуто путем «содействия систематической практике чистой и прикладной математики в Нидерландах». Что должно было привести к «повышению уровня благосостояния и цивилизации в Нидерландах». Кроме того, целью было «увеличить вклад Нидерландов в международную культуру». С 1983 года — Centrum Wiskunde & Informatica (CWI).

Ф. Франа: Насколько я понимаю, когда вы поженились, вы не могли внести термин «программист» [в интервью: programmer] в запись о бракосочетании?

Э. Дейкстра: Это правда. Да.

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

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

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

• Сбор такой информации позволял властям отслеживать демографические изменения и профессиональный состав населения.

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

Ф. Франа: Когда это слово [программист] стало признанным?

Э. Дейкстра: Думаю, в начале шестидесятых. Это известная и правдивая история. Я должен был изучать теоретическую физику, я так и сделал, и это было причиной поездки в Кембридж, потому что меня готовили стать отличным теоретическим физиком. Идея заключалась в том, что если помимо всех обычных инструментов я смогу также использовать компьютеры, я, возможно, смогу стать лучшим теоретическим физиком, превзойти средний уровень.

Однако в 1955 году, после трех лет программирования, будучи еще студентом, я пришел к выводу, что интеллектуальный вызов программирования был больше, чем интеллектуальный вызов теоретической физики, и в результате я выбрал программирование, потому что программирование было таким непрощающим [that programming was so unforgiving]. Если что‑то шло не так, я понимал, что ноль — должен быть нулём, а единица — должна быть единицей.

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

В ранние годы вычислений компьютеры работали с двоичным кодом, использующим только два символа: 0 и 1. Эти цифры — фундаментальные строительные блоки всех компьютерных инструкций и данных.

Если в коде есть хоть одна ошибка (неверный 0 или 1), программа не будет работать — в двоичном коде нет понятия «почти правильно»; код либо совершенно правильный, либо полностью неверный. Эта природа сделала программирование сложным, но интеллектуально более привлекательным занятием для героя интервью, чем теоретическая физика.

Я никогда не использовал чужое программное обеспечение. Я использовал машины {компьютеры}, в разработке которых сам участвовал, я документировал машинный код и написал свое собственное базовое программное обеспечение и все программы, и если что‑то шло не так, это сделал я. И именно эта непрощающая природа бросала мне вызов, потому что я также начал понимать, что, хотя в принципе это очень просто. Ноль — это ноль, а единица — это единица, и вы должны иметь полный интеллектуальный контроль над тем, что вы делаете, каким‑то странным и непонятым образом программы могут становиться очень сложными, хитрыми.

Так что в 1955 году я решил не становиться физиком, а стать программистом. Это было трудное решение, потому что, как я уже сказал, меня готовили стать первоклассным ученым, а в то время программирование не выглядело как научная деятельность, это была просто смесь изобретательности и точности.

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

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

Сомнения Дейкстры были вполне обоснованы:

1. До появления высокоуровневых языков программирования (FORTRAN, ALGOL) работа программистов была сложной и трудоёмкой, с низким уровнем абстракции.

2. Программирование ещё не воспринималось как дар для технологической революции. Связь с будущим развитием вычислительных систем и автоматизацией не была очевидна.

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

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

Ф. Франа: Итак, как вы тогда приступили к тому, чтобы сделать информатику уважаемой наукой?

Э. Дейкстра: Ну, это случилось позже. Я поговорил с ван Вейнгаарденом в 1955 году и объяснил свою дилемму, что мне нужно уйти из науки, если я стану программистом. И он сказал, что, во‑первых, что компьютеры пришли, чтобы остаться, что это не было развлечением. А затем он сказал, что согласен с тем, что в компьютерном программировании нет четкого научного компонента, но что я вполне могу стать одним из тех, кого призвали сделать его наукой. И в то время я был тем парнем, которому вы могли сказать такие вещи, и он даже принял бы их.

Как я уже говорил, меня готовили стать ученым. Когда я пришел в 1952 году, они работали над ARRA (Automatische Relais Rekenmachine Amsterdam), но не могли добиться надежности, и была построена обновленная версия с использованием селеновых диодов вместо реле.

Затем Математический центр построил машину для авиационной промышленности Fokker, потому что до этого мы провели на ARRA множество вычислений для F27. Таким образом, была построена FERTA (Fokker Electronische Rekenmachine Te Amsterdam), обновленная версия ARRA, и установлена в Схипхоле. Установку я проводил вместе с молодым Герардом Блаау, который позже стал одним из разработчиков IBM 360, вместе с Амдалом и Бруксом.

Одна забавная история о F27, который Fairchild позже построил под названием «Friendship».

Во время своего первого визита в Австралию я летел на большом 747 из Амстердама в Лос‑Анджелес, затем сменил самолет и сел на другой 747, из Америки я полетел в Сидней или Мельбурн, я не помню, какой из двух. А затем была заключительная часть путешествия на F27 в Канберру, потому что меня пригласили австралийцы в Канберру. И мы приехали, я вышел из самолета и встретил своего принимающего {человека, который отвечает за гостя в рамках деловой поездки или визита в профессиональной сфере}, которого никогда раньше не встречал, но мы обменивались письмами.

И он очень извинялся, что этот путешественник по миру должен был проделать последний этап пути на таком шатком двухмоторном турбовинтовом самолете. И это дало мне прекрасную возможность для чувства превосходства, которого у меня больше никогда не было. Я мог честно сказать: «Доктор Стэнтон, я чувствовал себя в полной безопасности: я сам рассчитал резонансные частоты крыльев». [смех]

Резонансные частоты

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

Если частота вибраций двигателя или внешние аэродинамические воздействия совпадут с резонансной частотой крыла, это может вызвать критические повреждения. Такие события уже происходили в авиации, например, катастрофы из‑за флаттера. Например, Катастрофа L-188 под Баффало в 1959 и через полгода под Каннелтоном.

Зная резонансные частоты, инженеры могут изменять конструкцию крыла, добавляя ребра жесткости или выбирая материалы, которые снизят вероятность резонанса.

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

Расчеты на ARRA и FERTA

Эти вычисления выполнялись с использованием ранних электронных компьютеров ARRA и FERTA. Для Fokker F27, «Friendship», инженеры рассчитывали динамические свойства крыла, чтобы определить, какие внешние воздействия могут вызвать резонанс. Такие работы, по словам Дейкстры, были ключевыми для обеспечения безопасности самолета.

Ф. Франа: Это было то же путешествие, которое вы продолжили по всему земному шару? Вы останавливались в Индии?

Э. Дейкстра: Нет, нет, это была другая поездка, это была поездка в Японию.

Итак, в 1954 году завершилось создание ARRA, в 1955/56 годах я стал программистом. Затем, в 1956 году, произошло много всего. Я получил степень теоретического физика. Как только я решил стать программистом, я закончил учебу как можно быстрее, поскольку я больше не чувствовал себя желанным в университете: физики считали меня «дезертиром», а математики — пренебрежительным и несколько презрительным по отношению к вычислениям.

Все было так, конечно, не так ли? В математической культуре тех времён в Нидерландах вам приходилось иметь дело с бесконечностью, чтобы сделать вашу тему научно уважаемой.

В 1956 году я сделал две важные вещи: я получил свою степень, и у нас было торжественное открытие ARMAC (Automatische Rekenmachine MAthematische Centrum). Нам нужно было провести демонстрацию. ARRA, несколько лет назад, была настолько ненадежной, что единственной безопасной демонстрацией, которую мы осмелились дать, было создание случайных чисел, но для более надежной ARMAC я мог попробовать что‑то более амбициозное.

Математический центр для собственных нужд построил ARMAC, «автоматическую вычислительную машину Математического центра» (1956). Когда страховая компания Nillmij также захотела заказать машину, руководитель центра Ван Вайнгаарден ответил, что Математический центр не является компьютерной фабрикой. Тогда, по мнению страхового агента Энгельфрита, необходимо было создать подобную промышленность. С использованием опыта Математического центра и денег от страховых компаний в 1956 году была основана фирма Electrologica. В 1959 году она поставила свою первую машину — X1.

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

Ф. Франа: Что‑то похожее на проблему семи мостов?

Э. Дейкстра: Нет, это просто кратчайший путь.

Какой есть кратчайший путь, чтобы добраться из Роттердама в Гронинген, в общем: из заданного города в заданный город. Это алгоритм кратчайшего пути, который я разработал примерно за двадцать минут. Однажды утром я ходил по магазинам в Амстердаме со своей молодой невестой, и, уставшие, мы сели на террасу кафе, чтобы выпить чашку кофе, и я просто думал, смогу ли я это сделать, и затем разработал алгоритм кратчайшего пути. Как я уже сказал, это было изобретение за двадцать минут.

На самом деле, он был опубликован в 1959 году, с трехлетним опозданием. Публикация по‑прежнему читабельна, она, по сути, довольно хороша. Одна из причин, по которой она настолько хороша, заключалась в том, что я разработал ее без карандаша и бумаги. Позже я узнал, что одним из преимуществ проектирования без карандаша и бумаги является то, что вы почти вынуждены избегать всех излишних сложностей. В конце концов, этот алгоритм, к моему большому удивлению, стал одним из краеугольных камней моей славы. Я нашел его в начале 60-х годов в немецкой книге по менеджменту — «Das Dijkstrasche Verfahren». Внезапно появился метод, названный в мою честь.

Ф. Франа: Он имеет экономическую ценность.

Э. Дейкстра: Да. И он снова популярен в последнее время, потому что он широко используется во всех планировщиках поездок. Если сегодня вы хотите добраться отсюда дотуда на машине с GPS и экраном, он может показать вам кратчайший путь от вашей гостиницы до Робби Крик {Robbie Creek}. Да?

Ф. Франа: Я действительно сгенерировал маршрут на карте, да, в Интернете.

Э. Дейкстра: Вы использовали ее?

Ф. Франа: Да, я использовал ее.

Э. Дейкстра: Тогда вы использовали мой алгоритм сегодня утром.

Ф. Франа: Когда он был впервые опубликован?

Э. Дейкстра: Он был впервые опубликован в 1959 году в немецкой статье в Numerische Mathematik. Ф. Л. Бауэр основал этот журнал, и он запрашивал статьи.

В то время что‑то вроде алгоритма кратчайшего пути едва ли считалось математикой: существовало конечное число способов добраться из точки А в точку Б, и очевидно, существует кратчайший, так что в чем вся суета?

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

Я сделал это для своих друзей, работающих с оборудованием. Вы знаете, на большой панели вам нужно соединить множество точек одним и тем же медным проводом, потому что у них должно быть одинаковое напряжение. Как минимизировать количество медного провода, соединяющего эти точки? Поэтому я написал статью «Заметка о двух задачах, связанных с графами» или что‑то в этом роде.

Но теперь, когда я пошел к своему офтальмологу — и насколько я знаю, он даже не знал, что я ученый‑информатик — он сказал: «Вы разработали алгоритм для GPS?» Оказалось, он видел «Scientific American» за прошлый ноябрь. Вы задали вопрос…

Ф. Франа: Что вы сделали со своей славой?

Э. Дейкстра: Что я сделал со своей славой? Я был поражен ей!

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

Кроме того, я столкнулся с прерыванием в реальном времени {real‑time interrupt}, и я почти запаниковал. Потому что, видите ли, в течение этих первых пяти лет я всегда программировал для несуществоваших машин, еще несуществовавших машин.

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

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

Любая ошибка в проектировании машины могла сделать всё написанное ПО бесполезным, отсюда выражение «подписывали кровью».

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

Ф. Франа: Невозможно их протестировать?

Э. Дейкстра: Не было способа их протестировать, поэтому вы должны убедить себя в их правильности, рассуждая о них. Конечно, могут быть ошибки в записи, я никогда не претендовал на непогрешимость. Вы должны оставить это экспертам в этой области, таким как Папа Римский. Но простая ошибка в написании не имела значения, пока машины {компьютера} еще не было, и как только ошибки появлялись на машине, их было легко исправить.

Однако в 1957 году я столкнулся с идеей прерывания в реальном времени {real‑time interrupts}, и это создало представление о программе с невоспроизводимыми ошибками, потому что прерывание в реальном времени происходит в непредсказуемый момент. Мои друзья, занимающиеся оборудованием, помогли мне преодолеть сомнения.

Они говорили: «Да, да, мы видим твою проблему, но ты, конечно, должен справиться с ней…» Я научился справляться с этим. Я написал обработчик прерываний в реальном времени, который был безупречным и стал темой моей докторской диссертации.

Обработчик прерываний в реальном времени

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

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

Главная сложность заключалась в том, что прерывания могли происходить в непредсказуемые моменты. Это создавало возможность появления неповторяемых ошибок (non‑reproducible errors), поскольку программа должна была корректно обрабатывать множество вариантов поведения.

Дейкстра создал обработчик прерываний (interrupt handler), который был предназначен для обработки непредвиденных событий в реальном времени без ошибок. Это была важная задача, особенно для работы с вычислительными системами, где критически важна надежность.

Позже я узнал, что здесь {в Америке} это считалось бы почти «не по‑американски».

Ф. Франа: Почему?

Э. Дейкстра: Ну, американская реакция была очень, очень другой. Когда IBM пришлось разрабатывать программное обеспечение для 360, они построили одну или две машины, специально оборудованные монитором. Это дополнительный механизм, который точно записывал бы, когда происходили прерывания и откуда куда. И если что‑то шло не так, можно было воспроизвести это снова и использовать записанную историю, чтобы контролировать, когда будут происходить прерывания. Итак, они сделали это воспроизводимым, да, но ценой гораздо большего количества оборудования, чем мы могли себе позволить. Излишне говорить, что они так и не исправили OS/360.

Дейкстра обсуждает различия между европейским и американским подходами к обработке прерываний, особенно в контексте работы с системой IBM 360.

Почему это важно?

• Подход Дейкстры стал основой для формальной верификации (процесса проверки корректности программного обеспечения относительно заданных спецификаций с использованием математических методов) программного обеспечения и надежного проектирования.

• Метод IBM показал силу инструментов отладки и мониторинга, что особенно актуально для крупных проектов, где полное предсказание невозможно.

Это показывает культурные различия в 1960-х годах: Европа отдавала предпочтение теории и строгой логике, а США — прагматичным решениям.

Ф. Франа: Это правда. Это очень верно.

Э. Дейкстра: Потому что…

Ф. Франа: Это никогда бы не пришло в голову европейцу?

Э. Дейкстра: Нет, мы были слишком бедны.

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

Ф. Франа: Чтобы подумать об этом?

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

---

Конец перевода первой части интервью.

---

_{Использованные источники:}

_{Интервью: Oral history interview with Edsger W. Dijkstra https://works.bepress.com/philip_frana/6/}

_{Сайт: Centrum Wiskunde & Informatica https://cwi.nl}

_{Видео: Remembering ARRA: A pioneer in Dutch computing (English) https://www.youtube.com/watch?v=ph7KyzFafC4}

_{Статья: Een halve eeuw computers in Nederland: https://www.fi.uu.nl/wiskrant/artikelen/223/223maart_alberts.pdf}

_{Статья: De AERA. Gedroomde machines en de praktijk van het rekenwerk aan het Mathematisch Centrum te Amsterdam https://www.researchgate.net/publication/260 983 963_De_AERA_Gedroomde_machines_en_de_praktijk_van_het_rekenwerk_aan_het_Mathematisch_Centrum_te_Amsterdam}