Никлаус Вирт

Выступление при получении премии Тьюринга

Очень приятно получить премию Тьюринга; высокая оценка работы, проделанной за столько лет, одновременно радует и ободряет. Мне хотелось бы поблагодарить АСМ за присуждение этой престижной премии. Особенно приятно, что я получаю ее в Сан-Франциско, где начиналась моя профессиональная деятельность.

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

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

Конечно, когда я вступил в компьютерную область в 1960 г., она не была ни в самом центре коммерческого внимания, ни в университетских программах. Во время моего обучения в Швейцарском Федеральном Технологическом институте (ЕТН) единственное, что я слышал о компьютерах,— факультативный курс профессора Амброса Р. Спейсера, который позднее стал президентом ИФИП. Разработанный им компьютер ERMETH был мало доступен обычным студентам, и по этой причине мое приобщение к компьютерной сфере отложилось до тех времен, когда я стал слушать курс численного анализа в университете Лаваля в Канаде. Но, увы, машина Alvac 3Е большую часть времени не работала, и упражнения в программировании оставались на бумаге в виде непроверяемых последовательностей шестнадцатеричных кодов.

Моя следующая попытка была несколько более успешной: в Беркли я был поставлен перед любимой машиной Гари Хаски, компьютером Bendix G-15. Хотя Bendix G-15 обеспечивал определенное чувство успеха, выдавая результаты, казалось, что суть искусства программирования состоит в разумном размещении инструкций на барабане. Если это искусство игнорировалось, то программы могли выполняться в сто раз медленнее. Но польза от обучения была очевидной: нельзя было позволить себе игнорировать мельчайшие детали. Не было возможности прикрыть недостатки вашего проекта простой покупкой большей памяти. Оглядываясь назад, можно сказать, что самой привлекательной чертой являлось то, что все детали машины были видны и могли быть поняты. Ничего еще не было спрятано внутри электронных схем, СБИС или магической операционной системы.

С другой стороны, было очевидно, что компьютеры будущего должны программироваться более эффективно. Поэтому я отказался от мысли изучить разработку аппаратуры ради изучения того, как использовать ее более элегантно. Мне повезло, что я вступил в исследовательскую группу, которая была занята разработкой — или скорее улучшением — компилятора и его использованием на IBM 704. Язык был назван НИЛИАКом, это был диалект АЛГОЛа 58. Выгоды, которые давал такой «язык», быстро стали очевидными, но задача автоматической трансляции программ в машинный код поставила бросившие нам вызов проблемы. Это как раз то, что ищешь, добиваясь степени доктора. Компилятор, написанный на языке НЕЛИАК, был сильно запутан. Казалось, что эта дисциплина состоит на один процент из науки и на 99 процентов из колдовства, и этот перекос нужно было менять. Становилось ясно, что программы должны разрабатываться в соответствии с теми же принципами, что и электронные схемы, т. е. должно быть четкое подразделение на части, через границы которых проходят только несколько проводников. Только понимание в каждый момент времени одной части дает надежду в конце понять все в целом.

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

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

Эйлер привлек внимание Рабочей Группы ИФИП, которая занималась составлением планов на будущее АЛГОЛа. Язык АЛГОЛ 60, разработанный специалистами по вычислительной математике и, для специалистов в этой области, имел систематическую структуру и четкое определение, что, хотя ему недоставало компиляторов и промышленной поддержки, было высоко оценено теми, кто имел математическую подготовку. Чтобы получить признание, он должен был расширить свою область применения. Рабочая Группа взяла на себя задачу подобрать наследника, но скоро разделилась на дав лагеря. С одной стороны были те, кто намеревался установить еще одну веху на пути разработки языков, а с другой стороны—те, кто чувствовал, что время поджимает и подходящее расширение АЛГОЛа 60 было бы плодотворной попыткой. Я принадлежал к этой второй группе и внес предложение, которое при голосовании провалилось. Начиная с этого времени, мое предложение несколько раз улучшалось за счет вклада Тони Хоара (члена той же группы) и было реализовано на первой IBM 360 Стенфордского университета. Язык стал позднее известен как АЛГОЛ W и был использован в нескольких университетах для целей обучения.

Стоит упомянуть небольшой промежуточный этап в этих значительных по объему усилиях по реализации. Новая IBM 360 предоставляла только ассемблер и, конечно, Фортран. Ни тот, ни другой, ни я, ни мои аспиранты не очень хотели иметь в качестве инструмента для разработки компилятора. Поэтому я набрался храбрости определить еще один язык, на котором планировалось написать компилятор АЛГОЛа: был достигнут компромисс между АЛГОЛом и возможностями, предоставляемыми ассемблером, это был машинный язык с алголоподобными структурой операторов и объявлениями. Стоит отметить, что язык был определен за пару недель; я написал кросскомпилятор на компьютере Burroughs В-5000 за четыре месяца, а усердный студент за такой же срок перенес его на IBM 360. Этот предварительный этап помог значительно ускорить работы по АЛГОЛу. Хотя он считался полезным лишь для наших собственных текущих потребностей, после чего его следовало отбросить, он быстро получил собственную жизнь. ПЛ360 для многих стал эффективным средством и вдохновил сходные разработки для других машин.

По иронии судьбы успех ПЛ360 был одновременно признаком неудачи АЛГОЛа W. Область применения АЛГОЛа была расширена, но как инструмент для системного программирования он все еще имел очевидные недостатки. Возникли проблемы: как удовлетворить одним языком многочисленным требованиям? Сама цель стала сомнительной. ПЛ/1, выпущенный примерно в то же время, обеспечил еще одно доказательство этого утверждения. Идея «единого ножа для швейцарской армии» имеет свои достоинства, но когда ее доводят до абсурда, этот нож становится камнем на шее. Кроме того, размер компилятора АЛГОЛа W вырос за пределы, в которых можно чувствовать себя мысленно охватившим и понимающим всю программу. Желание добиться более строгого и в то же время более подходящего для системного программирования формализма не было осуществлено. Системное программирование требует эффективного компилятора, генерирующего эффективный код, который работает без зафиксированного, постоянного, скрытого и объемного так называемого пакета периода исполнения. Этой цели не достиг ни АЛГОЛ W, ни ПЛ/ 1 — оба по причине сложности языка и неадекватности целевого компьютера.

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

Порою декларируется, что Паскаль был разработан как язык для обучения. Хотя это правильно, его использование в обучении было единственной целью. В действительное я не верю в использование в обучении таких средств и формализмов, которые не годятся для кaкoй-нибудь практической задачи. По сегодняшним стандартам Паскаль имеет очевидные недостатки для программирования больших систем, но 15 лет назад он представлял собой разумный компромисс между тем, что было желанно, и тем, что было эффективно. В ЕTH мы ввели Паскаль в классы для занятия программированием в 1972 г., несмотря на существование значительной оппозиции. Это имело успех, так как дало возможность преподавателю концентрировать внимание скорее на структурах и общих представлениях, чем на особенностях и странностях, т. е. скорее на принципах, чем на технике.

Наш первый компилятор Паскаля был реализован для семейства компьютеров CDC6000. Он был написан на самом Паскале. Никакого ПЛ6000 не потребовалось, и я рассматривал это как существенный шаг вперед. Тем не менее, генерируемый код определенно уступал коду, генерируемому компиляторами Фортрана для соответствующих программ. Скорость является существенным и легко измеряемым критерием, и мы полагали, что обоснованность концепции языка высокого уровня будет принята промышленностью только в том случае, если потери производительности исчезнут или, по крайней мере, уменьшатся. Имея это в виду, была предпринята вторая попытка, по существу одним человеком, чтобы получить высококачественный компилятор. Цель была достигнута Урсом Амманом в 1974 г., и этот компилятор был затем широко распространен во многих университетах и отраслях промышленности. Однако цена была высока: усилия по генерации хорошего (т. е. даже не оптимального) кода пропорциональны несоответствию между языком и машиной, a CDC6000 разрабатывалась, конечно, не с прицелом на языки высокого уровня.

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

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

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

К 1976 г. мне несколько надоели языки программирования и тщетные попытки создать хорошие компиляторы для существующих компьютеров, разработанных для старомодного «ручного» кодирования. К счастью, я получил возможность провести свой свободный от лекций год (предоставляется раз в семь лет — прим. переводчика) в исследовательской лаборатории корпорации Ксерокс в Пало Альто, где идея мощной персональной рабочей станции не только впервые появилась, но и была практически реализована. Вместо того, чтобы делить со многими другими единый большой компьютер и бороться за свою долю через провод с полосой частот в 3 кГц, я теперь пользовался собственным компьютером, расположенным под моим столом, с каналом более чем 15 МГц. Влияние увеличения в 5000 раз невозможно себе представить ни в одной области: оно поразительно. Более всего меня воодушевлял тот факт, что после 16 лет моей работы на компьютеры теперь, казалось, что компьютер работает на меня. Впервые я вел ежедневную корреспонденцию и писал отчеты с помощью компьютера вместо того, чтобы проектировать новые языки, компиляторы и программы для использования их другими. Еще одним откровением было то, что компилятор для языка Меса, сложность которого намного превосходила сложность Паскаля, мог быть реализован на такой рабочей станции. Эти новые условия работы на столько порядков превосходили то, с чем я был знаком дома, что я решил попытаться там установить такое же окружение.

Наконец-то я решил окунуться в разработку аппаратуры. Это решение было подкреплено моим старым отвращением к существующим архитектурам компьютеров, которые делали жалкой жизнь разработчика компиляторов, если у него была склонность к систематичности и простоте. Мысль разработать и построить целиком компьютерную систему, состоящую из аппаратуры, микрокода, компилятора, операционной системы и программных утилит, быстро оформилась в моем воображении — разработка, которая будет свободна от любых ограничений, требующих совместимости с PDP-11 или IBM 360, Фортраном, Паскалем, Юниксом или каким-нибудь еще другим объявившимся сегодня увлечением или стандартом, исходящим от какого-нибудь комитета.

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

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

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

Ограничив себя одним языком, я очутился перед трудным выбором, последствия которого будут сказываться в широкой области — речь идет о выборе языка. Из существующих языков ни один меня не привлекал. Они не могли ни удовлетворить всем требованиям, ни понравиться разработчику компилятора, знающему, что его задача должна быть выполнена в разумный промежуток времени. В частности, язык должен был быть приспособлен ко всем нашим пожеланиям относительно возможностей структурирования, основанным на десятилетнем опыте работы с Паскалем, и он должен был обслуживать ситуации, которые до сих пор обрабатывались только с помощью кодирования на ассемблере. Короче говоря, выбор состоял в том, чтобы разработать потомка обоих яаыков: как хорошо зарекомендовавшего себя Паскаля, так и экспериментальной Модулы. Он был назван Модула-2. Модуль — это ключевое средство для подведения под одну крышу противоречивых требований: высокого уровня абстракции для обеспечения безопасности, которая достигается избыточными проверками, и средств низкого уровня, которые позволяют обеспечить доступ к индивидуальным свойствам конкретного компьютера. Он позволяет программисту скрывать в нескольких небольших частях системы использование средств низкого уровня, тем самым защищая его от попадания в их ловушки в самых неожиданных местах.

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

Это различие почти исчезает, а вместе с ним исчезает и тяжесть монолитного, громоздкого резидентного блока кода, с которым все вынуждены мириться, хотя он всем мешает. Более того, проект Лилит доказал выгодность хорошо соответствующих друг другу разработок аппаратуры и программного обеспечения. Эта выгода может быть измерена в терминах скорости. Сравнения времени выполнения программ на Модуле показали, что Лилит часто превосходит VAX 750, чья сложность и стоимость в несколько раз превосходят сложность и стоимость Лилита. Их также можно измерять в терминах пространства: код программ на Модуле для Лилита короче кода для PDP-11, VAX или М68000 в 2—3 раза и короче кода для NS 32000 в 1,5—2 раза. Кроме того, кодогенерирующие части компиляторов для этих микропроцессоров значительно сложнее, чем для Лилита, из-за малоподходящего набора их команд. Это увеличение длины должно быть умножено на низкую плотность кода, что бросает мрачную тень на сильно рекламируемое соответствие современных микропроцессоров языкам высокого уровня и показывает, что их претензии сильно преувеличены.

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

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

Раньше чем закончить, разрешите мне попытаться выделить общие характеристики упомянутых мною проектов. Очень важным техническим приемом, который редко используется где-нибудь столь эффективно, как в информатике, является раскрутка. Мы использовали ее фактически во всех проектах. При разработке инструментальных средств, будь то язык программирования, компилятор или компьютер, я разрабатывал его таким образом, что он оказывался полезным уже на следующем шаге: ПЛ360 был разработан для реализации АЛГОЛа W; Паскаль — для реализации Паскаля П; Модула-2 — для реализации всего программного обеспечения рабочей станции, Лилит — для обеспечения подходящего окружения всей нашей будущей работы — от программирования до разработки и документирования электронных схем, от подготовки докладов до разработки шрифтов. Раскрутка..— это самый эффективный способ извлечь выгоду благодаря собственным усилиям, так же как пострадать от собственных ошибок.

Это обязательно заставляет рано проводить разделительную черту между тем, что существенно, и тем, что преходяще. Я всегда пытался выявить то, что является существенным, дает неоспоримые преимущества, и сосредоточить на этом свое внимание. Например, я считаю существенным включение в язык программирования последовательной и согласованной системы объявлений типов данных, в то время как особенности разных видов оператора FOR либо способность компилятора различать большие и малые буквы — это вопросы малосущественные. В разработке компьютеров я считаю решающим выбор видов адресации и обеспечение полноты и согласованности наборов (со знаком и без знака) арифметических команд, включающих надлежащие прерывания при переполнении; в противоположность этому, особенности механизма многоканальных прерываний, их приоритеты гораздо менее существенны. Еще важнее обеспечить, чтобы несущественное никогда не сталкивалось с систематической, структурированной разработкой основных свойств. Несущественное лучше добавлять, приспосабливая к уже существующей, хорошо структурированной основе.

Иногда трудно противостоять давлению, оказываемому для включения различных возможностей, которые «тоже было бы неплохо иметь в наличии». Вполне реальна опасность, что желание угодить всем будет мешать задаче получить целостный проект. Я всегда старался выяснить, какую цену придется заплатить за получаемый выигрыш. Например, когда рассматривается включение некоторого свойства языка или добавление особого режима компиляции для достаточно часто встречающейся конструкции, нужно сопоставить получаемую выгоду и дополнительную стоимость его реализации и просто его присутствия, которое ведет к увеличению системы. Разработчики языка при этом часто терпят неудачу. Я охотно допускаю, что некоторые свойства Ады, для которых нет соответствия в Модуле-2, иногда хорошо иметь, но в то же время я сомневаюсь, что они оправдывают свою цену. А цена значительная: во-первых, хотя разработка обоих языков началась в 1971.1., компиляторы Ады только теперь начали появляться, в то время как мы используем Модулу с 1979 г. Во-вторых, говорят, что компиляторы Ады — это гигантские программы, состоящие из сотен тысяч строк кода, в то время как наш последний компилятор Модулы имеет размер всего порядка пяти тысяч строк. Я по секрету сознаюсь, что этот компилятор с Модулы уже на пределе допустимой сложности, и я бы чувствовал себя совершенно неспособным создать хороший компилятор для Ады. Даже если можно было бы игнорировать усилия, направленные на построение ненужно больших систем, и стоимость памяти, содержащей их код, все равно реальная стоимость прячется в невидимых усилиях бесчисленных программистов, отчаянно пытающихся понять и использовать эти системы эффективно.

Другой общей характеристикой обрисованных проектов явился выбор инструментов. Я убежден, что инструмент должен соответствовать результатам; он должен быть таким простым, как только возможно, но не проще. Когда значительную часть всего проекта берутся одолеть этим инструментом, то он в действительности становится непродуктивным. В проектах Эйлера, АЛГОЛа W, ПЛ360 уделялось много внимания развитию методов таблично управляемого восходящего анализа. Позднее я переключился опять на простой нисходящий метод рекурсивного спуска, легко понятный и, без сомнения, достаточно мощный, если синтаксис языка выбран разумно. При разработке аппаратуры Лилит мы ограничили себя хорошим осциллографом, только изредка требовался логический анализатор. Это было возможно благодаря относительно систематическому, без трюков, общему представлению о процессоре.

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

И последнее. Каждый из этих проектов был доведен до конца благодаря энтузиазму и желанию преуспеть, основанных на знании, что эти усилия имеют смысл. Это, возможно, самая существенная, но в то же время самая неуловимая и трудно проверяемая предпосылка успеха. Мне повезло иметь членов бригады, которые заражались энтузиазмом, и я пользуюсь этим удобным случаем, чтобы поблагодарить их всех за ценный вклад в общее дело. Моя искренняя благодарность относится ко всем, кто принимал участие, будь то непосредственная работа в группе или косвенное участие: испытание наших результатов и обеспечение обратной связи, содействие появлению идей через критику или одобрение или создание общества пользователей'. Без них ни АЛГОЛ W, ни Паскаль, ни Модула-2, ни Лилит не стали бы тем, чем они стали. Этой премии Тьюринга удостоен и вклад моих соратников.

перевод с англ. Б. Я. Левин
публикация в Интернет подготовлена Т. Ю. Сушниковой