Расмус Лердорф, создатель PHP: «Я хочу делать вещи для реальных людей»

Человек, придумавший один из самых распространенных языков программирования — 44-летний Расмус Лердорф (Rasmus Lerdorf), — родился в Гренландии, а последние годы живет в США. Впрочем, «живет» — громко сказано: по словам самого Лердорфа, очень много времени он проводит в путешествиях по самым разным странам, встречаясь с людьми, использующими PHP в самых разных сферах жизни.

В начале октября Расмус Лердорф участвовал в конференции IDCEE’13  в Киеве, где я и смог пообщаться с ним и задать часть вопросов, предложенных читателями DOU на форуме .

— Как продвигается работа над PHP 5.6?

— Процесс идёт. Люди предлагают новые функции и возможности, сообщество голосует и обсуждает их, и если большинство «за» — они внедряются в проект. Потом в какой-то момент мы сделаем его «слепок», проверим, чтобы в нем было достаточно тестов и выпустим PHP 5.6. Думаю, это случится примерно в июне-июле 2014 года, но начинать работать нам нужно уже сейчас.

— В одном из предыдущих интервью вы говорили, что в команде разработчиков PHP нет структуры. Действительно ли это так, и как вообще выглядит процесс разработки?

— В отличие от многих других проектов с открытым исходным кодом, которыми занимается в первую очередь какая-нибудь компания с программистами на зарплате, разработкой PHP занимаются исключительно добровольцы. Можно сравнить, например, с MySQL: есть компания MySQL, и она платит программистам, которые обычно и делают большую часть работы. Или, скажем, Mongo — большая компания с хорошим финансированием, которая оплачивает труд разработчиков. Они могут строить планы, устанавливать дедлайны, даты релизов и диктовать разработчикам, чем им заниматься.

Я не могу этого делать в проекте, который делается на добровольных началах. Волонтеры-программисты приходят и уходят, когда хотят, и делают только то, что им нравится. Так что я не могу объяснить структуру команды — нет никакой структуры, есть просто люди, которые занимаются тем, чем они увлекаются.

— Значит, добровольцы работают над чем хотят, а вы делаете всё остальное?

— Ну, не без того. Я делаю много вещей, которые не имеют отношения конкретно к коду — это связано с инфраструктурой, с работой Git-сервера, например, или почтовыми рассылками. Некоторые добровольцы берут на себя скучную работу — и это прекрасно; им, видимо, нравится скрупулезно и внимательно проверять мельчайшие детали, мониторить системы, писать тесты, настраивать Jenkins и всё такое. Всё это очень важно, но если у нас не будет добровольцев, многие задачи просто не будут выполнены. Иногда релиз не выходит вовремя, потому что программист, который работает над ключевой частью проекта, ушел в отпуск, или у него родился ребенок.

— Это анархия.

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

— А вы сами не думали о том, чтобы основать компанию вроде MySQL и структурировать разработку PHP?

— Нет.

— Вам не нравится, как компании разрабатывают языки?

— PHP — просто инструмент, с помощью которого можно сколотить классные штуки. И мне нравится именно это — то, что создано с помощью PHP. Я никогда не работал в компании, производящей инструменты; много лет я проработал в Yahoo, потом в WePay, сейчас — в Etsy. Это компании, которые работают для нормальных, обычных людей, и PHP — их неотъемлемая часть. Это инструмент, которым мы пользуемся, чтобы делать вещи для реальных людей.

А компании, которые делают инструменты, работают не для людей, а для программистов — как Mongo, как MySQL и т.п. Если выйти на улицу и спросить обычных людей, слышали ли они о Mongo или MySQL, никто не ответит утвердительно. И про PHP никто из них не слышал, и это хорошо.

С другой стороны, если выйти на улицу и спросить людей, слышали ли они о Facebook, что они ответят? Все скажут, что слышали. Меня интересуют именно такие продукты, я хочу делать вещи для реальных людей. Вы спрашиваете, почему я не хочу основать компанию для разработки PHP? Он не касается реальных людей, только придурков типа меня; к тому же делать что-то для программистов — очень раздражающее занятие.

— Означает ли это, что в какой-то момент вы забросите PHP или станете уделять ему меньше времени?

— Единственная причина существования PHP состоит в том, что это инструмент для создания продуктов для реальных людей. И мне нужен этот инструмент, без него я не могу этого делать; это же относится и ко многим компаниям. Мне нравится заниматься PHP, но мне нужно видеть эффект для реальных людей: если я его не вижу, мне нет смысла продолжать это делать.

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

— Кстати, об инструментах. Многие разработчики на других языках часто смотрят на PHP свысока. Вы наверняка слышали мнения, что это язык для низкоквалифицированных программистов, что на PHP нельзя написать что-то серьезное и т.п. Что вы об этом думаете?

— Просто посмотрите на долю рынка, на то, на скольких серверах работает PHP-код. И это неправда, что на PHP нельзя написать что-то серьезное. Я видел исследование, согласно которому 72% из 1 млн наиболее посещаемых сайтов работают на PHP.

— Учитывая все последние скандалы с американскими спецслужбами, я не могу не задать этот вопрос: есть ли в PHP бэкдоры?

— Что прекрасно в проектах с открытым кодом, так это то, что я вообще никак не могу спрятать в нем бэкдор. Если вы загружаете скомпилированное приложение от Microsoft или Oracle, вы понятия не имеете, что там внутри. Конечно, большинство пользователей загружают PHP тоже в уже скомпилированном виде вместе с операционной системой — Ubuntu, или Debian, или RedHat... Но мы публикуем исходный код, а значит, что если появляется бэкдор, то его могли добавить только уже на уровне ОС. Если бы мы это сделали в исходниках... представляете, сколько людей их читают?

— Честно говоря, нет.

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

Впрочем, опасность всё равно есть, но на гораздо более низком уровне. NSA может иметь влияние на стандарты шифрования, на криптографические библиотеки, от которых многое зависит. Не только PHP, но практически всё, что можно представить, базируется на определенных криптографических алгоритмах; и если бы кто-то встроил бэкдор на этом уровне, то да, никто бы этого не увидел. Но в самом PHP — ни в коем случае.

Прошлое и настоящее

— Если бы вы могли изменить что-то из того, что сделали (или не сделали) за годы работы над PHP, что бы это было?

— В общем, всё, что я сделал, имело смысл с учётом того, как в то время выглядел веб и сколько людей использовало PHP. Но если бы 20 лет назад я знал, что PHP проживет так долго и им будут пользоваться миллионы людей, я бы убрал оттуда многое из того, что мы убрали позже.

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

Изначально я представлял PHP как шаблонный язык, где можно было добавлять собственные специальные тэги; и тэги PHP были похожи на HTML, чтобы людям было проще его осваивать. Но в какой-то момент PHP стал чем-то большим, и чувствительность к регистрам стала иметь смысл. Я должен был ввести её прямо тогда, но я помню свои мысли: «PHP используется на 20 тысячах серверов, и всем этим людям придется править свой код!» Конечно, сейчас я понимаю, что лучше было сделать это с 20 тысячами серверов, чем с миллионами, как сейчас.

Есть ещё несколько подобных примеров. Если бы я знал, что язык проживет 20 лет и соберет миллионы пользователей, я бы принимал другие решения. Но в то время это был просто молоток, который я сделал для себя.

— То есть, планов покорить мир не было?

— Абсолютно. Это был просто инструмент, с которым я мог программировать быстрее и эффективнее и не писать один и тот же код много раз. Я просто упаковал его в библиотеку функций и опубликовал её. У меня была шаблонная система, и в итоге я мог разворачивать динамические веб-приложения очень быстро: там, где другим требовались две недели, я делал всё за день. Многие интересовались, как я делаю всё так быстро, и просили разрешения использовать этот «молоток». Я разрешал, без проблем.

— Планируется ли глобальный рефакторинг стандартных библиотек, чтобы избавиться от запутанных имен функций и их использования?

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

Есть предложения сделать объектный механизм, с которым можно вызывать методы для строк. Но это сложно сделать правильно, к тому же мне не нравится, что это требует строгой типизации. Если, например, вы вызываете строчную функцию для целого числа, а она не работает, то это фигня, потому что веб не типизирован. Когда браузер отправляет информацию, вы получаете только строки; даже если речь идет о числе — скажем, возрасте, — то это всё равно строка. И нужно, чтобы можно было взять это число и работать с ним как со строкой без всяких сложностей.

Одна из причин стремительного развития и распространения PHP заключается в том, что в большинстве случаев он делает то, что разработчик от него ожидает. Хотя, конечно, бывает и иначе, когда программист думает об одном, а язык делает другое; и тогда разработчики выходят из себя. Но надо понимать, что программирование невозможно без определенных компромиссов, так что мы часто выбираем меньшее зло при разработке новых возможностей.

Когда с одной стороны есть код на PHP, написанный начинающими программистами в качестве хобби, а с другой — компаниями вроде Wikipedia, Yahoo или Facebook, развитие языка усложняется на порядки. Продвинутые разработчики будут жаловаться на возможности, созданные для любителей, и наоборот; невозможно сделать всех счастливыми. Чтобы все были довольны, нужно было бы сосредоточиться только на одной группе, и мы могли бы это сделать, но ведь гораздо интереснее создавать язык, которым могут пользоваться все.

— Довольны ли вы тем, как развивается PHP?

— Из-за того, что все наши программисты — добровольцы, и занимаются тем, что им нравится, недостаточно людей работают над такими вещами, как надежность и защищённость, где нужно обрабатывать баг-репорты и находить редкие случаи, в которых без видимых причин выпадает segfault. Обычно это очень странные случаи, и разобраться в них очень непросто.

Главная причина сложности — то, что баг-репорты обычно написаны плохо. Они не объясняют поледовательность действий, там просто написано «Всё сломалось», и приходится долго задавать наводящие вопросы, чтобы понять, что же именно случилось. Это огромное количество работы, особенно когда на другом конце — человек, не очень хорошо объясняющий баги; а надо сказать, что, в общем, никто не объясняет баги хорошо. Одна такая задача может занять три дня.

Поскольку разработка новых возможностей движется довольно быстро — скажем, временной разрыв между PHP 5.4 и 5.5 был небольшим, плюс в PHP 5.6 тоже будет много новых фич, — я переживаю за надежность всех этих нововведений. Проверка всех «крайних случаев» с их использованием занимает некоторое время, и часто разработчики стремятся скорее двигаться дальше, к новым задачам.

— Вы действительно видите уменьшение надежности языка, или это только теория?

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

Лирическое отступление: поддержка Unicode

— Что сейчас происходит с нативной поддержкой Unicode? В чем заключается главная проблема?

— Собственно, приложения с поддержкой Unicode можно писать на PHP и сейчас, вопрос в том, как именно это делается. У нас есть расширение для библиотеки ICU от IBM, и эта библиотека может сделать всё что угодно. Любую проблему с Unicode сейчас можно решить. Но обычно людей интересует возможность делать это легко и не задумываться на эту тему; именно это мы и хотели сделать в PHP 6.

Главный вопрос с Unicode заключается в том, как упростить работу с ним и сделать её приятной. Сейчас уже можно решить любую проблему, связанную с Unicode, но это не выглядит красиво, Unicode — не умолчание. Нам в первую очередь мешает тот факт, что библиотека ICU основана на UTF-16; к тому же она большая и сложно организованная, и работа с ней раздражает. Что нам действительно нужно — да и не только нам, а, думаю, всему сообществу Open Source, — так это хорошая стандартная библиотека, основанная на UTF-8, которую будут использовать все. Но её нет, и это проблема.

Одной из серьезных сложностей в попытке создания PHP 6 было то, что нам нужно было работать с UTF-16 внутри, но при этом быть полностью совместимыми с UTF-8 снаружи. То есть каждый раз при вводе и выводе данных нужно было конвертировать их из UTF-16 в UTF-8 или наоборот.

Я надеюсь, что со временем всё в мире будет работать с UTF-8. Я жду, когда все поймут, что им нужно пользоваться UTF-8, и появится эта самая библиотека. Если бы она была, всё можно было бы сделать красиво и удобно. Вообще, в условиях такого бардака я впечатлен тем, как удачно некоторые проекты смогли организовать работу с UTF-8. Многим, впрочем, это не удалось: мне не нравится идея с ustring в Python, например, где нужно отдельно указывать Unicode-строки.

— И кто, по-вашему, должен и/или может написать такую библиотеку? Может ли в этом помочь PHP-сообщество?

— Библиотека ICU по объему примерно в 10 раз больше и сложнее, чем весь PHP. Соответственно, когда мы добавили поддержку ICU в PHP, это скорее было добавление маленького PHP к ICU. Она огромная.

В принципе, мы бы могли написать новую библиотеку, но тогда нам пришлось бы потратить на это следующие три года, в течение которых мы бы не притрагивались к PHP. Да и вообще я бы предпочел, чтобы этим заимались Unicode-гики. Может, и сама команда, которая занимается ICU, могла бы сделать следующее поколение библиотеки — меньше, быстрее, современнее. Текущей версии уже 15 лет, и это ощущается — она очень громоздкая. Было бы здорово, если бы IBM выделила 50 разработчиков на такую задачу.

— И какова вероятность того, что это случится?

— Понятия не имею.

Технические вопросы

— Какие изменения происходят в поддержке MySQL?

— Поддержка никуда не девается, но мы пытаемся упразднить само расширение MySQL, чтобы люди пользовались MySQLi или PDO_MYSQL. Это имеет смысл, потому что они — и особенно MySQLi с нативным драйвером Mysqlnd, — действительно лучше и удобнее. MySQLi использует менеджер памяти PHP, может сохранять копии и кучу всего другого, позволяет выполнять асинхронные запросы и т.п. Мы хотим, чтобы люди могли всем этим пользоваться, но это невозможно через старый API.

Можно ещё добавить, что есть MariaDB — очень интересное решение, но тут нет никаких сложностей и тонкостей. Она использует тот же протокол, и если вы используете её вместо MySQL, ваш выбор всё равно MySQLi или PDO.

— А что с поддержкой NoSQL?

— У нас есть поддержка для всех баз данных. Неплохая поддержка для MongoDB — кстати, несколько разработчиков PHP работают в Mongo, и ещё несколько — в Oracle; есть хорошая поддержка Redis, мы и сами используем его для некоторых вещей.

PHP дошел до стадии развития, когда мы уже не должны сами заниматься поддержкой таких вещей. Когда люди выпускают новый продукт, они понимают, что поддержка PHP может помочь им в поиске и удержании пользователей. В старые времена было наоборот: мне нужно было добавлять поддержку как можно большего числа продуктов в PHP, чтобы получить traction. Теперь он у меня есть.

— А что вы думаете о противостоянии SQL и NoSQL? И есть ли оно вообще?

— Гики могут спорить о чем угодно. Насколько я вижу, всё «противостояние» — это спор гиков, которым просто не о чем больше беспокоиться. Для SQL и NoSQL есть свои применения, хотя я иногда вижу, как люди внедряют нереляционную базу там, где явно нужна реляционная (и наоборот), а потом пытаются с этим жить, — это безумие.

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

— Какие запланированные возможности PHP вы считаете наиболее важными?

— В PHP 5.5 самым важным были генераторы, а насчет 5.6 я пока не уверен. У нас есть множество предложенных функций; одна из них, которая мне очень нравится, нужна для упрощения работы с шифрованием.

Скажем, в 5.5 мы ввели механизм хэширования паролей, который позволяет это делать просто, быстро и правильно. Все инструменты для этого были доступны и раньше, но всё равно время от времени можно было увидеть истории о сайтах, которые хранят пароли в незашифрованном виде, используют md5, алгоритм с плохой «солью» или без «соли» вообще. Это происходит, потому что разработчики иногда просто не знают или не понимают, как нужно делать те или иные вещи. Поэтому теперь у нас есть функция password_hash, которая делает всё что нужно.

Одно из предложений для PHP 5.6 — сделать то же самое для шифрования. При создании SSL-соединения нужно проверять сертификат второй стороны и то, что вы используете актуальную базу сертификатов. Это несложно сделать, но многие разработчики этим не заморачиваются. Потом они переиспользуют тот же самый код на других проектах, и оказывается, что они уязвимы к атакам типа «незаконный посредник» (man-in-the-middle). Так что в PHP 5.6 вся эта работа с шифрованием может быть встроена по умолчанию.

Есть ещё несколько предложений, но я не хочу их называть, потому что пока нельзя точно сказать, что именно войдет в 5.6. Решение ещё не принято.

Анархия или демократия?

— А кто принимает окончательное решение? Вы?

— Нет. Решение принимаем мы все, я отказываюсь становиться узким местом в этом процессе.

— То есть, в PHP демократия?

— Да, мы голосуем за предложенные возможности. Иногда, правда, случается, что большинство голосует «за», но впоследствии оказывается, что внедрение невозможно по техническим причинам. Но 95% одобренных фич попадают в проект.

— Часто ли случается, что большинство одобряет идеи, которые не нравятся лично вам?

— Довольно часто.

— Вас это расстраивает?

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

— Были ли случаи, что программисты переставали работать над PHP из-за того, что результаты голосования их не устраивали?

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

— Есть ли другие языки программирования с аналогичным процессом разработки?

— Я думаю, в большинстве случаев всё же есть один человек, который принимает окончательные решения, и задача остальных — убедить этого человека. Так же происходит, например с Linux: если Линус Торвальдс говорит «нет», то это обжалованию не подлежит. Это тоже нормально, но для меня PHP — не основная работа, к тому же мне не нравится принимать решения такго уровня.

PHP — очень широкий проект с поддержкой самых разных вещей, и совершенно не факт, что я разбираюсь в них всех. Например, я не понимаю Sybase, я никогда им не пользовался, и когда один человек предлагает сделать что-то в этой области, а трое других говорят «нет», мы этого не делаем. Эти ребята разбираются в Sybase, а я не хочу вмешиваться, у меня нет необходимых знаний.

Я уверен, что у Линуса тоже случаются такие ситуации, но он действительно глубоко вникает во все вопросы, разбирается и старается принять правильное решение, что достойно уважения. Но это его основная работа, он получает деньги за то, чтобы заниматься именно этим. А для меня PHP никогда не был основной работой.

— Расскажите о своей основной работе, что вы сейчас делаете?

— Я работаю инженером в Etsy, в Нью-Йорке. Это онлайновая торговая площадка для хэндмейда с фокусом на конечных пользователях; как я уже говорил, я всегда работал именно в таких компаниях.

А занимаюсь я тем, что отслеживаю интересные задачи и решаю их. Последнее, что я сделал, — переписал систему развертывания новых версий сайта. Теперь это делается без перезагрузки сервера, быстро и просто. Мы это проделываем примерно 40 раз в день, так что это действительно важно. То, что я сделал, не относится непосредственно к PHP, но мне нужно было знать, как работают веб-верверы. В итоге я написал модуль для Apache и расширение для PHP; так что в общем и целом я — просто старый программист с бородой, который разбирается в технологиях. Компаниям очень полезно иметь в штате старых программистов с бородой, которые разбираются в технологиях.

— Сколько времени вы обычно тратите на PHP?

— Это практически невозможно посчитать. Например, если кто-то в Etsy нашел баг в PHP и я его исправляю, то в это время я работаю для Etsy. Если же его нашел кто-то другой, то вроде уже и нет, но ведь исправление этого бага может оказаться полезным и для Etsy. То же самое было, когда я семь лет работал в Yahoo; да, я много занимался PHP, но часто я делал это для Yahoo. Эта компания заплатила мне за многие вещи в PHP, которыми сейчас пользуются все.

— Хорошо, тогда зайдем с другой стороны: сколько времени вы вообще работаете?

— Это тоже сложный вопрос. Я провожу много времени в путешествиях — в самолетах, в залах ожидания. Три дня назад я был на конференции в Буэнос-Айресе, сегодня я в Киеве, через две недели я еду в Мехико. Так что в моей жизни много аэропортов и беготни. Я не знаю, сколько точно я работаю; думаю, столько же, сколько и большинство гиков — 12–14 часов в день. Не знаю, правда, какая часть этого времени действительно продуктивна; я всегда онлайн — пожалуй, больше, чем следовало бы.

— Ваши поездки обычно связаны с PHP?

— Да.

— Вам нравится путешествовать и общаться с разработчиками на мероприятиях в разных странах?

— Да. Я терпеть не могу летать, мне не очень нравятся переезды, но места, где я бываю, всегда интересны. Мне нравится узнавать, что нужно реальным пользователям, а не слушать жалобы разработчиков на всякую фигню снова и снова.

Я обожаю слушать пользователей, особенно на User Groups и конференциях. Они говорят о том, как PHP помог им решить какие-то задачи — или, наоборот, не смог помочь по каким-то определенным причинам. Иногда они рассказывают, как PHP изменил их жизнь, или как изменилась жизнь людей где-то в маленьком городке в Южной Америке благодаря написанному на этом языке проекту.


Бонусы: дополнительное видеоинтервью и доклад Расмуса Лердорфа на IDCEE 2013

Опубліковано: 20/11/13 @ 08:54
Розділ php

Рекомендуємо:

Аудит аудиту рознь. Изучаем рынок SEO-консалтинга.
Как мы вывели сайт из-под фильтра за переоптимизацию
Нужно ли отвечать на хорошие отзывы? История о чудо-сумке GeniusPack
Кейс: Лечение сайта правильной внутренней оптимизацией
Wanted SEO-аналитик в Одессе