Читаем Кодеры за работой полностью

Что касается Adventure, то не думаю, что я на самом деле убрал подпрограммы из программы Дона Вудса, написанной на Фортране, — я взял его программу на Фортране и переписал ее на английском и на Си. Но абсолютно верно то, что если вы взглянете на мой код ТеХ, то увидите, что подпрограмм в стеке около 4-5, тогда как в программе, написанной кем-либо другим — без применения методов литературного программирования, — их может быть и 50, и 100.

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

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

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

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

Кнут:

Конечно. Такое происходит постоянно, но лишь из-за недостаточно высокого качества моих объяснений. Позвольте привести простой пример. В «Искусстве программирования» я пишу о первых применениях побитовых операций, и у меня есть такое предложение: «Компьютер Manchester Mark 1, созданный примерно в то же время, что и EDSAC, использовал не только побитовые операторы И, но также ИЛИ и исключающее ИЛИ. В его первом руководстве программиста, написанном в 1950 году, Алан Тьюринг отмечал, что побитовый оператор НЕ может быть получен с помощью исключающего ИЛИ или в сочетании с несколькими подобными операторами».

То есть во фразе «В его первом руководстве программиста Алан Тьюринг...» речь идет о первом руководстве программиста для компьютера Manchester Mark 1. Но четверо или пятеро человек, прочитавших это предложение, независимо друг от друга заявили, что поняли фразу в том смысле, что в 1950 году Алан Тьюринг написал свое первое руководство программиста.

На самом деле у него были и другие руководства по программированию, поэтому я написал все правильно, но фраза была неправильно истолкована людьми. Поэтому я исправил ее следующим образом: «В первом руководстве по программированию для компьютера Mark I, написанном в 1950 году, Алан Тьюринг отмечал...»

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

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

Кнут: Нет. Хорошая литературная программа всегда покажет свою историю. Хорошая литературная программа всегда скажет: «Вот очевидный способ выполнения данной задачи — почему бы нам им не воспользоваться?»

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

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

Сейбел: То есть это чаще встречается не в коде, а в тексте?

Кнут: Да, речь о текстовой части. Я не показываю код, который исключил из программы. Хотя мог бы.

Перейти на страницу:

Все книги серии Профессионально

Кодеры за работой
Кодеры за работой

Программисты — люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они «подсели» на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

Питер Сейбел

Биографии и Мемуары / Программирование / Прочая компьютерная литература / Документальное / Книги по IT
Человеческий фактор
Человеческий фактор

Немногие книги о компьютерах оказали такое заметное влияние на управление разработкой программного обеспечения, как «Человеческий фактор». Уникальное озарение этой книги, долгие годы сохранявшей свое положение в списке бестселлеров: самые сложные проблемы разработки ПО носят не технологический, а социальный характер. Эти человеческие проблемы решать не просто, однако, решив их, вы увеличите шансы на успех до верхнего предела.В третьем издании появилось шесть новых глав и внесены многочисленные правки в основной текст, так что теперь книга лучше соответствует современным средам разработки и современным проблемам. В частности, обсуждаются патологии лидерства, которые раньше за патологии не считались, эволюционирующая культура собраний, а еще растущее понимание того, что некоторые наши инструменты служат скорее якорями, а не двигателями. Каждый, кому необходимо управлять проектом по разработке ПО или целой организацией такого рода, найдет на страницах этой книги множество ценных советов.

Тимоти Листер , Том ДеМарко

Деловая литература
97 этюдов для программистов. Опыт ведущих экспертов
97 этюдов для программистов. Опыт ведущих экспертов

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

Пит Гудлиф

Программирование, программы, базы данных

Похожие книги