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

• Название: Кодеры за работой. Размышления о ремесле программиста
• Автор: Питер Сейбел
• Жанр: Биографии и Мемуары
• Год: 2011
• ISBN: 978-5-93286-188-2

Программисты - люди не очень публичные, многие работают поодиночке или в небольших группах. Причем самая важная и интересная часть их работы никому не видна, потому что происходит у них в голове. Питер Сейбел, писатель-программист, снимает покров таинственности с этой профессии. Он взял интервью у 15 величайших профессионалов: Кена Томпсона, создателя UNIX, Верни Козелла, участника первой реализации сети ARPANET, Дональда Кнута, Гая Стила, Саймона Пейтон-Джонса, Питера Норвига, Джошуа Блоха, Брэда Фицпатрика, создателя Живого Журнала, и других. Все они “подсели” на программирование еще в школе. Тогда, на заре зарождения отрасли, лишь в немногих учебных заведениях читались курсы по компьютерным наукам. Поэтому будущим гуру приходилось покорять профессиональные вершины самостоятельно, но всех их отличает творческое горение и полная самоотдача любимому делу.

Вы узнаете, что они думают о будущем программирования и как сами научились программировать, как, по их мнению, нужно проектировать ПО, как выбор языка программирования влияет на продуктивность и можно ли облегчить выявление труднонаходимых ошибок.

---

Сейбел: Вернемся к тем десяти дням, когда вы реализовали изначальную версию JavaScript. Я слышал, кто-то обратил ваше внимание на книгу Абельсона и Сассмана[45], и первоначально вы собирались встроить в броузер 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]. Мы все переведем на лямбда-выражения. Так должен писать каждый, потому что я так думаю”. Это упрощенчество, которое подходит не для каждого. Конечно, один из способов выстроить в уме собственную систему доказательств - это упрощать все, делить языки на подмножества. Мощный метод. Но ведь не каждый сможет программировать в крохотном подмножестве.

Сейбел: В одной из дискуссий по поводу 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 и делать первоначальные наброски.