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

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

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

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

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

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

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

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

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

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

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

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

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