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

Сейбел: Но практически все языки на самом деле префиксные, не считая небольшого количества арифметических операторов.

Дойч: Это не совсем так. Если говорить о Python, например, то это неверно для создания списков, кортежей и словарей. Это делается с помощью скобок. Построковое форматирование — инфиксное.

Сейбел: Так же, как и в Common Lisp — с помощью команды FORMAT.

Дойч: Ну хорошо, ладно. Но есть вещи, которые не делаются с помощью инфиксов; самые простые — циклы и условные операторы — не префиксные. Они выполняются с помощью чередующихся ключевых слов и того, к чему они применяются. В этом отношении они даже более многословны, чем Лисп. И здесь я перехожу к другой части, другой причине, по которой мне больше нравится синтаксис Python, — Лисп очень однообразен в лексическом плане.

Сейбел: Кажется, Ларри Уолл сравнил этот язык с тарелкой овсяных хлопьев, перемешанных с обрезками ногтей.

Дойч: Ну, я бы описал подобным образом Perl, только еще добавил бы, что все это вышло из собаки, причем понятно, откуда именно. На мой взгляд, силе духа Ларри Уолла можно позавидовать, если он еще позволяет себе высказывать какие-то мысли о разработке языков программирования, ведь Perl — просто отвратительный язык. Но не будем об этом.

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

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

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

Сейбел: Да, именно так.

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

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

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

Дойч: Да, это так.

Сейбел: В моей книге о Лиспе есть глава, посвященная синтаксическому анализу двоичных файлов, и я привожу в качестве примера ID3-теги в МРЗ-файлах. Что здесь интересно — можно программировать так: выбираете спецификацию, в этом случае ID3, помещаете ее в скобки и делаете из нее код, который вам нужен.

Дойч: Верно.

Сейбел: То есть мое описание парсинга ID3-заголовка по сути содержит столько же токенов, сколько и спецификация ID3-заголовка.

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

Связь между созданием класса и наименованием метода осуществляется в общем родителе. То есть это все делается в объектно-ориентированном стиле — макросы не требуются. Это выглядит не так красиво, как можно было бы сделать иным способом, но на выходе получается примерно так же читаемо, как и аналогичные макросы Лиспа. Есть вещи, которые на Лиспе делаются более гладко и внятно. С этим я не спорю.

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

Что касается Python, то и здесь мне приходилось делать небольшие дополнения. Это не синтаксические дополнения; это классы, примеси[70] — многие из этих примесей дополняют то, что большинство людей привыкло считать семантикой языка. В Python за это отвечает один набор инструментов, в Лиспе — другой. Кому-то нравится одно, кому-то другое.

Сейбел: Что заставило вас отказаться от программирования и заняться сочинением музыки?

Дойч: По большому счету, я «перегорел» во время работы над Ghostscript. Ghostscript был одним из моих основных технических интересов с 1986 года, а где-то с 1992-1993 года был моим единственным крупным техническим проектом. Примерно в 1998 году я почувствовал, что сгораю, потому что не только делал всю техническую работу, но и занимался всей технической поддержкой, всеми административными вопросами. Это была компания из одного человека, и рано или поздно это должно было превысить мои возможности. Я нанял человека, чтобы создать компанию, и он стал нанимать инженеров.

После чего понадобилось еще два года, чтобы найти человека, который смог бы меня заменить. После чего потребовалось еще два года, чтобы по-настоящему передать ему все дела. К 2002 году я уже «наелся». Я уже не мог больше видеть Ghostscript.

Поэтому я сказал: «Ладно, отдохну полгодика, осмотрюсь и решу, чем заняться дальше». Мне тогда было 55 лет, и я не чувствовал себя старым. Я чувствовал, что могу сделать еще один крупный проект, если захочу что-то сделать. Поэтому я стал смотреть, что же происходит вокруг.

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

И вот была эта небольшая преуспевающая группа, которая доказывала теоремы; я о них писал в своей диссертации, и мне всегда это было интересно. И они добились потрясающего результата, работая над арифметическим блоком центрального процессора AMD. И я подумал: «Хм, эта группа обладает множеством хороших качеств: они занимаются интересными мне вещами; ими управляет человек, с которым я знаком и который мне нравится; их технология базируется на Лиспе. Это действительно по мне».

Поэтому я отправился туда и прочитал там лекцию о том, как доказывание теорем могло бы — если, конечно, могло в принципе — помочь повысить уровень надежности Ghostscript. К тому времени у системы отслеживания ошибок Ghostscript была уже богатая история. Я нашел 20 ошибок, более или менее в произвольном порядке, взглянул на каждую из них и сказал: «Так, для того чтобы технологию доказывания теорем можно было бы с пользой применять для обнаружения или предотвращения этой проблемы, что должно еще произойти? Что здесь еще должно было бы появиться?»

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