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

Сейбел: Когда мы говорили о том, как вы создаете программы, вы упоминали процесс разработки снизу вверх. Вы строите эти кирпичики отдельно друг от друга?

Томпсон: Иногда.

Сейбел: А вы пишете тестовые модули для тестирования низкоуровневых функций?

Томпсон: Да, я так часто поступаю. Все зависит от программы, над которой я работаю. Если программа — это транслятор из А в Б, то я предложу целый спектр возможных А и соответствующих Б. Для регрессионного тестирования исполню все варианты А и проверю, насколько им будут соответствовать Б. Компилятор, транслятор, поиск регулярных выражений. Что-то вроде этого. Но есть программы, которые совсем не похожи на эти. Я никогда много не занимался тестированием и в этих программах мало понимаю. Я проведу несколько проверок, но они редко будут значительными, потому что, например, их будет тяжело проводить внутри самой программы. Главным образом это будут просто регрессионные тесты.

Сейбел: Под более сложными для тестирования программами вы понимаете, например, драйверы устройств и сетевые протоколы?

Томпсон: Вообще, они ведь запускаются каждый раз, когда вы запускаете систему.

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

Томпсон: Да, конечно. Что может быть лучше для тестирования операционной системы, чем постоянно запускать ее?

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

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

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

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

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

Сейбел: Есть ли еще такие задачи, для решения которых в целях производительности приходится работать вручную с ассемблером?

Томпсон: Это редкость. Это музейная редкость — разве что вы можете таким образом получить порядковую разницу. Если вы можете усердно работать и заставить маленький кусочек большой программы исполняться в два раза быстрее, то и всю программу можно заставить исполняться в два раза быстрее, если только подождать год-другой. Если вы пишете компилятор, то, безусловно, 99% кода, который вы пишете, будут исполнены один или два раза. Но будет крохотная часть в операционной системе, которая работает 24 часа в день. А еще более крохотная — в самом внутреннем цикле такой системы. Так что, возможно, только 0,1% оптимизации, которую вы применили к компилятору, обернется для ваших пользователей каким-то эффектом. Но притом эффект может оказаться глубоким, так что, возможно, вы все равно захотите эту оптимизацию выполнить.

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

Томпсон: Да, да.

Сейбел: Так что, возможно, часть причин, по которым программы пишут прямо на ассемблере, ныне менее важна, потому что компиляторы стали лучше.

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

Сейбел: Кстати было бы упомянуть сборку мусора. С появлением Java сборка мусора наконец-то пошла в массы. Как однажды сказал Деннис Ричи, Си активно сопротивляется сборке мусора. Хорошо ли, что сейчас наблюдается явная тенденция к языкам со сборкой мусора? Заслуживает ли эта технология настолько массового использования?

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

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

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

Сейбел: Кем вы себя считаете — ученым, инженером, художником, ремесленником или кем-то еще?

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

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

Томпсон: Что-то ближе к низкому уровню. Например, ремесленник, но с творческой жилкой.

Сейбел: Как вы определяете талантливого программиста?

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