Кодеры за работой. Размышления о ремесле программиста
Шрифт:
По мере того как приложения будут становиться все более и более сложными, построенными на все более и более сложных библиотеках, - и все окончательно перестанут понимать, где в них “дыры” из-за их чрезвычайной сложности, - наверное, нам придется перейти к программированию приложений на менее располагающем к ошибкам языке. Процессоры становятся потрясающе быстрыми, а память - удивительно дешевой. Не могу сказать, какой он - завтрашний язык программирования. Не думаю, что Си или его дальнейшие модификации, вроде C++, станут подходящей платформой, на которой программирование приложений - даже развитие систем - сможет двигаться дальше.
Java не кажется мне выходом. Мои старые рефлексы не подводят. Этот язык неприятно поразил меня своей авторитарностью. Это еще одна причина, по которой я
Впервые попробовав Java - еще совсем молодой тогда язык, - я сказал себе: “А, еще один язык, призванный помочь посредственным программистам встать на путь истинный, ограничивая их”. Но, возможно, сейчас это и правильно. Пожалуй, сегодня опасно полагаться на хороший, гибкий язык, на котором один или два процента программистов смогут писать высокохудожественные программы, потому что в мире уже 75 миллионов штампованных программистов, пишущих чрезвычайно сложные приложения и нуждающихся в помощи. Так что, вероятно, Java - это то, что нужно. Я не знаю.
Сейбел: До вас я брал интервью у Фрэн Аллен, сотрудницы IBM, писавшей компиляторы для Фортрана. Её Си разочаровал совсем другим - тем, что для него невозможно написать хороший оптимизирующий компилятор, потому что язык слишком низкоуровневый.
Козелл: Ну, она из другого лагеря. Она создает компиляторы и видит Си как ужасный, неудобный этап, от которого никуда не денешься. Когда мы работали с ассемблерами, жонглируя битами, Си был просто глотком свежего воздуха. Понятно, что большинство лучших программистов того времени работали не с Бейсиком и не с Фортраном. Самыми крутыми были, конечно же, те, кто писал ассемблерный код. И мы сразу же перешли на Си - это было как небо и земля. Если вы думаете, что это у Си проблемы с границами массивов, попробуйте написать цикл по массиву на ассемблере. Так что здесь это был настоящий прорыв.
Я не хочу сказать, что Си выработал свой ресурс. Но мне кажется, что его использовало так много хороших программистов, что планка стала очень высокой, и их более посредственные коллеги, пытаясь сегодня писать приложения на Си, просто не справляются. Наверное, Си - идеальный язык для по-настоящему хороших системных программистов, но увы, его много используют и программисты похуже, а не стоило бы.
Сейбел: Не кажется ли вам, что суть программирования изменилась из-за того, что мы больше не знаем, как это на самом деле работает?
Козелл: О, да. Это еще одна причина, из-за которой я выгляжу живым динозавром. Ничто не появляется на пустом месте, а развивается из чего-то. Я помню, как на PDP-11 с седьмой версией UNIX мы делали кое-какую анимацию и графику. Это было по-настоящему трудно программировать. Мониторы были громоздкими. Не было библиотек.
Каждое поколение программистов уходит все дальше от того старого оборудования и получает в распоряжение все более совершенные инструменты. Это хорошо, потому что расширяет их возможности. Базовый уровень все выше, а следующий выглядит еще лучше - а через пару лет он сам становится базовым и так далее. Проблема в том, что сложность тоже возрастает. Набор инструкций PDP-1 покажется сущей ерундой по сравнению с тем, что происходит сейчас.
Я бы не хотел оказаться на месте тех ребят из Microsoft, которым приходится создавать операционную систему для четырехъядерного мультипроцессора. Видеокарты развились до такого уровня, что имеют множество мегабайт памяти, а их встроенные процессоры обрабатывают массивы и векторную графику на лету. Сегодняшняя видеокарта - фактически очень мощный обработчик данных. Мне трудно представить, как это программировать.
У нас была когда-то такая вещь, как IMLAC - одна из первых машин, имевших интегрированный векторный дисплей, подобный установленному на старом PDP-1, но в отличие от него это был мини-компьютер. Для него была игрушка: ездишь в маленькой машинке по трехмерному лабиринту и видишь, как приближаются стены, заворачиваешь за углы. Помню, я был поражен тем, что она удаляла невидимые линии. Это было
Работать со скрытыми линиями в те времена было очень трудно, а та программа делала это. Я был просто поражен. Это было что-то уникальное. Могу сказать, что сегодня видеокарты легко оперируют трехмерными координатами и удаляют невидимые линии. Восемь, девять лет назад наложение текстур и трассировка лучей были чрезвычайно сложными, трудно программируемыми задачами. Нужно было потратить часы, чтобы нарисовать блик на сфере.
Современные видеокарты, насколько мне известно, умеют делать трассировку лучей. Так что сегодня, с одной стороны, мы видим разработчиков NVIDIA и подобные чрезвычайно сложные программы обработки видео, с другой - современного программиста, которому мало нарисовать двумерную стену, а нужно создать полноценную ЗБ-среду, основанную на библиотеках, которые становятся все более и более сложными. Работать с ними проще, чем писать код самому, но я все равно не понимаю, как люди справляются. Для меня это слишком сложно.
Я ощутил это, поработав с Тк. Попробовал написать на Тк небольшую программку и был поражен сложностью этой библиотеки и количеством подводных камней, с которыми сталкиваешься, даже прописывая, например, размер кнопки или ее расположение. Это очень сложная работа. Разобраться в системе разделения времени для PDP-1, для сравнения, было гораздо проще.
Так что я не завидую современным программистам, им все труднее и труднее. Простые вещи упаковываются в библиотеки, остаются только сложные. Оборудование становится все совершеннее, а запросы людей - выше и выше. Недавно мне показали кое-что поразительное. Это одна из опций системы прокладки маршрута в Google Maps. Можно захватить мышью и перетащить участок маршрута в другую точку, так чтобы система поняла: путь должен быть проложен через нее. И Google переделывает маршрут соответствующим образом. Теперь я знаю, как это работает: большой кусок кода в JavaScript отслеживает передвижения мыши. Когда отпускаешь кнопку мыши, он формирует запрос на Ajax XML, сообщая материнской системе, что выбран новый пункт маршрута. После этого вычисляется новый маршрут. Я просто не представляю, как это можно было так здорово запрограммировать! Люди жалуются, что им проложили маршрут через огороды и тому подобное, но проблема выбора оптимального маршрута - одна из старейших в компьютерной науке: как найти кратчайший маршрут на произвольном графе? Сногсшибательно.
С одной стороны, я восхищен. С другой, думаю про себя: “Боже, как здорово, что в мои времена такого не было”. Я бы никогда не написал код для решения такой задачи. Как они это делают? Наверное, выросло целое поколение программистов, превосходящих меня. Я рад, что некогда заработал репутацию хорошего программиста и не должен больше ее подтверждать, потому что я бы просто не смог.
Сегодня мне приятно быть этаким почетным старейшиной цеха программистов. Я заслужил это право своими предыдущими успехами и рад, что могу до сих пор пользоваться их плодами без необходимости что-то кому-то доказывать сегодня. Если вы недавно получили компьютерное образование, знаете, как программировать, и готовы сказать в этой профессии свое слово - вам и карты в руки.
15. Дональд Кнут
Из всех героев этой книги Дональд Кнут, пожалуй, меньше всех нуждается в представлении. На протяжении последних 40 лет он пишет свой многотомный шедевр “Искусство программирования” - библию фундаментальных алгоритмов и структур данных. Журнал “American Scientist” включил эту работу в список 12 самых важных естественнонаучных исследований века наряду с произведениями Рассела, Уайтхеда, Эйнштейна, Дирака, Фейнмана и фон Неймана. Кнут популяризировал применение асимптотической нотации (“О” большое) при анализе алгоритмов, изобрел LR-анализатор и защищал операторы перехода GOTO от критики Эдсгера Дейкстры.