можем себе это позволить.
Сейбел: Есть ли сожаления по поводу того пути, который вы выбрали, изучая программирование?
Крокфорд: Есть интересные языки, поработать с которыми мне так и не пришлось. Я много читал об APL и понимаю, почему он погиб, но это был очень логичный язык; жаль, что так и не удалось им позаниматься. Были и другие подобные языки, которыми я интересовался, читал о них кое-что, но так никогда и не получил шанса научиться думать на них.
Сейбел: Получив диплом телеведущего, чем вы занялись?
Крокфорд: Я поступал в магистратуру по технологиям образования. Но скоро понял, что знаю намного больше, чем мне преподают, и что все это пустая трата времени. Я бросил это дело где-то через год и пошел работать в Стэнфордский исследовательский институт в Менло-Парке. Потом я перешел в компанию Basic Four, которая производила миникомпьютеры для бизнеса, и проработал там довольно долго. Я разрабатывал текстовый процессор для компании и начал кое-какие исследования насчет переносных машин и персональных компьютеров. Я пытался обратить внимание компании на персональные компьютеры. Первым в компании купил персональный компьютер и оставил его на своем столе, чтобы инженеры приходили и смотрели на детище IBM.
Но мне так и не удалось изменить корпоративную культуру компании, поскольку они были слишком зациклены на том, что делают.
Однажды на Рождество, кажется в 1981 году, я купил Atari 800. В компьютерном магазине был еще Apple II, но Atari смотрелся шикарнее, и я выбрал его. Я думал написать на нем текстовый процессор или создать для него язык программирования. Но процессор 6502 был просто ни на что не способен. То есть я потратил две тысячи долларов на эту штуку, но что она может? Ну, хотя бы игры. Поэтому я начал создавать компьютерные игры, продал одну из них компании Atari и получил предложение поработать в их исследовательской лаборатории в Саннивейле[34]. Это была лаборатория, организованная Аланом Кэем (Alan Kay), — первое, что он сделал со времен работы в Xerox PARC. Там было просто здорово. Я проработал там два года, наблюдая, как компания рассыпается. Но мне удалось сделать кое-что интересное и поработать с прекрасными людьми.
Сейбел: До этого вы увлекались компьютерными играми?
Крокфорд: Разве что потратил несколько четвертаков на Space Invaders и Рас-Man[35]. Мне нравились игры, но их фанатиком я никогда не был. Компьютерные игры мне нравились как еще одно место взаимодействия компьютеров и телевидения. Первое такое место, открытое для широкой публики. По-моему, это было действительно интересно.
Сейбел: Что было после краха Atari?
Крокфорд: Я перешел в компанию Lucasfilm и работал там восемь лет.
Сейбел: И разработка игры Habitat началась, когда вы работали там.
Крокфорд: Конечно. Этот проект начал мой друг Чип Морнингстар. Он придумал аватары[36] и виртуальный графический мир. Сначала он занимался всем этим. Работало все это на компьютере Commodore 64 и ненагруженных сетях Х.25. Проект был невероятно дальновидным, с огромным количеством правильных решений, просто потрясающе. Я наблюдал со стороны, подбадривал их, но в том, что они сделали, моей заслуги нет.
Сейбел: А потом вы вместе ушли и основали Electric Communities, которая построена на этих идеях?
Крокфорд: Да. Морнингстар и Рэнди Фармер ушли из Lucasf ilm и основали компанию American Information Exchange, в которой применили идею социальной сети к онлайновым рынкам. Блестящая идея, но увы, опередившая свое время. Сделав это несколько позже, они могли бы стать чем-то вроде eBay.
Потом у нас появилась идея: давайте попробуем снова и создадим общую платформу, которая бы занималась развлечениями, социальными вещами, бизнесом — да чем угодно, — создадим платформу для всего мира. У нас были кое-какие мысли насчет того, как сделать ее полностью распределенной, чтобы не было единственного сервера, а она была бы распределена по всему Интернету. И мы придумали модели обеспечения безопасности, которые позволили бы ей быть полностью децентрализованной. Эта действительно отличная идея и привела к созданию Electric Communities.
Сейбел: Именно там и была создана первая версия языка Е.
Крокфорд: Совершенно верно. Нам нужен был безопасный язык для разработки платформы и приложений под нее. Сначала мы пытались использовать язык Joule компании Agorics. Это был язык на основе модели акторов, и многое в нем делалось необычным способом; язык был блестящий, но слишком уж непривычный.
У нас были сомнения по поводу Joule. Мы собирались научить людей пользоваться этим языком. Но не слишком ли он экстравагантен? Тогда у нас появилась идея насчет языка E, который заимствовал основные концепции акторов языка Joule и был построен поверх языка Java.
Сейбел: Применялся ли язык E кем-нибудь, кроме его создателей?
Крокфорд: В своей первоначальной версии — нет. Старый E был диалектом Java. Из-за этого у нас возникали всякие проблемы с компанией Sun. Потом мы разработали язык сценариев E — более легкий, но с аналогичными возможностями. Именно этот язык сейчас известен как E.
Мы разработали этот язык в компании Electric Communities, но, кажется, так его и не использовали. В какой-то момент мы просто решили, что не будем его использовать. Несмотря на это язык оказался неплох, и мы продолжали его развивать. И я рад, что он все же выжил.
Один из плюсов работы в Electric Communities — там я научился думать в терминах замыканий. А начав заниматься Сетью, посмотрел на JavaScript и сказал: «Кажется, мне это знакомо». Ведь JavaScript многое унаследовал от Scheme, но из документации не понять, что в нем есть замыкания. Так что я открыл это случайно и сказал себе: «Ого, здорово!» И стал продвигать идею, что на этом дурацком маленьком языке можно делать серьезные вещи.
Сейбел: Это возвращает нас к недавним спорам по поводу ECMAScript 4. Как я понял, вам нравится простота версии ES3 JavaScript.
Крокфорд: Ну, в конечном счете значимость изменений, которые можешь внести в язык, зависит от успеха этого языка. Чем более успешен язык, тем выше цена вносимых изменений. Возрастает цена переобучения людей, кроме того, цена возможной неудачи при подобном росте становится неприемлемой. Если язык действительно успешный, нужно быть очень осторожным в плане изменений. В то же время, если язык пока не выпущен, свободы для внесения изменений гораздо больше.
JavaScript стал самым популярным в мире языком программирования чисто случайно. Сейчас процессоров, на которых могут выполняться программы на JavaScript, гораздо больше, чем для любого другого языка программирования. И несмотря на все проблемы с безопасностью, JavaScript — единственный язык, который даст вашему коду запуститься на каком угодно компьютере.
Но это еще не все: он встроен во множество приложений. Большинство приложений компании Adobe поддерживает JavaScript, так что вы можете использовать его локально. Многие другие приложения также поддерживают эту возможность. То есть он становится невероятно популярным.
Проблема с этим языком в том, что он ворвался на рынок слишком быстро и так же слишком быстро был стандартизирован. Так что большинство его недостатков связаны не с текущей реализацией, а находятся в спецификации. Стандарт указывает делать это неправильно. А это просто ужасно. Но ситуация именно такова. В 1999 году развитие этого языка замерло, все должны были его забыть, и он должен был умереть. Но вместо этого совершенно случайно возник Ajax, и теперь JavaScript — самый важный язык программирования в мире.
И теперь мы думаем, что должны его как-то исправлять. Это нужно было сделать еще в 2000-м, но тогда этого никто не сделал, поскольку на него тогда никто не обращал внимания. Теперь же это сделать очень сложно.
Есть еще одна особенность JavaScript в контексте Сети. Обычно, разрабатывая серверное, прикладное или встроенное (embedded) приложение, выбираешь не только язык, но и компилятор, и среду выполнения. Однако в случае JavaScript нет такого выбора: нужно, чтобы код работал на чем угодно.
Поскольку код должен выполняться на чем угодно, ошибки не исправляются. Если разработчик браузера выпустит его с ошибкой, то скажет: «Ой, мы лажанулись», — и на следующий месяц выпустит следующую версию с другой ошибкой, а мы не можем подстраиваться под все обновления, которые устанавливают их пользователи. Большинство пользователей, установив однажды Internet Explorer, никогда его не обновляют. Ошибки в этом браузере остаются с ними годами.
Сейбел: То есть ситуация сейчас именно такова. Но вы хотите сделать Сеть более совершенной платформой для разработки приложений. Если мы не можем исправить свои ошибки, пока разработчики браузеров не исправят собственные, если даже и это не помогает, значит, мы в тупике. Где же выход?
Крокфорд: Как раз этим я и занимаюсь. Я вижу идеальное решение. Я знаю, каким оно должно быть. Знаю, где мы находимся, и вижу все преграды на нашем пути. И пытаюсь придумать, каким образом нам выйти из этого положения. Мы оказались в ловушке, в том смысле что разработали громоздкие системы — экономические, социальные, технические, которые в значительной степени зависят от этих непродуманных решений.
Несомненно, худшей особенностью JavaScript является зависимость от глобального объекта. В JavaScript нет компоновщиков и информация между элементами компиляции никак не скрывается. Все объединяется в общий глобальный объект. Так что каждый компонент видит все остальное; все компоненты имеют равноправный доступ к DOM; все они имеют одинаковый доступ к сети. Если какой-нибудь скрипт проберется на вашу страницу, он сможет зайти на сервер, представив себя в качестве вашего скрипта, и сервер никак не сможет отличить его от вашего.