Текст книги "Кодеры за работой. Размышления о ремесле программиста"

Автор книги: Питер Сейбел

сообщить о нарушении

Текущая страница: 7 (всего у книги 41 страниц) [доступный отрывок для чтения: 15 страниц]

Стив Йегг (Steve Yegge) работает над проектом, который в основном заменил бы язык Elisp на JavaScript. Жду, пока он закончит, чтобы не учить еще один язык. Пишу все эти штуки на JavaScript, но не рассматриваю его как язык. Это язык для браузеров. В Google я много чего писал на JavaScript и потом встраивал это в Java и C++. Я понял, что JavaScript для этого отлично подходит.

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

Фицпатрик: Да, все настольные приложения. У меня их куча. Эти браузеры все время виснут, падают и занимают кучу памяти. Вся моя операционная система виснет. Коллеги, видя, как я работаю в Emacs, пытаются убедить меня, что Eclipse или IntelliJ все это делают у них автоматически. Раз в полгода я пробую то или другое. Но эти чертовы штуки просто крутятся там, съедая память и падая в процессе ввода (наверно, не справляются с тем, что я набираю). Ладно, фоновая подсветка синтаксиса или компиляция в другом потоке. Но зачем при этом блокировать ввод с клавиатуры? Что ж, снова попробую то или другое через полгода. И я счастлив, что не обязан использовать.все это. Мне и с Emacs неплохо.

Моя кривая обучения выглядит так: я быстро изучаю что-нибудь, пока не смогу работать с этим достаточно быстро и качественно. Обычно это где-то 80-90%, тогда я работаю весьма продуктивно, мне не приходится постоянно что-то искать, вот и отлично. После этого я продвигаюсь уже медленнее. И только если мне что-то очень уж приглянулось, говорю себе: «Пора поглубже изучить документацию этого языка – мануалы – и обшарить все потайные углы и щели».

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

Фицпатрик: Да, но для меня такие усилия всегда окупаются (по крайней мере, что касается редакторов). Когда я изучаю что-то, это окупается в течение недели, может быть двух. Если я пишу дурацкий скрипт командной оболочки или маленький скрипт на Perl, или еще что-то, что автоматизирует мою жизнь, это всегда окупается.

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

Фицпатрик: Нет. Я все это делаю с какой-нибудь целью. Да, я знаю тех, кто постоянно работает над своими инструментами, никогда ничего не доводя до конца. И я могу двинуться в этом направлении, но недалеко.

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

Фицпатрик: Мыслить как ученый; за один раз изменять только что-то одно. Терпение и стремление понять коренную сущность вещей. Это особенно ценно при отладке или проектировании чего-то, что не желает работать. Иногда молодые программисты говорят: «Черт, эта штука не работает», – и переписывают ее целиком заново. Стоп. Попытайтесь понять, что происходит. Научитесь разрабатывать программу шаг за шагом, так чтобы была возможность проверять ее на каждом шаге.

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

Фицпатрик: Иногда я отхожу от привычного пути – пишу что-нибудь на языке, которым обычно не пользуюсь. Я знаю, что это займет больше времени, но также знаю, что это все-таки благо. Например, когда я пришел в Google, мне часто приходилось писать всякие однодневные программы, и я всегда_#писал их на Perl. А потом сказал себе: «Стоп, а напишу-ка я это на Python». Теперь я пишу массу всего на Python, и это меня не напрягает – даже не приходится что-то искать. Perlbal был изначально написан на С#, просто чтобы выучить этот язык.

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

Фицпатрик: Коммуникабельность, хотя я не уверен, что ее действительно можно развить. Больше общайтесь по электронной почте. Умение общаться в письменном виде очень важно. Но оно и в жизни пригодится, правда? Было какое-то исследование насчет того, кто из выпускников более успешен – умные ребята или общительные? Выяснилось, что именно общительные ребята могут заработать любые деньги, а не те, кто хорошо учился. Думаю, это интересно.

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

Фицпатрик: Да, везде, где я работал, в проектах с открытым исходным кодом или в компаниях, все зависят друг от друга. Побудительный мотив: «Я напишу это, потому что знаю, что тебе это понадобится через две недели, или через две недели мне понадобится твое». Все это относится к человеческим взаимоотношениям.

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

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

Думаю, есть те, кто занимается этим только ради заработка, но на самом деле без удовольствия. Что нормально. Но зачем сравнивать их с программистами по призванию? Кто продуктивнее – тот, кто постоянно думает о деле, или тот, кто думает о нем только в рабочее время?

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

Фицпатрик: Ученым или инженером. Пожалуй, скорее инженером. А потом уже ученым – и только из-за принципа изменять за один раз что-то одно и подхода к диагностике проблем. Я считаю себя инженером в смысле подхода к проектированию. Среди моих друзей есть те, кто считает себя художником или ремесленником, но я о себе так никогда не думал.

Сейбел: С другой стороны, инженеры часто завидуют программистам. Помните шутку: «Если бы небоскребы строились так, как мы пишем программы, первый же дятел уничтожил бы цивилизацию». Как вы считаете, создание программного обеспечения – это понятная инженерная дисциплина?

Фицпатрик: Нет. Пока что это не так. Да, чтобы писать код, лицензия не нужна. Я не сторонник кучи предписаний, но не хотел бы, чтобы некоторые из РНР-программистов, допускающие все эти атаки через XSS, занимались системами управления полетами. Я бы предпочел, чтобы здесь была четкая официальная граница.

У меня есть друг, инженер-строитель, так он постоянно учится и получает все эти сертификаты. Как-то легче на душе от мысли, что те, кто строит мосты, по которым я хожу, тщательно изучают это дело, сдают множество тестов и постоянно учатся.

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

Фицпатрик: Понятия не имею. Страшно подумать об этом.

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

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

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

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

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

Фицпатрик: Конечно. Я постоянно занимаюсь всякой ерундой. У меня на мобильнике есть простая плоская игра. Как-то раз я так устал, что не мог делать ничего серьезного и написал программку, которая проходит эту игру. Я пробовал разные размеры доски, создал множество случайных досок и построил график количества ходов для досок разного размера. Я послал эту программу автору той игры, потому что в игре очень плохо оценивалась игра партнера. Обычно для успеха в игре нужно превзойти партнера. В моей почтовой рассылке все только и говорили о том, что игра из-за этого оказалась проще, чем ожидалось, поскольку оценка партнера бралась, по-видимому, с потолка. Так что я отправил ему график для каждого размера доски. Думаю, в новой версии автор это исправил. Это был забавный хак, на одну поездку домой. Я могу уволиться и заниматься подобными глупостями целый день.

3. Дуглас Крокфорд

Старший архитектор JavaScript в Yahoo! Дуглас Крокфорд занимается программированием с середины 1970-х – тогда, в колледже, не получив студийного времени по своему основному предмету – телевещанию, он прослушал курс Фортрана. Всю карьеру он совмещал программирование и медийную деятельность в таких компаниях, как Atari, Lucasfilm, Electric Communities, а теперь – Yahoo!.

Крокфорд по натуре склонен к простоте и аккуратности. Он изобрел JSON – формат передачи данных, широко применяемый в Ajax-приложениях, поскольку XML, с его точки зрения, слишком сложен. В его недавней книге «JavaScript: The Good Parts» (JavaScript: положительные стороны) утверждается, что JavaScript – весьма неплохой язык, если избегать некоторых его возможностей. В беседе со мной Крокфорд подчеркивает важность иерархии как способа борьбы со сложностью и описывает свой метод чтения кода, который начинается с его чистки.

Ко времени нашего интервью Крокфорд уже был известен как непримиримый критик ECMAScript 4 (ES4) – новой версии стандарта языка ECMAScript (JavaScript), поскольку считает ее слишком сложной. Он высказывался в пользу версии с менее масштабными изменениями – ES3.1. В конце концов, точка зрения Крокфорда и других защитников ES3.1 возобладала, версия ES3.1 получила название ES5, a ES4 была официально отвергнута.

Мы с Крокфордом беседовали о том, что ему не нравится в ES4, о важности чтения кода как части работы в команде и о том, как совершенствовать Сеть, несмотря на имеющиеся в ней старые системы.

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

Крокфорд: Я учился в Университете Сан-Франциско. Поступил туда потому, что там была хорошая система подготовки специалистов для телевидения. Но в первый год мне не удалось получить доступ к студии, и по счастливой случайности я решил посещать курс языка Фортран на математическом факультете. Оказалось, у меня прекрасно получается, так что я продолжил изучение в следующем семестре.

Это был 1971-1972 учебный год. В библиотеке хранилось множество перфокарт. Разделение времени только-только начало внедряться. В Университете Сан-Франциско не было сильного инженерного факультета, который бы занимался всеми компьютерами. Вместо этого они были распределены по всему колледжу. Свои лаборатории были на факультете естественных наук, в школе бизнеса, на гуманитарном и педагогическом факультетах. Интересно, что все эти факультеты использовали компьютеры.

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

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

Сейбел: Итак, вы начали с Фортрана и поняли, что делаете в нем успехи. Чем еще привлекало вас программирование, кроме мысли о том, что у вас это получается?

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

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

Крокфорд: Давно это было. Кажется это была программа дизассембли-рования работающей системы на Фортране для системы с разделением времени, которую я использовал. В процессе ее написания я понял, как работает система, и многое узнал о программировании, основанном на этой модели, включая некоторые вещи из того, что обычно не публиковалось.

Сейбел: По сравнению с тем временем, что больше всего изменилось в вашем подходе к программированию?

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

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

Крокфорд: Есть интересные языки, поработать с которыми мне так и не пришлось. Я много читал об APL и понимаю, почему он погиб, но это был очень логичный язык; жаль, что так и не удалось им позаниматься. Были и другие подобные языки, которыми я интересовался, читал о них кое-что, но так никогда и не получил шанса научиться думать на них.

Сейбел: Получив диплом телеведущего, чем вы занялись?

Крокфорд: Я поступал в магистратуру по технологиям образования. Но скоро понял, что знаю намного больше, чем мне преподают, и что все это пустая трата времени. Я бросил это дело где-то через год и пошел работать в Стэнфордский исследовательский институт в Менло-Парке. Потом я перешел в компанию Basic Four, которая производила миникомпьютеры для бизнеса, и проработал там довольно долго. Я разрабатывал текстовый процессор для компании и начал кое-какие исследования насчет переносных машин и персональных компьютеров. Я пытался обратить внимание компании на персональные компьютеры. Первым в компании купил персональный компьютер и оставил его на своем столе, чтобы инженеры приходили и смотрели на детище IBM.

Но мне так и не удалось изменить корпоративную культуру компании, поскольку они были слишком зациклены на том, что делают.

Однажды на Рождество, кажется в 1981 году, я купил Atari 800. В компьютерном магазине был еще Apple II, но Atari смотрелся шикарнее, и я выбрал его. Я думал написать на нем текстовый процессор или создать для него язык программирования. Но процессор 6502 был просто ни на что не способен. То есть я потратил две тысячи долларов на эту штуку, но что она может? Ну, хотя бы игры. Поэтому я начал создавать компьютерные игры, продал одну из них компании Atari и получил предложение поработать в их исследовательской лаборатории в Саннивейле[34]34
  Саннивейл – один из крупных городов Кремниевой долины. – Прим. науч. ред.


[Закрыть]. Это была лаборатория, организованная Аланом Кэем (Alan Kay), – первое, что он сделал со времен работы в Xerox PARC. Там было просто здорово. Я проработал там два года, наблюдая, как компания рассыпается. Но мне удалось сделать кое-что интересное и поработать с прекрасными людьми.

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

Крокфорд: Разве что потратил несколько четвертаков на Space Invaders и Рас-Man[35]35
  Space Invaders (Космические захватчики) – игра для игровых автоматов, Рас-Man (Пакман) – компьютерная игра в жанре аркады. Две эти игры, разработанные в Японии в конце 1970-х, стали культовыми и сильно повлияли на развитие компьютерной индустрии. – Прим. науч.ред.


[Закрыть]. Мне нравились игры, но их фанатиком я никогда не был. Компьютерные игры мне нравились как еще одно место взаимодействия компьютеров и телевидения. Первое такое место, открытое для широкой публики. По-моему, это было действительно интересно.

Сейбел: Что было после краха Atari?

Крокфорд: Я перешел в компанию Lucasfilm и работал там восемь лет.

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

Крокфорд: Конечно. Этот проект начал мой друг Чип Морнингстар. Он придумал аватары[36]36
  Аватар, или юзерпик (от user picture – картинка пользователя) – небольшое изображение, используемое для персонализации пользователя какого-либо сетевого сервиса. – Прим. науч. ред.


[Закрыть] и виртуальный графический мир. Сначала он занимался всем этим. Работало все это на компьютере 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; все они имеют одинаковый доступ к сети. Если какой-нибудь скрипт проберется на вашу страницу, он сможет зайти на сервер, представив себя в качестве вашего скрипта, и сервер никак не сможет отличить его от вашего.

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

Ситуация ухудшается еще и тем, что есть и другие пути попадания скрипта на вашу страницу. Архитектура Сети включает несколько языков: HTTP, HTML, язык URL-адресов, CSS и язык сценариев. Все они существуют и могут встраиваться друг в друга, обладая разными правилами цитирования (quoting), экранирования (escaping) и комментирования. Не во всех браузерах все эти правила реализованы одинаково. А некоторые из этих правил могут быть вообще не определены. Из-за этого злоумышленник легко может встроить какой-либо скрипт в URL, вставить его в кусок CSS, который затем вставить в HTML, а тот – в другой скрипт и так далее.

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

Крокфорд: Именно. Это ужасно. Нам нужно что-то с этим делать, потому что оставлять все это так совершенно не хочется.

В конце концов мы открыли мэшапы[37]37
  Мэшап (mash-up) – веб-приложение, объединяющее данные из нескольких источников в один интегрированный инструмент; например использует картографические данные Google Maps для добавления к ним данных о недвижимости с Craigslist, в результате создавая новый уникальный веб-сервис, изначально не предлагаемый ни одним из источников. – Прим. науч. ред.


[Закрыть]. Это как раз то, чего мы пытались добиться в области программного обеспечения в течение двадцати лет: компоненты многократного использования, которые можно объединять друг с другом, как детали в конструкторе LEGO, очень быстро создавая новые приложения. Мэшапы действуют аналогичным образом, и получается великолепно: берешь что-то из Yahoo!, что-то из Google, что-то свое, что-то чье-нибудь еще и делаешь из всего этого приложение. Класс! И все это делается в браузере, прямо у тебя перед глазами. Проблема одна: каждый из этих компонентов имеет доступ к тому же, что и другие. Мы сознательно создаем условия для XSS-атак. Модель безопасности браузеров не ожидает от этого ничего хорошего и не предоставляет никаких механизмов взаимодействия при взаимном недоверии. Вся всемирная Сеть построена на сплошных ошибках. Результат – множество неприятностей.

Сейбел: Можно ли из всего этого сделать вывод, что все усилия по принятию стандарта ES4[38]38
  Имеется в виду четвертая версия стандарта ECMAScript, работа над которой так и не была завершена. – Прим. науч. ред.


[Закрыть] относятся к альтернативным издержкам и все думают именно об этом, а не о том, как избавиться от имеющихся проблем?

Крокфорд: Именно так. Этот стандарт решает не ту проблему. Он решает проблему, связанную с тем, что люди ненавидят JavaScript. И я могу понять позицию Брендана Айка, поскольку он проделал потрясающую работу, но он торопился, допускал ошибки в руководстве, и в итоге вышла полная ерунда. Его ругали и поносили последние двенадцать лет за его глупость и за то, что он создал глупый язык, но все это не так. Там есть блестящие идеи, и сам Брендан – блестящий парень. Он сейчас пытается оправдаться и доказать, что действительно умен, и показать это всем с помощью языка, который будет содержать все классные возможности, которые он когда-либо видел, объединенные и работающие все вместе.

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

Думаю, нужно двигаться шаг за шагом. Если у нас появится модульность или возможность выбирать язык программирования, это уже будет шаг вперед. Это еще не все, что нам нужно, но гораздо больше того, что есть у нас сейчас. Потом есть такие вещи, как Caja и ADsafe, пытающиеся сделать то же самое с помощью сегодняшних технологий. Мы не можем ждать.

ADsafe создает безопасное подмножество языка JavaScript, блокируя доступ ко всему глобальному и опасному. Но даже это подмножество все еще представляет собой полезный язык. У нас все еще остаются лямбда-выражения, а они могут многое. Таким образом, это нестандартный язык. Он не позволяет использовать прототипы так, как мы уже привыкли. Но этот язык остается невероятно мощным, поскольку в нем присутствуют лямбда-выражения.

Сейбел: Возвращаясь к ES4: есть ли в нем хоть что-то, что вам нравится с точки зрения языка?

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

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

Сейбел: Google Web Toolkit (GWT) позволяет компилировать Java в JavaScript. Многие уже пробовали компилировать другие языки в JavaScript. Это правильный путь?

Крокфорд: Любопытно наблюдать, как JavaScript становится универсальной средой выполнения. Мы никогда не ожидали увидеть его в такой роли.

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

Крокфорд: Что тем более заставляет нас обратить внимание на производительность. Особенно при переходе на мобильные платформы, к которым закон Мура неприменим. Здесь уже имеет большое значение то, сколько времени мы тратим на интерпретацию. Все это дополнительные такты процессора. Так что, думаю, это должно дополнительно улучшить качество среды выполнения.

Я придирчиво наблюдаю за тем, чего достигли GWT и другие средства преобразования. С этими средствами очень трудно работать – если найдете что-нибудь работающее, вам повезло. Лично я опасаюсь использовать их, поскольку боюсь дыр в абстракциях[39]39
  Закон дырявых абстракций, сформулированный Джоэлом Спольски, гласит, что использование абстракции любой нетривиальной концепции в любом случае потребует от ее пользователя четкого понимания внутренних аспектов реализации, в противном случае он рано или поздно столкнется с проблемами, с которыми не сможет справиться. См. http://www.joelonsoftware.com/articles/LeakyAbstractions.html – Прим. науч. ред.


[Закрыть]. Если возникнут проблемы с вашим Java-кодом, или с GWT, или со сгенерированным кодом, то у вас может быть, а может и не быть возможности справиться с этим. Особенно в том случае, если предпочтете ничего не знать о JavaScript, поскольку этот язык скрыт от вас. Тогда, если что-то пошло не так, вы столкнетесь с огромными проблемами. Я пока не слышал о подобных случаях, и это значит, что те, кто этим занимается, делают всё правильно. Но такой риск определенно есть.

Сейбел: Каким бы вы хотели видеть JavaScript?

Крокфорд: Думаю, лучший способ усовершенствовать JavaScript – сделать его более компактным. Если бы можно было оставить только те возможности, которые работают действительно хорошо, убрав малозначительные или ненужные, то мы бы действительно получили заметно улучшенный язык. И я думаю, что этот же подход применим и к HTML, и к HTTP, и к CSS. Мне кажется, что работая со всеми этими стандартами, нужно выяснить, что они делают правильно, а чего в них не хватает, и на этом основании переориентировать их, а не просто добавлять новые функции поверх существующих.

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