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

Сейбел:Вы печатаете инварианты; а используете ли вы утверждения, которые проверяют эти инварианты?

Томпсон:Редко. Мне проще убедить себя, что они правильны, и либо закомментировать вывод на печать, либо отбросить их.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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