Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Я говорил об этом Дугу Крокфорду несколько лет назад, когда он пригласил меня выступить в 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 что-нибудь повлияло отрицательно — то есть в смысле «я так ни за что не сделаю»?
Айк: Работа была очень спешной, и я не сильно задумывался о том,
Сейбел: Вы думали о том, чтобы сделать язык, стоящий ближе к Java, — взять Java и упростить, избавиться от примитивных типов и прочих ненужных сложностей?
Айк: Со стороны руководства ощущалось давление: они хотели, чтобы синтаксис был похож на тот, что в Java. Еще они хотели, чтобы язык не становился слишком объемным, — для сложного программирования был Java, а наш язык замышлялся как его младший брат.
Сейбел: Чтобы напоминал Java, но не слишком.
Айк: Не слишком. Если бы я ввел классы, то столкнулся бы с большими проблемами. У меня и времени, правда, на это не было, но я бы их все равно не ввел.
Сейбел: Вернемся в наши дни. ES4 была официально отвергнута, и сейчас идет работа над ES-Harmony, сочетающей черты ES3.1.H ES4. Как вы полагаете, это удачное решение?
Айк: Дуг, пожалуй, слишком уж торжествовал в своем блоге: «Мы победили. Мы одолели дьявола». Год назад я подарил ему в Лондоне шуточный слайд: Дуг в виде Гэндальфа на мосту в Казад-Думе, глядящий вниз на ниспровергнутого ES4pora. Ему очень понравилось. Я впервые подшутил так над ним — его порой оставляет чувство юмора, когда он касается этих проблем. Но ему понравилось. Может, он и герой, но ES4 совсем не был чудовищем.
ES4, как мне кажется сейчас, был слишком объемным. Но нам нужно было прагматично подойти к стандартам. Мы не могли сказать: «Все, что вам нужно, — это лямбда-выражения». Алонзо Чёрч доказал, что это не так. И мы не могли вставлять еще больше таких выражений. Такой подход, предполагающий высокую квалификацию каждого, многого не учитывает, например того, что многих программистов в Java-вузах научили плохому. JavaScript однажды умрет, но можно совершенствовать его, поддерживать его конкурентоспособность как в теоретическом, так и практическом плане. При условии, конечно, что мы не откажемся от сахара ради чистоты.
Язык должен совершенствоваться, чтобы можно было решить стоящие перед программистами задачи. С некоторыми можно справиться, если писать собственные библиотечные абстракции. Но возможность написания абстракций для языка очень ограничена, если нет расширений — вы не можете написать геттеры и сеттеры [47] . Объекты будут смотреться чужеродно, свойства не смогут стать кодом и так далее. Кроме того, вопросы безопасности нельзя будет разрешать неявно или автоматически.
47
Геттер, сеттер — специальные методы, используемые в объектно-ориентированном программировании и позволяющие реализовать гибкий меха низм инкапсуляции. – Прим. науч.ред.