хороший оптимизирующий компилятор, потому что язык слишком низкоуровневый.

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

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

Сейбел: Не кажется ли вам, что суть программирования изменилась из-за того, что мы больше не знаем, как это на самом деле работает?

Козелл: О, да. Это еще одна причина, из-за которой я выгляжу живым динозавром. Ничто не появляется на пустом месте, а развивается из чего-то. Я помню, как на PDP-11 с седьмой версией UNIX мы делали кое-какую анимацию и графику. Это было по-настоящему трудно программировать. Мониторы были громоздкими. Не было библиотек.

Каждое поколение программистов уходит все дальше от того старого оборудования и получает в распоряжение все более совершенные инструменты. Это хорошо, потому что расширяет их возможности. Базовый уровень все выше, а следующий выглядит еще лучше - а через пару лет он сам становится базовым и так далее. Проблема в том, что сложность тоже возрастает. Набор инструкций PDP-1 покажется сущей ерундой по сравнению с тем, что происходит сейчас.

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

У нас была когда-то такая вещь, как IMLAC - одна из первых машин, имевших интегрированный векторный дисплей, подобный установленному на старом PDP-1, но в отличие от него это был мини- компьютер. Для него была игрушка: ездишь в маленькой машинке по трехмерному лабиринту и видишь, как приближаются стены, заворачиваешь за углы. Помню, я был поражен тем, что она удаляла невидимые линии. Это было в ту эпоху, когда журнал “Communications of the ACM” публиковал статьи об алгоритмах. У меня была целая книга о том, как использовать симметричные координаты; и я видел написанный кем-то алгоритм, вычислявший, где пересекаются две линии, так что можно было узнать, где линия пересекает плоскость, то есть место, где ее надо уже прекратить рисовать, потому что дальше она не видна.

Работать со скрытыми линиями в те времена было очень трудно, а та программа делала это. Я был просто поражен. Это было что-то уникальное. Могу сказать, что сегодня видеокарты легко оперируют трехмерными координатами и удаляют невидимые линии. Восемь, девять лет назад наложение текстур и трассировка лучей были чрезвычайно сложными, трудно программируемыми задачами. Нужно было потратить часы, чтобы нарисовать блик на сфере.

Современные видеокарты, насколько мне известно, умеют делать трассировку лучей. Так что сегодня, с одной стороны, мы видим разработчиков NVIDIA и подобные чрезвычайно сложные программы обработки видео, с другой - современного программиста, которому мало нарисовать двумерную стену, а нужно создать полноценную ЗБ-среду, основанную на библиотеках, которые становятся все более и более сложными. Работать с ними проще, чем писать код самому, но я все равно не понимаю, как люди справляются. Для меня это слишком сложно.

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

Так что я не завидую современным программистам, им все труднее и труднее. Простые вещи упаковываются в библиотеки, остаются только сложные. Оборудование становится все совершеннее, а запросы людей - выше и выше. Недавно мне показали кое-что поразительное. Это одна из опций системы прокладки маршрута в Google Maps. Можно захватить мышью и перетащить участок маршрута в другую точку, так чтобы система поняла: путь должен быть проложен через нее. И Google переделывает маршрут соответствующим образом. Теперь я знаю, как это работает: большой кусок кода в JavaScript отслеживает передвижения мыши. Когда отпускаешь кнопку мыши, он формирует запрос на Ajax XML, сообщая материнской системе, что выбран новый пункт маршрута. После этого вычисляется новый маршрут. Я просто не представляю, как это можно было так здорово запрограммировать! Люди жалуются, что им проложили маршрут через огороды и тому подобное, но проблема выбора оптимального маршрута - одна из старейших в компьютерной науке: как найти кратчайший маршрут на произвольном графе? Сногсшибательно.

С одной стороны, я восхищен. С другой, думаю про себя: “Боже, как здорово, что в мои времена такого не было”. Я бы никогда не написал код для решения такой задачи. Как они это делают? Наверное, выросло целое поколение программистов, превосходящих меня. Я рад, что некогда заработал репутацию хорошего программиста и не должен больше ее подтверждать, потому что я бы просто не смог.

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

Из всех героев этой книги Дональд Кнут, пожалуй, меньше всех нуждается в представлении. На протяжении последних 40 лет он пишет свой многотомный шедевр “Искусство программирования” - библию фундаментальных алгоритмов и структур данных. Журнал “American Scientist” включил эту работу в список 12 самых важных естественнонаучных исследований века наряду с произведениями Рассела, Уайтхеда, Эйнштейна, Дирака, Фейнмана и фон Неймана. Кнут популяризировал применение асимптотической нотации (“О” большое) при анализе алгоритмов, изобрел LR-анализатор и защищал операторы перехода GOTO от критики Эдсгера Дейкстры.

Но он не просто теоретик. Закончив третий том “Искусства программирования” в 1976 году, Кнут взял перерыв на год, как он тогда думал, собираясь написать системы компьютерной верстки ТеХ и METAFONT, для того чтобы его книги были напечатаны так, как он хотел. Через десять лет он закончил этот проект, попутно изобрел новый стиль программирования - “литературное программирование” - и алгоритм для разбиения абзацев текста на строки, который и по сей день применяется в программах компьютерной верстки.

Среди его многочисленных наград - первая премия имени Грейс Мюррей Хоппер от Ассоциации вычислительной техники (1971), премия Тьюринга (1974) и Национальная научная медаль США (1979). В 1990 году он перестал пользоваться электронной почтой, объясняя это тем, что его работа заключается не в том, чтобы быть “на самом верху”, а в том, чтобы быть “в самом низу”, - именно там можно глубже понимать и затем объяснять в книгах многие области компьютерных наук.

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