Текст книги "Кодеры за работой. Размышления о ремесле программиста"
Автор книги: Питер Сейбел
сообщить о нарушении
Текущая страница: 10 (всего у книги 41 страниц) [доступный отрывок для чтения: 15 страниц]
Сейбел: Думаете, решение этой проблемы отчасти зависит от техники? Могут ли программисты и проектировщики систем создать такую архитектуру, которая будет для этого полезна? Или проблема чисто социальная?
Крокфорд: Может быть, новые социальные системы будут строиться на основе новой сетевой инфраструктуры, и, может быть, она все еще не дозрела до нужного уровня, и проблема в этом. Может быть, все решится само собой – надеюсь, так и будет. Но мне кажется, что без подобной помощи не обойтись. Сейчас в Сети очень слабы системы идентификации и безопасности, и, на мой взгляд, это необходимые компоненты для построения надежной социальной системы. В этом отношении Сеть все еще несовершенна, возможно, отсюда и столько лишних проблем.
4. Брендан Айк
Создатель языка 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-х, но он не всегда работает так, как ожидалось.
Сейбел: Тут как с испанской инквизицией – никто не ждет плавающую запятую.[43]43
«Никто не ждет испанскую инквизицию» (No one expects the Spanish Inquisition) – ставшая крылатой фраза из британского юмористического телешоу «Монти Пайтон». – Прим. ред.
[Закрыть]
Айк: Никто не ожидает встретить получаемые ошибки округления – в пятой степени невообразимые. Округление плохо выполняется в двоичной системе. Поэтому в JavaScript, там, где речь идет о долларах и центах, суммах и разностях, встречаются странные нули с девяткой после них. В одном блоге критиковали Safari и Мак за неправильные математические вычисления. Это стандарт двойной точности IEEE – он встречается везде, и в Java, и в Си.
Кроме того, физика мне казалась чем-то застывшим. Что-то есть в этом нездоровое – люди протирают штаны, открывая что-нибудь вроде темной энергии, то, что принципиально нефальсифицируемо. Меня притягивали более практические вещи, которые тем не менее прочно опираются на математику и логику.
Затем я перешел в Иллинойский университет в Урбана-Шампейне, чтобы наконец получить степень магистра. Я думал, что все уже позади, когда оказался в проекте, для которого IBM набирала специалистов. У них была странная машина 68020, купленная у какой-то компании из Дэнбери (Коннектикут). На этот компьютер они портировали Xenix. Работал он так плохо, что они наняли нашу исследовательскую группу, сделав из нее группу контроля качества. Каждый понедельник появлялся человек в синем костюме и произносил напутственные слова. Преподавателям было, в общем, все равно. Может, я и научился бы чему-нибудь новому, но слышал, о чем говорил в кампусе Джим Кларк, и решил, что хочу работать в Silicon Graphics.
Сейбел: Над чем вы работали в SGI?
Айк: В основном над ядром и сетевым кодом. Я постепенно совершенствовался в языках, так как мы решили создать собственный уровень для управления сетью и анализа пакетов. Я написал язык выражений для сравнения полей и пакетов, и еще транслятор, который уменьшал и оптимизировал все это до небольшого числа фильтрующих масок для первых 36 байт пакета.
В конце концов я создал другую реализацию языка – компилятор, который генерировал Си-код на основе описания протокола. Кто-то захотел, чтобы наш анализатор пакетов поддерживал AppleTalk. Это было большое и сложное собрание протокольного синтаксиса для последовательностей и полей разных размеров и зависимых типов... в основном массивов, всякие штуки в этом роде. Это было занятно – трудная задача, которую нужно решить. В итоге мне пригодились некоторые знания о компиляторах из старой «Книги Дракона» Ахо и Ульмана[44]44
А. Ахо, Р. Сети, Д. Ульман «Компиляторы. Принципы, технологии, инструменты». – Вильямс, 2003.
[Закрыть]. Думаю, я сделал клон утилиты 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. Я слышал, кто-то обратил ваше внимание на книгу Абельсона и Сассмана[45]45
X. Абельсон, Д. Д. Сассман «Структура и интерпретация компьютерных программ». – Добросвет, 2006.
[Закрыть], и первоначально вы собирались встроить в браузер 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). Он сохранил за языком его динамическую окраску, но при этом вел борьбу за включение некоторых элементов, свойственных «программированию по-большому», например пространств имен.
Есть противоположный подход, более педантичный: «У нас будет лишь несколько примитивов, мы удалим из спецификации весь синтаксический сахар[46]46
Синтаксический сахар (syntactic sugar) – дополнения синтаксиса, которые не добавляют новые возможности, но делают язык программирования более удобным в использовании. – Прим. науч. ред.
[Закрыть]. Мы все переведем на лямбда-выражения. Так должен писать каждый, потому что я так думаю». Это упрощенчество, которое подходит не для каждого. Конечно, один из способов выстроить в уме собственную систему доказательств – это упрощать все, делить языки на подмножества. Мощный метод. Но ведь не каждый сможет программировать в крохотном подмножестве.
Сейбел: В одной из дискуссий по поводу 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 однажды умрет, но можно совершенствовать его, поддерживать его конкурентоспособность как в теоретическом, так и практическом плане. При условии, конечно, что мы не откажемся от сахара ради чистоты.
