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