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

Я не стал делать тотальный динамический контекст, на котором настаивал Стеллмен для 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] Синтаксический сахар (syntactic sugar) - дополнения синтаксиса, которые не добавляют новые возможности, но делают язык программирования более удобным в использовании. - Прим. науч. ред. . Мы все переведем на лямбда-выражения. Так должен писать каждый, потому что я так думаю”. Это упрощенчество, которое подходит не для каждого. Конечно, один из способов выстроить в уме собственную систему доказательств - это упрощать все, делить языки на подмножества. Мощный метод. Но ведь не каждый сможет программировать в крохотном подмножестве.