Кодеры за работой. Размышления о ремесле программиста - Сейбел Питер

Вот, если вкратце, что я думаю о Си. Уверен, что есть хорошие программисты, возможно, и я в их числе, которые могут писать на этом языке хорошие программы. Но это дается нам труднее, чем должно было быть. В современном мире эта проблема усугубилась, потому что вокруг становится все больше и больше программ на Си, и у программистов все больше работы по преодолению их недостатков. Это одна из причин, по которым мне нравится программировать на Perl. Perl медленный. Думаю, это один из самых медленных языков программирования, но зато в нем нет тех проблем с безопасностью, которые есть в Си. Что происходит в Perl, если информация не влезает в массив? Массив увеличивается в размерах, только и всего.

Этот язык знает, куда указывают его указатели, так что вы никогда не сможете «сбиться с пути»: нужно просто сказать системе, чтобы проследила путь и узнала, куда он ведет. Я уверен в этом языке, потому что на протяжении многих лет люди работают с его ядром, и оно очень стабильно. Не думаю, что в написанных на нем программах попадается много ошибок выделения памяти или проблем с указателями; фактически их вообще трудно допустить в коде Perl. He приходится надеяться только на программистов.

И даже после этого бывают случаи вроде того хрестоматийного, когда кто-то написал веб-страницу, искавшую имена в таблицах, а неизвестный хакер написал в строке ввода что-то вроде «Joe;drop all tables». Такое еще случается. Это, конечно, не вина языка Си, но видно, что программисты подчас бывают недостаточно осторожны. Они не продумывают все варианты, а в Си их слишком много. Все это кажется мне слишком опасным. Справедливости ради нужно добавить, что я программировал на Си на пять лет меньше Кена. Мы с ним в разных весовых категориях, но все же у меня большой опыт общения с Си, я знаю, как это непросто, и думаю, что дело тут, по большей части, в самом языке.

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

Java не кажется мне выходом. Мои старые рефлексы не подводят. Этот язык неприятно поразил меня своей авторитарностью. Это еще одна причина, по которой я хвалю Perl, — он безопасный, надежный и при этом чертовски разнообразный, так что художник во мне получает достаточное поле для самовыражения и выбора оптимальных путей. Я свободен.

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

Сейбел: До вас я брал интервью у Фрэн Аллен, сотрудницы IBM, писавшей компиляторы для Фортрана. Её Си разочаровал совсем другим — тем, что для него невозможно написать хороший оптимизирующий компилятор, потому что язык слишком низкоуровневый.

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

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

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

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

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

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

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

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

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

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