Создатель языка JavaScript, вероятно, самого популярного у веб-разработчиков и самого проклинаемого, Брендан Айк в настоящее время является главным техническим директором компании Mozilla Corporation — подразделения Mozilla Foundation, отвечающего за совершенствование браузера Firefox.

Поклонник изящных теоретических решений и одновременно практичных подходов в программировании, Айк в начале своей карьеры занимался тем, что программировал сетевой код и код ядра в Silicon Graphics и MicroUnity. После MicroUnity работал в Netscape над браузером и в условиях жестокого цейтнота разработал язык JavaScript.

В 1998 году вместе с Джейми Завински он возглавил движение за открытие исходного кода Netscape, что привело к созданию mozilla.org, где Айк стал главным проектировщиком.

В последние годы Айк является одним из руководителей работ по развитию платформы Mozilla и одновременно входит в число разработчиков ЛТ-виртуальной машины для JavaScript, названной TraceMonkey. В интервью Айк объясняет, что он также пытается «сдвинуть ось исследований» в проекте Mozilla, приведя в проект практически мыслящих ученых, чтобы сблизить академическую теорию и промышленную практику.

Мы затрагивали и другие темы, например: почему JavaScript должен был походить на Java, но не слишком сильно, почему JavaScript должен развиваться, несмотря на неудачу проекта ECMAScript 4, и почему необходимы новые разновидности статического анализа кода.

Сейбел: Где вы учились программировать?

Айк: В конце 1970-х — начале 1980-х я заканчивал Университет Санта-Клары, специализируясь по физике. Мы часто бывали в Стэнфорде и работали на LOTS-A и LOTS-B — больших системах с разделением времени типа DEC TOPS-20, а в Санта-Кларе как раз стояла система TOPS-20: отличный 36-битный процессор от DEC, великолепная операционная система, отличный макроассемблер. Си — это что-то вроде «портируемого ассемблера», но работа с макросами в ассемблере — это просто кошмар. А там были настоящие макросы для ассемблера, и имея навыки структурного программирования, можно было сделать многое. Системы типов не было, но и Си в этом отношении особенно ничем похвалиться не может. Зато был богатый набор системных вызовов, системных служб, ввод/вывод с отображением в память — все то, что первоначально не входило в UNIX.

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

Сейбел: На каких языках и в каких средах вы тогда программировали? Для целей физики использовался Фортран?

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

Меня также интересовали язык Си и UNIX, но с нашим старым железом, то есть DEC, мы только начинали их осваивать. У нас было что-то на основе Portable С Compiler и уасс, мы едва-едва начали генерировать код и занялись портированием программ в UNIX. Физики не получали летней работы, так что я много программировал, был ассистентом в лаборатории, а в последний год сменил специализацию на «математика/компьютерные науки», и именно это значилось в моем дипломе бакалавра.

Сейбел: Помните ли вы свою первую интересную программу?

Айк: Непростой вопрос... Там был жуткий графический терминал от DEC — видимо, усовершенствованный VT100, поскольку он понимал escape-последовательности. Совершенно убогая глубина цвета и разрешение на уровне начала 1980-х. Я начал делать для него копии игр: Рас-Man, Donkey Kong. Эти игры я писал на Паскале, и они использовали escape-последовательности. Это было что-то вроде хобби, которым я занимался все больше и больше. Думаю, это был первый для меня случай нестандартного программирования, когда пришлось задуматься о модульности и защите от самого себя.

Это было тогда, когда я еще специализировался по физике, — наверное, на третьем курсе. На четвертом курсе я сменил специализацию, стал изучать формальные языки и писать генераторы парсеров. Вот так я занимался одновременно вещами серьезными и несерьезными — играми и умными программами. Потом я обратился к компиляторам, стал писать копии макрообработчиков вроде т4 и СРР, все в таком духе. Помню, как мы достали исходник какой-то версии UNIX, как читали по-настоящему заумный код на Си! Препроцессор Си Джона Райзера — возможно, настоящий — был довольно забавной смесью всякой всячины. Он был очень эффективным — использовал глобальный буфер, там было много указателей, и еще он пытался избегать копирования. Я подумал: «Чтобы делать это, должен быть способ получше».

Так я бросил физику и обратился к компьютерным наукам и программированию. До этого я по-настоящему не занимался программированием — только математикой и компьютерной теорией. Родители не хотели покупать мне Apple П. Я заикнулся об этом однажды. Выпрашивать не стал, но сказал, что с помощью компьютера смогу выучить иностранный язык — это была своего рода маскировка. «Нет, ты будешь тратить время на свои игры», — ответили родители и были правы. Вот так они уберегли меня от игр.

Сейбел: Программисту легче найти летнюю подработку, чем физику. А что еще для вас было в этом привлекательного?

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

Сейбел: Тут как с испанской инквизицией — никто не ждет плавающую запятую.

Айк: Никто не ожидает встретить получаемые ошибки округления — в пятой степени невообразимые. Округление плохо выполняется в двоичной системе. Поэтому в JavaScript, там, где речь идет о долларах и центах, суммах и разностях, встречаются странные нули с девяткой после них. В одном блоге критиковали Safari и Мак за неправильные математические вычисления. Это стандарт двойной точности IEEE — он встречается везде, и в Java, и в Си.

Кроме того, физика мне казалась чем-то застывшим. Что-то есть в этом нездоровое — люди протирают штаны, открывая что-нибудь вроде темной энергии, то, что принципиально нефальсифицируемо. Меня притягивали более практические вещи, которые тем не менее прочно опираются на математику и логику.

Затем я перешел в Иллинойский университет в Урбана-Шампейне, чтобы наконец получить степень магистра. Я думал, что все уже позади, когда оказался в проекте, для которого IBM набирала специалистов. У них была странная машина 68020, купленная у какой-то компании из Дэнбери (Коннектикут). На этот компьютер они портировали Xenix. Работал он так плохо, что они наняли нашу исследовательскую группу, сделав из нее группу контроля качества. Каждый понедельник появлялся человек в синем костюме и произносил напутственные слова. Преподавателям было, в общем, все равно. Может, я и научился бы чему-нибудь новому, но слышал, о чем говорил в кампусе Джим Кларк, и решил, что хочу работать в Silicon Graphics.

Сейбел: Над чем вы работали в SGI?

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

В конце концов я создал другую реализацию языка — компилятор, который генерировал Си-код на основе описания протокола. Кто-то захотел, чтобы наш анализатор пакетов поддерживал AppleTalk. Это было большое и сложное собрание протокольного синтаксиса для последовательностей и полей разных размеров и зависимых типов... в основном массивов, всякие штуки в этом роде. Это было занятно — трудная задача, которую нужно решить. В итоге мне пригодились некоторые знания о компиляторах из старой «Книги Дракона» Ахо и Ульмана. Думаю, я сделал клон утилиты unifdef. Дэйв Йост уже сделал до меня что-то подобное, но его программа не работала с выражениями #if и не делала минимизацию выражений в том случае, если одни выражения определялись как U, а другие не определялись. Моя программа до сих пор используется и даже, кажется, применяется в Linux.

Я работал в SGI с 1985 по 1992 г. В 1992 г. один мой коллега из SGI перешел в MicroUnity. SGI мне к тому времени уже поднадоела — она все распухала, скупая другие компании, и постепенно переходила под контроль политиков. Так что я оказался в MicroUnity, о которой Джордж Гилдер тогда писал в журнале «Forbes ASAP», что это будет очередной компьютерный монстр. Но все закончилось ничем — компания набрала кредитов на 200 миллионов и обанкротилась. Это было крайне поучительно. Там я занимался компилятором GCC и улучшил свои навыки работы с компиляторами. Еще я писал небольшой язык для редактора видеофайлов MPEG2, на котором можно было писать псевдоспецификации, похожие на стандарты ISO или IEC, и он генерировал тестовые битовые потоки с правильным синтаксисом.

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

Айк: Я много занимался физикой, прежде чем обратился к математике и компьютерным наукам. Я довольно много занимался математикой, получая через это знания по программированию, а также изучал кое-что самостоятельно и поэтому на занятиях сидел в задних рядах — скучал, ерзал, делал что-то свое. От этого сильно страдала самодисциплина, и я, вероятно, пропустил кое-что важное.

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

Что касается программирования, то я всегда говорил, что занимаюсь низкоуровневым программированием. Объектно-ориентированное программирование, шаблоны проектирования — это не для меня. Я так и не купил книгу Эриха Гаммы. Кое-кто в Netscape потрясал этой книгой как Библией — наши с Джейми Завински враги-коллеги, пришедшие в компанию после ее покупки. Просто невыносимо, учитывая, что это были далеко не лучшие программисты.

Сложись все иначе, я мог бы заниматься и высокоуровневыми вещами. Думаю, работая в Mozilla и имея дело с Firefox, я узнал больше о разработке через тестирование — то был ценный опыт. Было и кое-что еще, например тестирование с использованием случайных данных, которого проводилось много. У нас было много исходных языков, были большие и глубокие конвейеры рендеринга, сильно подверженные ошибкам, связанным с безопасностью доступа к памяти. Вообще, тестирование с использованием случайных данных оказалось самым продуктивным видом тестирования.

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

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

Айк: Анализ языка C++, выполнить который непросто. Обычно при статическом анализе вы анализируете программу целиком и стремитесь, скажем, доказать корректность состояния памяти. Нужно устранить все неоднозначности, а для этого найти в памяти все альтернативные имена — это проблема экспоненциального характера, обычно нерешае-мая ни для одной более-менее крупной программы. Большой прорыв, однако, заключался в том, что больше не надо было волноваться насчет памяти. Если построить полную диаграмму исполнения команд и связать воедино все виртуальные методы с их возможными реализациями, то можно частично оценивать код, не запуская его. Можно найти недостижимый код, можно найти избыточные проверки и пропущенные проверки на NULL.

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

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

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

Сейбел: Да, это весьма высокий уровень программирования. Как по-вашему, насколько близко сегодняшние программисты должны стоять к «железу»? Нужно ли тому, кто в основном пишет приложения на JavaScript, разбираться в языке ассемблера?

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

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

Абстракция — великая сила. Что у меня вызывает аллергию еще с 1990-х, так это CORBA, COM, DCOM, всякая объектно-ориентированная чушь. Каждый новый проект в то время обязательно имел какую-нибудь примочку, которой было нужно 200 000 вызовов только для запуска и приветствия. Это профанация. Настоящие программисты таким не занимаются. В SGI ядро делали настоящие крутые программисты, и там никто не занимался ерундой. Выделение динамической памяти ядра через malloc было тогда совсем новым делом. Мы использовали таблицы с фиксированным размером и паниковали, заполнив их целиком.

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

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

Айк: В некоторых областях эти навыки смыкаются. Есть разница между миром простых указателей и солнечным, радостным миром JavaScript. Здесь проходит граница между истинными программистами и всеми прочими.

Важно держать все в голове. Конечно, у всех разная память. Особо памятливые могут держать в уме набор высокоуровневых инвариантов при архитектуре с безопасным доступом к памяти, не заботясь при этом об указателях. Но иногда меня беспокоит, что мы постепенно утрачиваем способность писать для «железа». Это делают другие; компилятор генерирует код. Видимо, спрос на таких людей будет расти.

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

Айк: Я давно не занимался кодом ядра, и если нужно будет заняться, это потребует от меня усилий. Теперь нужно писать больше кода. Кроме того, удачные абстракции позволяют сейчас справляться с задачами, не решаемыми в прошлом.

Сейбел: Вернемся к тем десяти дням, когда вы реализовали изначальную версию JavaScript. Я слышал, кто-то обратил ваше внимание на книгу Абельсона и Сассмана, и первоначально вы собирались встроить в браузер Scheme.

Айк: Чем прежде всего были озабочены в Netscape? Все должно быть как в Java! Другие создавали алголоподобный синтаксис для Лиспа, но у меня не было времени взять Scheme за основу. Пришлось делать все напрямую, а значит, я мог совершать те же ошибки, что и другие.

Я не стал делать тотальный динамический контекст, на котором настаивал Стеллмен для Emacs и которым он наводнил Elisp. В JavaScript контекст в основном лексический, но есть отступления в виде динамических элементов: глобальный объект, оператор with, функция eval. Но ничего похожего на $-переменные в Perl до введения ту или на команды upvar и uplevel в Tel. В 1990-е все это было очень модно.

Однако я не остановился на Scheme — из-за спешки. Было очень мало времени, чтобы задуматься над последствиями своих действий. Я экономил усилия на многих объектах, которые должны были реализовы-ваться в браузере. Поэтому я сделал window глобальным объектом, который является источником связывания необъявленных новых имен и делает невозможными статические суждения о свободных переменных. А жаль. Дуг Крокфорд и прочие приверженцы объектной модели были недовольны тем, что вы получаете нежелательную власть над глобальным объектом. Это другой способ сказать то же самое. В JavaScript есть безопасные ссылки на объекты в памяти, и мы уже близки к цели, но остаются большие недочеты — те самые отступления.

Эти переменные, привнесенные на высокий уровень, теперь становятся изменяемыми свойствами объекта, которые можно тасовать как угодно за спиной у кого-то — это плохо. Должно быть лексическое связывание. Тогда, если спускаться вниз, к функциям и вложенным функциям, будет больше похоже на Scheme. У вас не будет богатых форм связывания, макросов вроде fluid-let — скорее, что-то вроде set!. Но изначальное связывание, создаваемое при помощи локальной переменной, — это лексическая переменная.

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

Айк: Да. Функция создается и тут же вызывается. Это дает безопасную среду для связывания, приватные переменные. Дуг — ярый пропагандист всего этого. Тем, кто работал со Scheme и Лиспом, это уже было отчасти знакомо, но многим JavaScript-программистам пришлось осваивать все с нуля. Дуг и его коллеги провели большую работу по их обучению. Увы, сделать грамотных Scheme-программистов из всех не получилось, но, по крайней мере, люди стали понимать функциональные идиомы, пусть неглубоко, но хотя бы на уровне шаблонов.

Сейбел: Итак, JavaScript примерно десять лет был в тени. Сейчас наблюдается его бурное возрождение благодаря Ajax. Все говорят: «Нам нужно взглянуть на это по-другому». Вы недавно оказались в центре драматической истории, связанной с соперничеством между ECMAScript 4 и ECMAScript 3.1. В конце концов был предложен план «Гармония», предусматривавший объединение двух версий в одну. Что стояло за ES4 — желание показать, что вы действительно классный программист, a JavaScript — хороший язык?

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

Сейбел: Был ли ES4 вашим детищем? Как вы оцениваете его с сегодняшних позиций — как идеальный вариант JavaScript?

Айк: Нет. То был плод коллективных усилий и в какой-то мере компромисс, поскольку мы работали с компанией Adobe, создавшей производный язык ActionScript. Третья версия этого языка повлияла на нашу работу. А ее основой стали наработки Вальдемара Хорвата в отношении изначальной версии JavaScript-2 и предложений по четвертой версии ECMAScript конца 1990-х. Их положили под сукно в 2003 г., когда компания Netscape закончилась и была основана Mozilla.

Вальдемар сделал все как надо — я дал ему ключи от королевства в конце 1997 г., когда уходил создавать mozilla.org вместе с Джейми. Вальдемар — это могучий ум: кажется, он выиграл Путнамовскую олимпиаду в 1987 г. PhD MIT (Massachusets Institute of Technology). Он сохранил за языком его динамическую окраску, но при этом вел борьбу за включение некоторых элементов, свойственных «программированию по-большому», например пространств имен.

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

Сейбел: В одной из дискуссий по поводу ES4 вы цитировали статью Гая Стила «Growing a Language» (Выращивание языка). Как старый Лисп-программист, я сделал из нее прежде всего такой вывод: введите в язык макросы, и весь сахар исчезнет.

Айк: Разумеется, есть две крупные проблемы. Си создает куда больше забот, чем s-выражения, поэтому надо определить абстрактные синтаксические деревья, потом стандартизировать их — это мучительный процесс. Есть и проблема гигиены, которую пока еще плохо понимают. Дэйв Херман, который работает вместе с нами, пишет — по крайней мере, писал — диссертацию насчет разновидности логики, которая сможет обеспечить гигиену. И это здорово, ибо нас ждет переход на макросы.

Я говорил об этом Дугу Крокфорду несколько лет назад, когда он пригласил меня выступить в Yahoo! Я начал говорить о сахаре, горячим сторонником которого был. «А не разработать ли нам сперва систему макросов?» — спросил он, и я ответил: «Нет, это займет девять лет». Тогда был реальный риск, что Microsoft откажется от сотрудничества. После нескольких лет летаргии они снова заинтересовались ЕСМА. Их новый парень — он был из Хайдарабада — отнесся к этому с энтузиазмом, сказал, что они включат CLR в IE8, а JScript.net будет их новой реализацией JavaScript для Сети. Но, по-моему, наверху погасили его энтузиазм, и он отказался от своих слов. В нашем руководстве тогда произошел раскол.

Мы беспокоились, что переход на макросы потребует исследований, а это означало, что у нас не будет обязательств перед Microsoft и мы не сможем оказывать на них конкурентное давление. Макросам пришлось подождать. Будем создавать хорошие средства автоматической проверки грамматики, сделаем так, чтобы весь сахар превратился в макросы, когда настанет время макросов. А пока — зачем лишать пользователей сахара? Зубы не испортятся, а ошибок будет меньше.

Сейбел: Вернемся в 1995 год. Какие еще языки повлияли на первоначальный проект JavaScript?

Айк: Self был популярен, в основном благодаря статьям Дэйва Унга-ра. Я никогда не работал с кодом Self, но вдохновлялся теми статьями. Я люблю Smalltalk. Кое-кто у нас взял из Smalltalk идею делегирования на основе прототипов — с несколькими прототипами, в отличие от JavaScript, и очень плотно стал работать в этом направлении. Smalltalk мне нравился — там был хороший компилятор, инженерные подходы на уровне виртуальных машин и, как я считаю, хороший дизайн языка.

Подобно Кроку и некоторым другим, я сторонник простоты. Мне симпатичны те проектировщики языка, которые берут немного примитивов и смотрят, как далеко можно с этим пойти. С разработчиками JavaScript, по-моему, случилось нечто вроде «стокгольмского синдрома»: «Он делает то, что делает, только потому, что Microsoft не дает это совершенствовать. Зачем нам улучшать синтаксис — теперь все идет через лямбда-программирование». Если оставить в стороне «стокгольмский синдром» и тот факт, что Microsoft тормозит развитие Сети, проектировщику языка стоит взять одну-две идеи для ядра и настойчиво воплощать их в жизнь.

Сейбел: А с NewtonScript вы знакомы?

Айк: Только после того, как кто-то ткнул пальцем, и я понял: «Да у них же что-то похожее на нашу цепочку областей видимости по ссылке на родителя и наш одиночный прототип!» Думаю, то была конвергентная эволюция на базе Self. А что касается обработки событий DOM, здесь повлияли HyperTalk и аткинсоновский HyperCard. Так что я учитывал не только Self и Scheme, но и обработчики событий onFoo в HyperTalk: я реализовал это в DOM в виде onClick и не только.

Стыдно признаться, но положительное влияние на меня оказал также awk. Да, я был старым UNIX-хакером, уже вышел Perl, но для рутинной работы я часто использовал awk. Я назвал функции первого класса «функциями» прежде всего из-за awk. Слово «function» из восьми букв выглядит тяжелым, но тем не менее.

Сейбел: По крайней мере, это не «lambda» — иначе JavaScript был бы заранее обречен. Скажите, а на JavaScript что-нибудь повлияло отрицательно — то есть в смысле «я так ни за что не сделаю»?

Айк: Работа была очень спешной, и я не сильно задумывался о том, чтобы отмежеваться от Ada или Common Lisp. Java в какой-то мере оказал такое воздействие. Мне надо было, чтобы язык напоминал Java, но не содержал безумных вещей, вроде различия между примитивными типами и объектами. И я не хотел создавать классы. Поэтому я стал смотреть в сторону Self и делать первоначальные наброски.

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

Айк: Со стороны руководства ощущалось давление: они хотели, чтобы синтаксис был похож на тот, что в Java. Еще они хотели, чтобы язык не становился слишком объемным, — для сложного программирования был Java, а наш язык замышлялся как его младший брат.

Сейбел: Чтобы напоминал Java, но не слишком.

Айк: Не слишком. Если бы я ввел классы, то столкнулся бы с большими проблемами. У меня и времени, правда, на это не было, но я бы их все равно не ввел.

Сейбел: Вернемся в наши дни. ES4 была официально отвергнута, и сейчас идет работа над ES-Harmony, сочетающей черты ES3.1.H ES4. Как вы полагаете, это удачное решение?

Айк: Дуг, пожалуй, слишком уж торжествовал в своем блоге: «Мы победили. Мы одолели дьявола». Год назад я подарил ему в Лондоне шуточный слайд: Дуг в виде Гэндальфа на мосту в Казад-Думе, глядящий вниз на ниспровергнутого ES4pora. Ему очень понравилось. Я впервые подшутил так над ним — его порой оставляет чувство юмора, когда он касается этих проблем. Но ему понравилось. Может, он и герой, но ES4 совсем не был чудовищем.

ES4, как мне кажется сейчас, был слишком объемным. Но нам нужно было прагматично подойти к стандартам. Мы не могли сказать: «Все, что вам нужно, — это лямбда-выражения». Алонзо Чёрч доказал, что это не так. И мы не могли вставлять еще больше таких выражений. Такой подход, предполагающий высокую квалификацию каждого, многого не учитывает, например того, что многих программистов в Java-вузах научили плохому. JavaScript однажды умрет, но можно совершенствовать его, поддерживать его конкурентоспособность как в теоретическом, так и практическом плане. При условии, конечно, что мы не откажемся от сахара ради чистоты.

Язык должен совершенствоваться, чтобы можно было решить стоящие перед программистами задачи. С некоторыми можно справиться, если писать собственные библиотечные абстракции. Но возможность написания абстракций для языка очень ограничена, если нет расширений — вы не можете написать геттеры и сеттеры. Объекты будут смотреться чужеродно, свойства не смогут стать кодом и так далее. Кроме того, вопросы безопасности нельзя будет разрешать неявно или автоматически.

Сейбел: Как вы полагаете, языки в целом со временем улучшаются?

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

Есть, например, Ruby, испытавший влияние языков Ada и Smalltalk. Это прекрасно. Я не имею в виду эклектичность. Но Ruby перехваливают. Нет, ничего плохого сказать не могу, просто некоторые мальчики-фанаты трубят, что он решит все проблемы, а это не так. Новые языки нужны, но хвалить их надо в меру, не как C++ — «шаблоны проектирования нас спасут». Конечно, может быть, это реакция на консерватизм приверженцев Си-мира UNIX 1980-x.

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

Сейбел: В какой степени языки должны предотвращать ошибки программистов?

Айк: Язык для «синих воротничков», такой как Java, должен иметь четкую и логичную базовую систему, так как «синим воротничкам» трудно понять, что это за вывороченный синтаксис с ковариантными и контравариантными ограничениями типов. Я немало пострадал из-за того, что порой выкидывают Си и C++. Программирование отчасти состоит в конструировании, а конструирование отчасти состоит в решении проблем безопасности. Они важны при разработке браузера и еще больше — если вы делаете программу для аппарата лучевой терапии. Так или иначе, речь идет о более совершенных языках для написания параллельных программ или эффективного использования аппаратного параллелизма. Мы не всегда будем использовать синхронизированные блоки и уж точно не будем использовать мьютексы или взаимные блокировки. Поэтому языки могут служить для установления разумного компромисса между безопасностью и выразительностью.

Мне кажется, с JavaScript мы стремились именно к этому, в противоположность диким, неуправляемым французам, которые хотели видеть JavaScript чем-то вроде #86 с лямбда-выражениями. Нам совершенно незачем вводить оператор call/cc. Предположим на минуту, что обойдется без проблем с реализацией: народ будет сбит с толку. Не обязательно большинство, но многие из тех, кто считает себя крутыми программистами. Есть нечто вроде программистской пирамиды, на вершине которой располагается Правильная вещь. Люди карабкаются к вершине, даже если некоторые срываются, получая травмы.

В JavaScript можно нарваться на неприятности разными способами. Есть функции первого класса. Есть малопонятные для людей прототипы — они не отвечают классическим стандартам объектно-ориентированного программирования.

Многовато. Я не минималист и не утверждаю, что мы должны прекратить развитие языка. Это удобная отговорка в Microsoft, которая меня бесит, потому что люди тратят время, а ошибки не устраняются. Даже при наличии лямбда-выражений вы все равно не избавитесь от кое-каких трудноустранимых ошибок.

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

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

Айк: Мы ведем справедливую борьбу, но надо делать это с умом. Надо также изменить направление исследований, так как — для меня это было очевидным еще в школе — академическая наука выглядит чем-то ненормальным. Она сильно оторвана от практики.

Надо это исправлять. Мы успешно работали с практически мыслящими учеными. Денег у нас немного, поэтому отчасти мы занимаемся тем, что попросту разговариваем с людьми, служим для них объединяющим центром.

Если ученые охотятся за правительственными грантами и никак непричастны к вашей деятельности, это в какой-то степени потеря для вас. Далее, вы наблюдаете бурный взлет динамических языков, слушаете безумные заявления насчет того, как они убьют Java, и что статические языки — просто смешно. Но ученые убеждены, что статическая типизация — это венец эволюции, они исследуют особые ее виды — язык ML, вывод типов Хиндли-Милнера. Это полный отрыв от практики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако отладчики могут сделать бесконечно больше, чем делают сейчас, и в этом смысле Chronomancer и Replay — шаг вперед. Они изменили для меня весь процесс. Но вот насчет многопоточности не знаю. Есть Helgrind и другие динамические детекторы гонок, которыми мы пользуемся. Они дают ложные срабатывания, которые надо отсеивать. С ними пока еще не все до конца понятно.

Многопоточные процессы страшат меня — до того как я женился и завел детей, они съели немалую часть моей жизни. Не все задумываются насчет параллелизма и всех возможных комбинаций команд, происходящих даже в небольших сценариях. Если ваш код соединяется с чужим, он выходит из-под контроля. Вы не можете мысленно смоделировать происходящее. Большинство людей не могут. Я мог бы стать одним из этих всезнаек с сайта Slashdot: когда я писал в своем блоге, что против многопоточности, кое-кто говорил: «Да он ничего не знает, это несерьезно». Давай, болтай. Я слетал в Австралию и Новую Зеландию, мне достались кое-какие бонусы. Но все это было так мучительно и продолжалось слишком долго. Как сказал Уайльд о социализме, «Он отнимает слишком много вечеров».

Сейбел: Как вы проектируете код?

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

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

Поэтому мы создаем множество прототипов, работаем над разными кусками с обоих концов, которые сводим в середине. Я считаю, что сейчас мы в Mozilla недостаточно переписываем код. Мы слишком консервативны. У нас открытый исходный код, поэтому вокруг нас создаются сообщества, мы заинтересованы в новых людях. Мы работаем в интересах пользователей и поэтому не можем позволить себе трехлетний перерыв на переписывание — хотя если очень постараться, то смогли бы.

Но если вам нужно избрать другой путь, и вы не знаете в точности какой, — переписывайте. Если хотите понять, что, черт возьми, вы тут делаете, потребуется несколько попыток. Код становится лучше по своему проектному решению, вы останавливаетесь на этой версии, начинаете ее латать, пока не дойдете до предела. Это нечто вроде эволюционного тупика для кода. Возможно, при приемлемых невозместимых издержках этот код останется на годы. А может, потребует замены. Вдруг в мире открытого исходного кода появится более совершенная стандартная библиотека?

Это возвращает нас к ремеслу программирования. Вы не просто пишете код в соответствии со старым проектным решением. Вы хотите постоянно практиковаться, а это значит думать о проектном решении кода и применять свой опыт в написании кода к этому решению.

У меня страшная аллергия на всякого рода эзотерические решения, шаблоны проектирования, доступные немногим. Питер Норвиг, работая в Harlequin, сказал о том, что шаблоны проектирования — всего лишь дефекты в вашем языке. Возьмите язык получше! И он был абсолютно прав. Что это такое — молиться на шаблоны, постоянно думая, какой бы из них применить!

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

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

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

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

А вот вторая причина того, что мы взялись за переписывание: я трудился в mozilla.org и был сильно недоволен Netscape, как и Джейми, — тот вообще собирался уходить. Я считал, что нужно пустить на наше поле новых работников, а со старым запутанным кодом, сделанным на коленке в 1994 году, сделать это было нельзя. И с моим прекрасным кодом интерпретатора в стиле ядра UNIX.

Нам нужна была большая перезагрузка. Четыре года с момента выпуска программы! Не говоря ничего такого топ-менеджерам, поскольку они и слушать об этом не желали, мы стали искать оптимальное решение за них. В итоге полетело несколько топ-менеджерских голов. Правда, менеджеры, в отличие от меня, все равно сказочно заработали на опционах. Но для Mozilla это было выгодно.

Сегодня можно назвать это удачей, поскольку развитие Сети ускорилось. Видимо, Microsoft — некоторые утверждают, что это было связано скорее с антимонополистскими расследованиями, чем с желанием его руководителей, — хотела плотно оседлать Сеть и не допустить ее эволюции. Это дало нам возможность заняться переписыванием, размахивая знаменем стандартов (довольно сомнительный ход, особенно с учетом качества стандартов). Как и Джоэл, я скептично смотрю на переписывание. Трудно примирить все интересы, найти деньги и при этом правильно отреагировать на требования рынка. Исключений единицы.

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

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

Айк: Я делал кое-что наподобие его первоначальных программ — просто классно, мне очень нравилось. Это было извлечение слов. Там было некое подобие древовидного хеша, программирование было целиком литературным. Потом Дуг Макилрой сделал все то же самое, только с конвейером.

Наши программы подробно откомментированы, но нет средства изъять из них прозу и проверить ее — хотя бы вручную — относительно кода. Разработчики Python сделали в этом смысле кое-что интересное. Все что я сделал — не более чем подробное комметирование. Я периодически обновляю старые комментарии, но это тяжело, и иногда мне это не удается, и я жалею, что кто-то из-за меня получил неверную информацию.

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

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

Сейбел: Вы читаете чужой код?

Айк: Это часть моей работы. Ревизия кода — обязательный шаг перед коммитом, который был когда-то необходим в основном из-за плохой кадровой политики Netscape, но мы до сих пор пользуемся им, а также делаем интеграционные ревизии. Мы устраиваем также особые «суперревизии», когда изменяется много модулей и вы не знаете всех скрытых инвариантов, которые Джо Шмо, который больше не работает в Mozilla, держал в своей голове. В принципе, есть люди, способные охватить взглядом целостную картину. Иногда мы обходимся без этого, когда все хорошо знают, что делают, и понимают друг друга без слов, как джедаи. Но лучше поступать так не слишком часто.

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

Сейбел: Вы говорите о коде, который пишется для Mozilla. А вы читали когда-нибудь код не по работе, а ради самообразования?

Айк: В этом смысле открытый исходный код — потрясающая вещь. Я люблю смотреть код, который пишут люди с разных концов света, хотя посвящаю этому не так много времени. Больше всего меня привлекают серверные фреймворки, а еще такие языки, как Python и Ruby.

Сейбел: То есть их реализации?

Айк: Реализации и код библиотек. Возьмем библиотеки Ajax: приятно видеть, насколько умны могут быть люди и как с небольшим набором инструментов — замыкания, прототипы, объекты — можно создавать удобные, порой очень удобные абстракции. Нельзя сказать, что они всегда крепко скроены или безопасны, — но до чего удобны!

Сейбел: Как вы поступаете, если надо прочесть большой кусок кода?

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

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

Создавая регулярные выражения в JavaScript, я обращался к Perl 4. Я пропускал его через отладчик и читал код. Это давало мне идеи: реализация в обоих языках оказалась схожей. Их рекурсивный характер с поиском с возвратом был немного необычен, так что пришлось поднапрячься. Удалось только отладить некоторые регулярные выражения и проследить за исполнением. Другие программисты, как я слышал, тоже говорили об этом: нелегко пробираться сквозь код, понимать, как динамическое состояние системы выглядит при беглом взгляде или при проверке базовой функциональности. Я согласен с ними.

Сейбел: Вы делаете то же самое с собственным кодом, даже если не ищете ошибку?

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

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

Айк: Да, или — это моя личная проблема — я живу на планете сказок. Сейчас я постарел, стал скептичнее, работаю лучше, но все еще настроен слишком оптимистично. В каком-то уголке моего сознания Говорящий сверчок шепчет: «Да у тебя там, должно быть, ошибка, ведь ты наверняка о чем-то забыл». Со мной так всегда.

Иногда я точно знаю это — знаю, что где-то ошибся, — и покрываюсь потом. У меня свербит не то в заднем мозгу (где это, кстати?), не то в микротрубочках. Так или иначе, я чувствую, что должен быть начеку, и отладчик помогает мне быть начеку. Он помогает мне принять решение или понять, что вот этот тест-вектор не покрывает всех комбинаций кода, так как передо мной обширное гиперпространство.

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

Айк: Мне надо было бы читать побольше. Но это как в музыке: главное — практика. Можно узнать очень многое, читая чужой код. Мне очень нравились книги Брайана Кернигана, написанные предельно логично — написать небольшой фрагмент кода, использовать его заново по мере продвижения, строить модули. Еще «Искусство программирования» Кнута, тома 1-3, особенно та часть, где говорится о получисленных алгоритмах. Двойное хеширование — я люблю эти главы. Лемма о золотом сечении, которую требуется доказать в качестве упражнения.

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

Нет, конечно, есть определенный объем знаний: компьютерная наука — все же наука. Помню, лет двадцать назад был спор в Usenet, и кто-то заметил: «Недонаука, показатель строгости — одна треть». Есть куча мимолетных брошюрок, которые явно не выдержат проверку временем. Журнальные статьи лучше, так как на них обязательно требуется отзыв, да и контроль там строже. Области автоматизированных доказательств — это впечатляет. Но эти статьи все еще не доходят до программистов. Поэтому в компьютерных науках кое-чего, пожалуй, не хватает, и я из-за этого недоверчиво отношусь к чтению книг. Видимо, все же не надо настолько уподобляться луддитам.

Есть наука, есть важные вещи, которые надо усвоить. На это можно потратить много времени. Я знаю чистых теоретиков в отделе развития JavaScript. Многие из них хорошие программисты. Некоторые не программируют вообще. Они мало знакомы с практикой. У них случаются любопытные и порой полезные озарения, но писать программы, выпускать их, делать работоспособными, чтобы они завоевали свою долю рынка, — все это далеко от теории. Но я интересуюсь теорией, она делает нашу жизнь лучше.

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

Айк: Такие книги мне нравятся. Мы говорили о труде Кнута, посвященном литературному программированию. Там был раздел о практике программирования — он мне пришелся по душе. Люблю книги по Smalltalk. Сейчас мне кажется, что они оказали большое влияние — книга Адели Голдберг, а до нее журнал «Byte».

Сейбел: С воздушным шаром на обложке?

Айк: Да. Она сильно перевернула мои взгляды. 1981 год или около того. Тогда я мало занимался программированием. Я думал о нем, читал о нем, терзал старое железо, учась на последнем курсе. Чистота среды в Smalltalk, то, в какой степени она поддерживала сама себя, — все это заставило меня обратиться к программированию, к языкам и виртуальным машинам. Работая с UNIX, я имел дело с физическими машинами и операционными системами, но не переставал читать. Была такая книга издательства Springer-Verlag — сборник статей, в котором народ в основном фантазировал насчет универсального формата объектных файлов и байт-кода Java еще до его появления. Но Smalltalk был мощной штукой. Я освоил Smalltalk позже, в Иллинойском университете, когда его приспособили для работы на компьютерах Sun того времени. Работало все медленно.

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

Айк: Недавно мы наняли такого — он был другом одного из самых могучих умов в нашей компании. То ли студент последнего курса, то ли бакалавр — кажется, еще не закончил колледж. Он познакомился с парнем, который работал у нас, — оба они OCaml-программисты. Он размышлял о проблемах, которые были поставлены в моем статическом анализе. По его ответам на вопросы не скажешь, что он еще мальчик. Кое-кто из наших говорил: «Да что он такого великого сделал? Мы берем только звезд, зачем тратить на него время?»

Я отвечал: «Нет, ребята, вы не правы. Надо брать специалистов, пока они молоды. Он сделал много чего для себя на OCaml; он знает не только исходный язык, но и рабочую среду, он разобрался с системными методами и написал на OCaml операционную систему — пусть пока игрушечную. Но это стоящий парень». Я даже не дал ему никакого теста — просто слушал его рассказ о том, что и почему он сделал. Он не пережевывал эту вечную жвачку насчет шаблонов C++. У нас, к сожалению, есть и такие мальчики. Милые люди, в чем-то неплохие программисты, могут работать на Java. Но нам нужен был кто-то необычный, а этот парень был необычным.

Поэтому главной проблемой стало убедить людей, что его возраст и отсутствие большой практики ничего не значат. Но мы взяли его, и он стал суперзвездой. Он придумал инструменты для статического анализа; сперва создавал их на платформе Berkeley Oink с открытым кодом, а потом на GCC в качестве плагинов вместе с разработчиками GCC. Сейчас он активно взялся за наши программы для мобильников: делает элементарное профилирование, выводя отметки времени через printf, ищет, где можно снизить издержки.

Разговаривая с ним, я понял, что он талантлив. Хорошо было и то, что его рекомендовал блестящий программист, — такие люди тянутся друг к другу и обычно не рекомендуют посредственностей. Они хотят работать с такими же блестящими программистами. Может показаться, что я выдумываю, но для меня это и правда один из способов распознать талант. Наверное, именно поэтому мы берем к себе суперпрограммистов. Думаю, все люди из Valgrind оказываются у нас. Некоторые из них могут все и совсем не выделываются.

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

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

Сейбел: Можно ли сразу выявить нужного человека?

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

Проверяйте знание C++, поскольку C++ — сложная штука. Это что-то вроде базовой проверки, вовсе не решающий аргумент. Прошел человек такую проверку — хорошо, нет — тревожный сигнал. Для приема на работу нужно что-то еще. Нужны подробности: что человек сделал, каков его подход к программированию, с какими языками он работал.

Кроме того, мне, видимо, нравятся необычные люди. Я не имею в виду всякие странности. Я не хочу нанимать человека, с которым трудно сработаться, — нам нужны таланты. Нужны те, кто мыслит нестандартно.

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

Когда я опрашиваю потенциальных кандидатов, то мне очень сложно не увязнуть в мелочах, в практических вопросах. Этот парень знает OCaml? Хорошо. Но стоит ли брать его на работу? Только из-за этого — нет. Но он еще делал что-то для себя, умеет решать задачи с ходу, думает о проблемах компиляции или анализа. Значит, возьмем. Но, возможно, главным доводом здесь была рекомендация его друга, блестящего программиста.

Сейбел: Программирование все еще доставляет вам удовольствие?

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

Сейбел: А есть то, что со временем вам стало нравиться меньше?

Айк: Ну, не знаю... Наверное, C++. Мы научились пользоваться всеми его свойствами, которых слишком много. Система типизации в нем, пожалуй, лучше, чем в Java. Но мы все еще применяем отладчики и компоновщики 1970-х — полный идиотизм! Не понимаю, как мы до сих пор их терпим.

Нетерпение и неприязнь к примитивным инструментам — вот из-за чего я старался совершенствоваться в программировании. Наш код сегодня испещрен проверками утверждений, и они фатальны. Но именно это помогает мне, особенно когда я применяю к коду тот самый принцип 90/10, не удовлетворяющий всем инвариантам. Я что-то упустил, утверждение срабатывает, и вдруг — раз! — я понимаю, как его исправить.

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

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

Айк: Думаю, у молодых огромные преимущества, прежде всего психологические. Им не хватает лишь мудрости! Становишься старше, работаешь медленнее — но ты усвоил горькие уроки и хочешь передать свой опыт следующему поколению. Я вижу, как они отворачиваются от меня и сами усваивают эти уроки, — и сжимаю кулаки.

Но человек знающий, который старается быть в курсе всего, не обязательно должен выдавать много кода. Нет, конечно, объем продукции тоже важен. Но что первостепенно для меня — и об этом мы много беседовали в Netscape, когда там искали главного инженера, — это найти человека, не менеджера, а того, кто своим авторитетом заставит других программистов писать код в нужном духе. Ведь один программист просто не справится со всеми задачами.

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

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

Не все программисты способны на это — многие склонны работать, забившись в свой угол. Но работая в Netscape, я понял, что мне нравится взаимодействовать с людьми, которые пользуются моим кодом. Если я забьюсь в свой угол, мне будет не хватать этого. А я хочу постоянно решать такие задачи. Да, я могу выстроить для себя прекрасный воздушный замок, но будет ли он удобен для других? Вряд ли. В чем же тогда смысл? Как говорил Гиллель-старший, «кто я без других»?

Я не связываю себя только с JavaScript. Поначалу мы страшно спешили, делали массу ошибок, и как-то Джейми переслал мне пост из Usenet со словами: «Говорят, ваш детище — урод». Теперь у меня настоящие дети, и те дела больше меня не волнуют.