Кодеры за работой. Размышления о ремесле программиста - Сейбел Питер
Я лишь немного занимался этим в Стэнфордском университете с группой студентов. Они писали программы в качестве летнего проекта, и я познакомил их с идеей литературного программирования. В то лето у меня была группа лишь из семи человек. Шестерым из них эта идея настолько понравилась, что они применяют ее до сих пор. Седьмой ее ненавидел. Его представление о литературной программе было следующим: он брал обычную программу, сверху создавал надстройку и говорил: «Это модуль номер один», — и так далее. Конечно, в Стэнфорд принимают тех, кто умеет хорошо писать, то есть это не вполне репрезентативный пример.
Сейбел: Вам когда-нибудь приходилось писать литературную программу, которую вы коренным образом перестраивали, чтобы объяснить ее? Просто мне трудно представить, что поток сознания всегда является наилучшим принципом организации материала.
Кнут: Такого практически никогда не было. Не помню, чтобы мне приходилось брать и действительно менять порядок частей. Просто у меня всегда было так, что я даже не задумывался над тем, какую задачу решать дальше. Не могу этого объяснить точно, но у меня такое ощущение, что одно просто плавно перетекало в другое.
Сейбел: Пишете ли вы литературный код для программ, которые никто кроме вас никогда не увидит?
Кнут: Конечно. Именно этим литературное программирование и хорошо — я могу разговаривать с самим собой. Я могу прочитать программу год спустя и точно понять, о чем я тогда думал.
Сейбел: Всегда ли этот метод работает?
Кнут: На самом деле, достаточно часто труднее понимать программу год спустя, чем до этого. Но это несравнимо с тем, что у меня было до того, как я придумал литературное программирование. Оно не делает сложную вещь очевидной — просто лучшего метода я не знаю.
Я недавно распечатал небольшой комплект больших коллекций подпрограмм, написанных на Си, которые в общем-то отражают текущее состояние дел в работе с булевыми схемами решений (BDD). Это полная противоположность CWEB; практически все во всем мире разрабатывают пакеты программ именно так. Делается это с помощью достаточно упорядоченных соглашений по комментированию, которые понимаются широким сообществом. И код не так уж труден для понимания, поскольку он логически разделен, в нем есть заголовочные файлы, и вы можете видеть структуры данных, и к каждой части структуры данных даны комментарии, поясняющие тот или иной момент. Это еще один вполне эффективный стиль программирования.
Тем не менее я уверен в том, что этот метод далеко не столь эффективен, как литературное программирование, в силу множества неосязаемых вещей, которые я не могу доказать. Наиболее убедительным аргументом для меня является моя уверенность в том, что некоторые из написанных мною программ я никогда бы не смог написать без методов литературного программирования. Например, создание эмулятора MMIX стало бы для меня такой чудовищной головоломкой, что если бы мне пришлось работать над ним с помощью обычного метода, то не думаю, что мне удалось бы его завершить. Обычного разделения его на подпрограммы было недостаточно для того, чтобы упростить его, сделав удобным для восприятия и работы с ним.
Этот эмулятор учитывает наиболее общим образом спецификацию компьютера: какими функциональными блоками он обладает, сколько инструкций может выполнять одновременно, каковы его стратегии кэширования, как работает шина и устройство вывода, каким образом производится прогнозирование ветвления и как работает конвейер.
Вы можете придумать компьютер с шестью блоками деления и конвейером, состоящим из определенного количества стадий, и сэмулировать его. Будете ли вы быстрее вычислять простые числа с таким компьютером? Вам не нужно создавать такой компьютер.
Я не утверждаю, что невозможно взять эту программу и разбить ее на подпрограммы, но я бы никогда не смог ее выполнить подобным образом. Кроме того, код занимает всего 170 страниц, и он понятен — я не единственный в мире человек, который его понимает.
Сейбел: Я читал повторную реализацию игры Adventure, осуществленную вами с помощью методов литературного программирования; она мне показалась слегка монолитной. Это было похоже на стиль литературного программирования, поскольку тут вы можете интерполировать объекты и совсем не думать о том, чтобы разбить ее на подпрограммы.
Кнут: Верно. Вместо того чтобы вызывать подпрограмму, мы как будто имеем встроенные подпрограммы на протяжении всей программы. Идея подпрограммы по-прежнему используется, но в итоговом варианте вашей программы подпрограмм нет. Это больше походит на макросы. Но суть в том, что на уровне понятий механизм вызова подпрограмм не нужен, если у вас есть иной способ реализации этой функции на языке, который вы используете.
Что касается Adventure, то не думаю, что я на самом деле убрал подпрограммы из программы Дона Вудса, написанной на Фортране, — я взял его программу на Фортране и переписал ее на английском и на Си. Но абсолютно верно то, что если вы взглянете на мой код ТеХ, то увидите, что подпрограмм в стеке около 4-5, тогда как в программе, написанной кем-либо другим — без применения методов литературного программирования, — их может быть и 50, и 100.
Я пытаюсь работать с блоками, которые соотносятся с моим мыслительным процессом, а не подчиняюсь каким-то логическим принципам работы с формальной системой. Я хочу, чтобы мои программы соответствовали моему интуитивному процессу их создания, а не чьей-либо жестко закрепленной схеме.
Естественно, в конечном счете она должна быть перенесена на компьютер, у которого есть жесткие рамки, четкие правила понимания. Но в моем представлении хорошая и правильная программа должна наиболее точно передавать образ моих мыслей, а не принцип работы компьютера. Мне нужно найти способ перехода из одного состояния в другое, но я стремлюсь сохранять исходные тексты ближе к своей голове, чем к компьютеру.
Кроме того, я убежден, что литературное программирование — это очень эффективный способ ведения документации, обеспечивающий связь между группами людей. Многие люди понимали код ТеХ настолько хорошо, что могли создавать сценарии, при которых в программе происходил сбой. Мне кажется, что еще больше людей в какой-то из моментов своей жизни понимали именно эту программу, а не любую другую программу схожего размера.
Сейбел: И тем не менее сталкивались ли вы когда-нибудь с такими ситуациями, в которых люди читали ваш код и все равно задавали вам вопросы, заставлявшие вас думать: «Неужели они действительно тут что-то не поняли?»
Кнут: Конечно. Такое происходит постоянно, но лишь из-за недостаточно высокого качества моих объяснений. Позвольте привести простой пример. В «Искусстве программирования» я пишу о первых применениях побитовых операций, и у меня есть такое предложение: «Компьютер Manchester Mark 1, созданный примерно в то же время, что и EDSAC, использовал не только побитовые операторы И, но также ИЛИ и исключающее ИЛИ. В его первом руководстве программиста, написанном в 1950 году, Алан Тьюринг отмечал, что побитовый оператор НЕ может быть получен с помощью исключающего ИЛИ или в сочетании с несколькими подобными операторами».
То есть во фразе «В его первом руководстве программиста Алан Тьюринг...» речь идет о первом руководстве программиста для компьютера Manchester Mark 1. Но четверо или пятеро человек, прочитавших это предложение, независимо друг от друга заявили, что поняли фразу в том смысле, что в 1950 году Алан Тьюринг написал свое первое руководство программиста.
На самом деле у него были и другие руководства по программированию, поэтому я написал все правильно, но фраза была неправильно истолкована людьми. Поэтому я исправил ее следующим образом: «В первом руководстве по программированию для компьютера Mark I, написанном в 1950 году, Алан Тьюринг отмечал...»
То же касается и чисто математических моментов — ко мне обращаются люди, которые их не понимают. Поэтому я скажу так: как правило, я все пишу верно, но знаю, что мне тем не менее нужно эти моменты исправлять и улучшать.
