Кодеры за работой. Размышления о ремесле программиста
Шрифт:
Стоять близко к “железу” для меня лично значило оставаться честным, избегая всякого дерьма. Но со временем, как известно, оборудование стало лучше, мы научились отделять хорошие абстракции от плохих. Наверное, сейчас можно не знать язык ассемблера и при этом быть хорошим программистом, писать грамотный код.
Сейбел: А если взглянуть с обратной стороны: может ли сегодня тот, кто раньше писал замысловатый код на языке ассемблера, успешно заниматься высокоуровневым программированием? Или здесь нужны разные навыки?
Айк: В некоторых областях эти навыки смыкаются. Есть разница между миром простых указателей и солнечным, радостным миром JavaScript.
Важно держать все в голове. Конечно, у всех разная память. Особо памятливые могут держать в уме набор высокоуровневых инвариантов при архитектуре с безопасным доступом к памяти, не заботясь при этом об указателях. Но иногда меня беспокоит, что мы постепенно утрачиваем способность писать для “железа”. Это делают другие; компилятор генерирует код. Видимо, спрос на таких людей будет расти.
Сейбел: Итак, этот вид программирования никуда не денется. А есть ли те, кто может быть успешным программистом сегодня, однако был бы беспомощен в мире низкоуровневого кода? Или программирование требует особого склада ума, и те, кто им обладает, просто разделились на низкоуровневых и высокоуровневых программистов?
Айк: Я давно не занимался кодом ядра, и если нужно будет заняться, это потребует от меня усилий. Теперь нужно писать больше кода. Кроме того, удачные абстракции позволяют сейчас справляться с задачами, не решаемыми в прошлом.
Сейбел: Вернемся к тем десяти дням, когда вы реализовали изначальную версию JavaScript. Я слышал, кто-то обратил ваше внимание на книгу Абельсона и Сассмана [45] , и первоначально вы собирались встроить в броузер Scheme.
Айк: Чем прежде всего были озабочены в Netscape? Все должно быть как в Java! Другие создавали алголоподобный синтаксис для Лиспа, но у меня не было времени взять Scheme за основу. Пришлось делать все напрямую, а значит, я мог совершать те же ошибки, что и другие.
45
X. Абельсон, Д. Д. Сассман “Структура и интерпретация компьютерных программ”.
– Добросвет, 2006.
Я не стал делать тотальный динамический контекст, на котором настаивал Стеллмен для Emacs и которым он наводнил Elisp. В JavaScript контекст в основном лексический, но есть отступления в виде динамических элементов: глобальный объект, оператор with, функция eval. Но ничего похожего на $-переменные в Perl до введения ту или на команды upvar и uplevel в Tel. В 1990-е все это было очень модно.
Однако я не остановился на Scheme - из-за спешки. Было очень мало времени, чтобы задуматься над последствиями своих действий. Я экономил усилия на многих объектах, которые должны были реализовы-ваться в броузере. Поэтому я сделал window глобальным объектом, который является источником связывания необъявленных новых имен и делает невозможными статические суждения о свободных переменных. А жаль. Дуг Крокфорд и прочие приверженцы объектной модели были недовольны тем, что вы получаете нежелательную власть над глобальным объектом. Это другой способ сказать то же самое. В JavaScript есть безопасные ссылки на объекты в памяти, и мы уже близки к цели, но остаются большие недочеты - те самые отступления.
Эти переменные, привнесенные на высокий уровень, теперь становятся изменяемыми свойствами объекта, которые можно тасовать как угодно за спиной у кого-то - это плохо. Должно быть лексическое связывание. Тогда, если спускаться вниз, к функциям
Сейбел: Выходит, сегодня для получения пространств имен создаются высокоуровневые функции?
Айк: Да. Функция создается и тут же вызывается. Это дает безопасную среду для связывания, приватные переменные. Дуг - ярый пропагандист всего этого. Тем, кто работал со 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] . Мы все переведем на лямбда-выражения. Так должен писать каждый, потому что я так думаю”. Это упрощенчество, которое подходит не для каждого. Конечно, один из способов выстроить в уме собственную систему доказательств - это упрощать все, делить языки на подмножества. Мощный метод. Но ведь не каждый сможет программировать в крохотном подмножестве.
46
Синтаксический сахар (syntactic sugar) - дополнения синтаксиса, которые не добавляют новые возможности, но делают язык программирования более удобным в использовании.
– Прим. науч. ред.