×Закрыть

Расмус Лердорф, создатель 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

  • Популярное

37 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

А что мешает автору сотоварищи переписать PHP с нуля, внедрить всё то, относительно чего ведётся срач, ввести нормальную модульность, при этом синтаксис оставить похожим на предыдущую версию?
И ко всему этому добру — утилиту (комплекс утилит, так скажем) для быстрой автоматической миграции старого кода в новый? А также набор гайдов и продвинутый дебаггер для отладки этого самого старого кода.

Просто PHP, таким, как я его знал и знаю — достаточно простой и приятный язык, не хотелось бы, чтобы он уходил на задний план только потому, что появилась вышла на передний план туева хуча различных других средств, мода на которые приходит и уходит каждый год; но говнокодить продолжают всё же на старой доброй пыхе.. значит, что-то держит, и если возникла крупная проблема — нужно её решать, пока PHP не стал «персоной нон грата», а пыхеры не повторили участь дельфистов и олдовых кодеров на COBOL (поддержка Legacy приложений для баз данных и банков).

Лично мне ни на трезву, ни на пьяну голову ни на йоту непонятно, чего же такого добавилось в последних версиях PHP (ну, не считая security updates). Я конечно лалка и джуниор, но тем не менее. Нормальные языки так не развиваются.

Но с пыхой я хочу жить и дальше, потому что я на нём, если хотите.. думаю. Для меня всегда проще реализовать какой-то жизнеспособный алгоритм именно на нём — либо сделать на нём, протестировать И УЖЕ ПОТОМ перевести его в другой язык. Вот такая зараза.

Подождите, так а что конкретно менять? Ну вот многих бесит порядок параметров в функциях, мол то на первом месте, то что меняем, то то, что заменяется. Ок, меняем последовательность параметров в каком-то substr — новый код работает, а старый — нет. Можно конечно все взять и переписать, но давайте не забывать сколько кода, фрейморков и целых подтехнологий уже написано на старом коде. Тут у вас только один выход — увеличивать скорость работы уже имеющихся функций, кидать очень старые и дремучие функции в депрекейтед, добавлять новые и в ногу за технологиями добавлять там всякие примочки типа поддержику nosql, примеси и т.д.

Не видете разницы в последних версиях?
А разниц много 5.2 и 5.3 и 5.4 и 5.5 заметно отличаются, не нужно просто ленится открывать чейнжлог. А то пхп уйдет а вы так и будите на пхп 5.2 пыхтеть. 5.4 в среднем на 15% производительнее кстати чем 5.3

А що, операции с юникодовыми строками уже не через mbstring?

И что? Это меняет, то что разниц достаточно между версиями? Или то, что вы про это понятия не имели :) По поводу юникода ИМХО голова болит не у всех далеко. За 10 лет разработки веб проектов в аутсорсинге меня эта проблема затрагивала очень мало, почти никак. Я с нормализацией юникода больше повозился в perl и postresql чем в php, возможно просто потому что когда мне надо было активно работать с текстом и кодировками я брал perl

Меня затрагивала неоднократно из-за работы с мультиязычными данными. CP-1251 давно пора отправить на помойку истории. Для новичка использование mstring неочевидно.

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

Времена поменялись, и от PHP уже хотят нечто большее, чем ?helloworld

Можно чуть детальней на что нарекания то ?

нарекания скорее всего на то что после прикладной разработки PHP не сильно воодушевляет. Но каждый язык хорош по своему и есть такой какой он есть. Легче сказать что язык «дерьмо» чем написать самому.

нарекания скорее всего на то что после прикладной разработки PHP не сильно воодушевляет.
Не уловил мысль. Прикладной это какой ?
Легче сказать что язык «дерьмо» чем написать самому.
Да не вопрос можно поливать язык грязью лишь бы аргументы были.

Пока Вы там на своей джаве кодили, его как раз и допилили.

Возможно. Пруфлинк на толковое руководство/буку имеется? Только не 100500 страниц ахинеи, а страниц 50-150 вменяемого текста.

А что конкретно не нравится в массивах? Каких «нормальных» переменных вам не хватает? Что не так в эксепшнах? Чего большего вы хотите от языка? ОС на пхп?

пхп не знаю, не писал, и кажется только раз устанавливал когда-то.

но никогда не мог понять — ну не нравится пхп, ну так языков то — немеряно! выбирай какой нравится. хошь хаскель полюби.

и, повторюсь, пхп не знаю, не писал на нем, но аргумент для меня главный:

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

Джаву тоже, как только не поносят сколько уж лет.

Ждем, когда ветку наполнят последователи множественного наследования и откроют нам глаза на убогость языка по сравнению с ____ (нужное вписать)

Угу, а Интернет эксплорер когда-то занимал 72% рынка. Делало это его хорошим браузером?

угу, а сейчас кладбища полны гнили и костей. были ли эти кости когда-то хорошими людьми?

Плохой пример. И да, java тоже умрет, не скоро, но умрет.

Так враження, що ви не бачили не те, що PHP 5.Х, а і про 4.Х напевне читали тільки в срачах на форумах і в очі його не бачили.

И видел, и в руках держать приходилось. Но ни разу не видел достойной документации по PHP, рассказывающей как этим инструментом владеть. Ещё раз повторюсь, не 100500 страниц воды, а ≈50-150 страниц позволяющих понять что может сам язык без танцев с бубном.

Из самых серьёзных проблем:
1) Не работает эффективно с низкоуровневыми типами данных типа массива.
2) Нет многопоточности.
3) По-свински непродуктивно жрёт ресурсы, что при реальных нагрузках вылевается в копеечку. В том числе потому, что элементарные вещи требуется реализовывать «через универсальный интерфейс».

Документація по PHP — це обширна довідка. А книжок хоч зачитайся в інтернет-магазинах. Для початкового рівня, для професіоналів, по тематикам — все є. Але звичайно, що однієї книжички на 50-150 сторінко нема — це факт — там би нічого не помістилося. 300-400 сторінок думаю по силам також. Тому перший аргумент- не аргумент.
Про проблеми:
1. Взагалі цього не помічав. + Я як PHP-developer просто радий, що мені не треба возиться з строгою типізацією даних. Це дуже зручно.
2. Так, Згоден.
3. Універсальний інтерфейс -це якраз швидше до джави. + Я працюю в одній компанії з Java-developer-ами і їх софт стає все прожорливішим і прожорливішим, а от php спокійно собі працює на рані виданих серверах. Є багатоспособів прискорить веб-систему про потребі. Тому в порівнянні з Java PHP точно має дуже скромні апетити.

Какой-то странный пост. Что значит достойная документация? Чего в документации по php вам не хватает? По какой конкретно функции нету описания? Где там не рассказано «как этим инструментом владеть»?

Теперь по вашим вопросам
"

1) Не работает эффективно с низкоуровневыми типами данных типа массива.
"
Перечислите с какими низкоуровневыми типами данных работает неэффективно? Какой у вас критерий эффективности? Что конкретно не так было выявлено в работе с массивами?
2) Нет многопоточности.
Ладно, не буду писать, что php как по мне всего лишь должен сгенерировать вам за вменяемое время страничку и не более того. А зачастую большая часть тех кому вдруг понадобилась многопоточность, или как-то криво написали архитектуру, что им вот без нее никак, или же гуглят и находят велосипеды/костыли/официальные допиливания:
habrahabr.ru/post/75454
www.phphighload.com/...012/07/php.html
habrahabr.ru/post/134501
habrahabr.ru/post/40245
etc.
То есть, проблема решаема. А просто так давать вам запускать в скриптовом языке кучу процессов, при том, что в основном на нем обычно летают миллионы сайтов-визиток на дешевых хостингах. Скорее всего там это будет запрещено и т.д. А так если у вас свой сервак, то наверняка куча побичного софта или возможность доставить недостающие костыли.
3) По-свински непродуктивно жрёт ресурсы, что при реальных нагрузках вылевается в копеечку. В том числе потому, что элементарные вещи требуется реализовывать «через универсальный интерфейс».
Хм... не тут надо смотреть настройки сервера, чего он у вас такой прожорливый. mod_php? fastcgi? fcgi? lighttpd? Какой вообще был сервер? Что делал скрипт? Просто долго работал? Какой-то мудренный фреймоврк создавал на каждый чих пачку объектов? Скрипт долго ждал результат выполнения запроса? и т.д.

Что такое «элементарные вещи»? Взяли какую-то идею из java и давай ее же лепить средствами php?

php как по мне всего лишь должен сгенерировать вам за вменяемое время страничку и не более того
И в этом он пережил своё время. Нужно «более того». При его популярности он давно должен уметь делать ВСЁ. Что тут сложно понять — был язык, он выстрелил, народ хавает, а значит надо завоёвывать мир. Нет, млин, наше дело «страничка».

Учитывая КОЛИЧЕСТВО установленных PHPей и ЦЕНУ тех ресурсов на которые он установлен — да, я считаю что это уже должна быть операционная система.

И это вопрос не холивара, а развития. Сейчас есть серьёзный конфликт между РЕАЛЬНЫМ железом/тучами и PHP. И вопрос был лишь в том, есть ли серьёзный прорыв в эффективности. В отказе от зацикливания на ненужной виртуализации и липовой простоте в пользу ВОЗМОЖНОСТИ общаться 1 на 1 с белогривыми лошадками.

Вопрос был да/нет, и учитывая количество мнений «нас устраивает как есть» — я поддерживаю мнение что PHP останется на своих принципиальных позициях. Откуда (в теории) может быть выброшен чем-то поудобнее.

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

То есть, на уточняющие три вопроса конкретно по теме, вы смогли ответить только то, что ПХП должен уметь ВСЁ (пафосно буду продолжать писать большими буквами как в оригинале). Можно конечно спросить Вас, а что конкретно вы подразумеваете под «ВСЁ», когда речь идет о скриптовом языке, который висит на удаленном сервер и отвечает на запросы клиент-сервер приложений?

В отказе от зацикливания на ненужной виртуализации и липовой простоте в пользу ВОЗМОЖНОСТИ общаться 1 на 1 с белогривыми лошадками.

Сезон грибов уже вроде закончился? Вы видите программируя белогривых лошадок? Вы хотите об этом поговорить?

Если вам для интернет-проектов надо, чтобы он реально мог ВСЁ, а иначе никак, то вы плохо спроектировали систему.

Короче вот примерно таким беспредметным чёсом заканчиваются все наезды на пхп. Человек или мало программировал, или не на нём, или не понимает как функционирует веб/сети/веб-сервер, или не понимает зачем нужны одни языки и другие.

П.С. Ну просто чтоб поржать, а что ж вы выбрали для вашего очередного проекта для веба, что может ВСЁ?

Ви глибоко в своєму світі загубилися. На PHP писалися і пишуть класні проекти. Я працюю в компанії, де є різні мови програмування і по моїх спостереженнях — якщо руки з ж**и, то руки з ж**и, не важливо на якій ти мові пишеш.

Якщо вибирати на якій мові написати новий проект для прода, я б запитав — а яку мову ви краще всього знаєте?

. Ещё раз повторюсь, не 100500 страниц воды, а ≈50-150 страниц позволяющих понять что может сам язык без танцев с бубном.
Где вы такое видели по java с описанием хотя бы с половины стека применяемых технологий?

А если не видели, то почему требуете этого от других?

PHP ... большинстве случаев он делает то, что разработчик от него ожидает
O’RLY?

Вообще-то, да. Там хоть и так называемый малый порог входа, но вот чтоб ходить в нем «высоко» надо уметь на нем кодить. А так очередной мейнстримный коммент без конкретики.

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

Ну видимо дело таки как раз было в динамической типизации, а вообще надо смотреть пример и тогда можно что-то говорить.

Знаете, я вот поначалу тоже бурчал на некоторые «странности», а потом как-то готовился к сертификации по пхп и заставил себя прочитать подготовительные материалы. Открыл для себя много нового о чем даже раньше как-то не задумывался и списал бы всё на «странности», но в итоге или не до конца дочитал хелп или не до конца понимал как оно это что-то делает.

А что за сертификат? Зендовый?

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

Да, зендовый сертификат, но так и не пошел сдавать — завалило всякой работой, так что снова надо будет читать

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

Ой правильный у него подход. Такой себе руководитель социального языка программирования.

Мне мастер класс Расмуса на арсенальной понравился.

Интересно было почитать, спасибо.

Представляю диалог на собеседовании в Etsy:
— How many years of PHP expertise do you have?
— All of them.

З Гвідо уже бували подібні історії:

Do not send me email like this:

"""
Hi Guido,

I came across your resume in a Google web search. You seem to have an awesome expertise on Python. I would be glad if you can reply my email and let me know your interest and availability.

plus.google.com/...sts/R8jEVrobbRj

І з DHH

Hi David,
I came across your profile online and wanted to reach out about Development
Opportunities here at Groupon. The company is growing, and we’re always
looking for folks with solid skills that can make positive contribution to
our continued success. Any chance you’d be open to a quick conversation
about opportunities, or for any possible networking potential? If so, let me
know when you’re free and we can set up a time to chat. Also, if you are
interested, it would be great if you could forward a current resume over
that I can take a look at. I look forward to hearing back from you! Please
let me know if you have any questions.
Cheers,
Yet Another Clueless Tech Recruiter

gist.github.com/dhh/1285068

Подписаться на комментарии