Страница 18 из 30
Фицпатрик: По правде говоря, нет. Занятно смотреть, как люди высказывают твердое, ничем не подкрепленное мнение. Лично мне ручное управление памятью не кажется таким уж раздражающим, по крайней мере, в C++ с умными указателями. Я могу днями писать на C++, ни разу не применив явно оператор new или delete. Вот так.
Я переписал memcached, уже работая в Google, для работы с инфраструктурой Google и для добавления ее к Арр Engine[24]. Она написана целиком на C++, потому что мне было нужно очень строгое управление памятью для уменьшения фрагментации. И я очень рад возможности ручного управления памятью в C++.
Сейбел: Изначально программа memcached была написана на Си. Вы переписали ее на C++, потому что этот язык предпочтительнее в Google или у него есть другие преимущества?
Фицпатрик: Сперва я хотел просто взять существующую реализацию и перенести ее на C++, но работы оказалось слишком много. Оказалось не так много кода, которым я мог бы воспользоваться, поэтому было гораздо быстрее просто переписать его на C++. Объем кода уменьшился вдвое.
Сейбел: Это из-за C++ или из-за того, что вы стали опытнее?
Фицпатрик: Может, и из-за опыта. Лет в 11-12 я путешествовал с родителями по стране и писал игру Mastermind для калькулятора TI-85 — пару сотен строк — на крошечном экранчике, пытаясь понять, что же я делаю. Я дважды стирал эту проклятую штуковину. Так что я написал ее три раза. Но с каждым разом становилось все легче. Верно подмечено: разрабатывать систему во второй раз намного проще.
Сейбел: Вы много писали на Perl, весьма симпатичном высокоуровневом языке программирования. Как по-вашему, насколько «низко» нужно спускаться программистам? Нужно ли им знать ассемблер и понимать, как работает процессор?
Фицпатрик: Не знаю. Мне знакомы по-настоящему умные люди, я бы сказал, хорошие программисты, но которые знают только Java. Они думают о решении задачи в пределах известной им области. Они не думают о задаче от начала и до конца. По-моему, надо знать всю цепочку, даже если оперируешь только с одним звеном.
Занимаясь Живым Журналом, я думал о разных вещах, начиная от языка JavaScript и заканчивая вопросами взаимодействия с ядром операционной системы. Я читал код системных вызовов epoll[25] в ядре ОС Linux и думал: «А что если у нас будут все эти длительные соединения по протоколу TCP, и код на JavaScript будет опрашивать открытые TCP-соединения, ведущие к системе балансировки нагрузки?» Я попытался понять, сколько памяти нужно каждой структуре данных на одно подключение. Все это вопросы достаточно высокого уровня, но потом мы задумываемся, скажем, об огромном количестве прерываний от сетевой карты — не переключиться ли нам на использование NAPI ядра ОС вместо получения прерывания по каждому принятому пакету от сетевой карты, которые она будет соединять со скоростью, эквивалентной 100 мегабитам, даже для гигабитной сетевой карты? Мы собирали данные, чтобы определить, на каком уровне это будет иметь смысл и освободит процессор.
Мы много чего сделали для достаточно низкоуровневых вещей. Недавно кто-то сказал мне по какому-то поводу: «Java сам заботится об этом; нам не нужно думать об этом». Я ответил: «Нет, Java не может позаботиться об этом, потому что я знаю, какую версию ядра вы используете, и это ядро не поддерживает эту возможность. Ваша виртуальная машина может скрывать это от вас, предоставляя какие-то абстракции, которые выглядят эффективными, но они будут эффективными только при запуске на определенном ядре». Я расстраиваюсь, когда люди даже поверхностно не знают, как все устроено.
На практике никогда ничего не работает нормально. За прекрасными абстракциями скрывается всякая дрянь. Библиотеки могут выглядеть прекрасно, но работают отвратительно. И если именно вы отвечаете за покупку серверов или за поддержку, то очень полезно знать, что же на самом деле происходит внутри, не доверяя чужим библиотекам, коду и интерфейсам.
Я даже склоняюсь к мысли, что сегодня вряд ли стал бы программистом. Это совсем неинтересно. Вот почему мне так нравятся вещи вроде Арр Engine. Кто-то сказал, что Google Арр Engine — это Бейсик нашего поколения. Потому что для нынешнего поколения все перешло в Сеть. Когда я занимался программированием, был только один язык, и он был установлен на моей собственной машине, а для развертывания системы достаточно было нажать кнопку Run. Сегодняшние дети не хотят заниматься такими глупостями, как «прыгающие мячики» на собственном компьютере. Им нужен веб-сайт.
Мне до сих пор пишут что-нибудь вроде: «Привет, у меня появилась идея: я хочу сайт, который уделал бы Википедию, YouTube,...» Каждый хочет сделать веб-сайт, поскольку четыре его любимых веб-сайта не совсем правильны, и хочет что-то внешне похожее.
То, что Арр Engine предоставляет всего одну кнопку Put this on the Web (Выложить в Сеть) и можно писать все на одном языке — Python, который кажется довольно простым для изучения, — просто прекрасно. Это отличное введение в программирование — вас избавляют от множества уровней всякой ерунды.
Сейбел: Как же это вяжется с вашим расстройством по поводу поклонников Java, когда они говорят: «Java позаботится об этом за вас». Разве это не одно и то же, когда вы говорите: «Арр Engine позаботится об этом за вас»?
Фицпатрик: Не знаю. Может, просто мне известно, что происходит на самом деле. В принципе, JVM не так уж плоха. Думаю, проблемы начинаются тогда, когда люди принимают на веру некие абстракции, не понимая, что происходит на самом деле.
Сейбел: У вас был большой опыт программирования к тому времени, как вы поступили в колледж и начали слушать курс по компьютерным наукам. Как это вам помогло учиться?
Фицпатрик: Поначалу я пропускал много занятий по компьютерным наукам — такая была там скука. Я появлялся только на экзаменах.
Дальше, на третьем-четвертом курсе стало поинтереснее. Но тут, как назло, я окончил колледж. А на занятия магистров меня не пускали, ведь я не учился в магистратуре.
Помню, на курсе по компиляторам последнее задание было таким: взять один из существующих языков, с которыми мы возились, и добавить определенный набор возможностей, включая одну функцию по своему выбору, за которую полагались дополнительные баллы. Я решил реализовать проверку выхода за границы массива во время выполнения. Преподаватель взял мой скомпилированный код и запустил на нем свой набор тестов, и выполнение нескольких из них завершилось неудачно. Тогда он сказал: «Извините, но ваш код не прошел мои модульные тесты. Вы получаете тройку». Я посмотрел на код его тестов и сказал: «Так ваш тест содержит ошибку диапазона (off-by-one error)». Он исправил оценку на пятерку. Но дополнительных баллов я так и не получил и разозлился на колледж.
Еще помню курс по базам данных, который читал человек, видимо, без реального опыта работы с базами данных. А я в то время уже работал с Oracle, Microsoft Server и особенно плотно с MySQL. И я задавал вопросы практического характера, на которые хотел получить ответы — тогда они были актуальны для меня, — но мне выдали стандартную фразу из учебника. Я сказал: «Нет-нет, это не работает».
Сейбел: Вы окончили колледж в 2002 году. Теперь вы можете лучше оценить то, чему вас учили, или нет?
Фицпатрик: Половина курсов мне очень нравилась, я или узнавал что-то новое, чего в то время еще не знал, или получал соответствующие базовые знания и изучал правильную терминологию. До того я неплохо знал программирование, но у меня не было достаточного словарного запаса, чтобы объяснить то, что я делаю. Я мог выдумать собственную терминологию, но в результате люди могли бы подумать, что я не знаю, о чем говорю. В этом плане формальное образование помогло мне.
Сейбел: Вы сожалеете о том, что приходилось совмещать работу с учебой? Может быть стоило заниматься либо одним, либо другим?
24
Google Арр Engine — сервис хостинга сайтов и веб-приложений на серверах Google с помощью различных служб Google. См. http://ru.wikipedia.org/wiki/Google_App_Engine. — Прим. науч. ред.
25
epoll — новый системный вызов, который появился в Linux 2.6. Призван заменить устаревший select (а также poll). В отличие от старых системных вызовов, длительность работы которых зависела от количества прослушиваемых дескрипторов, epoll использует алгоритм, который не зависит от количества дескрипторов, позволяя добиться хорошего масштабирования при увеличении количества прослушиваемых дескрипторов. — Прим. науч. ред.