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

Мне кажется, что прогресс неизбежен, что он затронет языки программирования. И поэтому разговоры о «втором золотом веке» я воспринимаю как должное. Просто пока не установлена связь между пользователями языков и потенциальными разработчиками из числа ученых, способными создать действительно революционный язык.

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

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

Это соблазнительно — поизучать что-нибудь систематически, и может быть, даже не особо напрягаясь. Выход на рынок, зависимость от закона Мура, конкуренция, короткий жизненный цикл продукта, одноразовые программы — все это тягостно, если в этом варятся все. Поэтому тем, кто хочет получить степень, кто имеет для этого нужные навыки, всегда будет чем заняться. Есть интересные области для исследования. Мы в Mozilla занимаемся вещами, промежуточными между тем, что ценится в академических кругах, и тем, что воплощается на практике. Это компиляторы, виртуальные машины, даже отладчики, профилировщики — вроде тех, что делает Valgrind. Для исследователей это слишком пресно и малоденежно, не очень ново, слишком много чисто инженерных задач — но здесь возможны крупные прорывы. Мы сотрудничаем с Андреасом Галом (Andreas Gal), и его работы по этим темам были отвергнуты как чрезмерно прикладные.

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

Сейбел: А что насчет доказательства правильности программ?

Айк: Это трудно. А люди по большей части ленивы. Ларри Уолл прав: лень должна считаться достоинством. Вот почему я предпочитаю автоматизировать этот процесс. Ученые его любят, большинство программистов ненавидят. Писать предикаты утверждений — это может принести пользу. У нас в Mozilla было несколько плохих утверждений — скорее они должны были быть предупреждениями, — но со временем хороших становится все больше. Благодаря этому нас наконец озарило, что есть инварианты — те, которые вы хотели бы реализовать в некоей идеальной системе типов.

Думаю, полезно считать утверждения точками доказательства правильности программы. Но не нужно стремиться к полному доказательству. Сколько дыр в серьезных доказательствах, напечатанных в научных журналах!

Сейбел: Давайте сменим тему. Можете ли вы припомнить худшую из ошибок, которую вам довелось отлавливать?

Айк: Худшие ошибки связаны с многопоточностью. В Silicon Graphics я делал работу, связанную с ядром UNIX. Как и все тогдашние UNIX-ядра, оно представляло собой монолитный монитор, который завершался после вхождения в ядро через системный вызов. Исключая прерывания, оно гарантированно работало вплоть до завершения, и блокировка вашей структуры данных никогда не наступала. Прекрасно и просто.

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

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

Диагностировать ее было трудно, так как она была связана с синхронизацией по времени. Машины использовались не по назначению, как концентраторы терминалов. Люди подвешивали псевдотерминалы к реальным терминалам. Это делали студенты в лаборатории или сотрудники брисбенской компании, производившей ПО для горной промышленности: множество отсеков и в конце стеклянная стена, а за ней компьютеры, в том числе двухпроцессорная машина от SGI. Было нелегко, и я рад, что мы все же нашли ошибку.

Обычно такие ошибки не сидят годами, но отыскать их крайне трудно. Нужно как бы приостановить все, думать о них постоянно, видеть их во сне... А заканчивается все тем, что вы делаете элементарные вещи. Так бывает со многими ошибками. Все заканчивается бисекцией, по методу волка и забора[49]. Вы постоянно следите за выполнением, за состоянием памяти, пытаетесь прикинуть размер ошибки, течение исполнения программы, понять, к каким данным можно обратиться. Если это куча голых указателей, дело плохо: следует обратиться к более современным инструментам, которые появились вместе с гигагерцными процессорами, вроде Valgrind и Purify.

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

Можно также использовать записывающие виртуальные машины — они записывают состояние только при системных вызовах и на границах ввода/вывода. Они могут воссоздать состояние поврежденной программы на каждой границе — правда, со всем, что между границами, намного сложнее. Зато все можно закончить быстро, практически в реальном времени, потом перенести программу в Chronomancer, запустить ее в медленном темпе, воссоздать все состояния и найти ошибку.

К сожалению, технология отладки мало исследована. Вот еще пример пропасти между учеными и практиками. Ученые создают доказательства правильности, часто вручную, — правда, эта работа все больше автоматизируется благодаря POPLmark и подобным инструментам. Но в реальной жизни везде есть только отладчики, встречаются даже развалюхи родом из 1970-х, вроде GDB.

Сейбел: В реальной жизни есть еще разрыв между приверженцами символических отладчиков и операторов вывода?

Айк: Да. Поэтому я использую GDB и доволен тем, что в нем, по крайней мере на Маке, есть возможность поставить точку прерывания, и это обычно работает. Я могу наблюдать за адресом, могу засечь момент, когда правильные биты сменяются неправильными. Это довольно полезно. Я также использую команду printf для бисекции. Когда я уже близок к цели, то обычно пытаюсь сделать что-то внутри GDB или пользуюсь командными сценариями (скриптами), хотя они очень слабы. Язык сценариев сам по себе очень слаб. По-моему, Ван Якобсон добавил циклы, но не знаю, использовались ли они в настоящем GDB, после семинаров, организованных Фондом свободного программного обеспечения.