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

Сейбел: Почему так происходит? Они не решают реальных проблем - или решение было бы половинчатым?

Айк: Мы делали кое-что с SML/NJ для размещения на резидентном сервере эталонной реализации четвертой версии JavaScript, ныне несуществующей. Мы пытались создать дефинициональный интерпретатор и даже не использовали модель Хиндли-Милнера. Мы собирались аннотировать типы и аргументы так, чтобы избежать этих безумных сообщений об ошибке, когда типы не унифицируются и подбирается наудачу фрагмент исходного кода - обычно не тот, что нужно. Это вопрос качества реализации. Возможно, это также теоретическая проблема, связанная с типами, - когда не получается унификация, трудно найти, какой фрагмент кода тому причиной.

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

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

Некоторые, например Джо Армстронг, проделали действительно большую работу с подходом без разделяемых ресурсов. Таких встречается много в создаваемых индивидуально системах в реализациях броузеров. В этом смысле выделяется Chrome. Мы сделали это по-своему в нашей реализации JavaScript. Но этот подход, по-моему, совсем не интересует ученых. Транзакционная память вызывает больше интереса, особенно там, где это касается компьютерной архитектуры, поскольку они способны разработать хорошие наборы инструкций и оборудование под них. Но это не решит всех наших сегодняшних проблем.

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

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

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

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

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

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

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

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

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

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

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

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