Возможное будущее PHP

Перевод статьи A possible future to PHP

Возможное будущее PHP

Опубликовано Франком Карличеком 2 октября 2014

Согласно последней статистике, ownClowd – один из крупнейших опенсорсных проектов, написанных на PHP. Как многие из вас знают, PHP использован для серверной части ownCloud. Мы использовали другие технологии, такие как C++ и Qt для десктопных клиентов, Java для андроид-приложений и Objective-C для iOS-приложений, JS для веб-интерфейсов и т.д. Но сердце ownCloud – серверная компонента, использующая PHP 5.3 и выше.

Было несколько причин для выбора PHP:
• Миссия ownCloud – сделать возможным для каждого хостить его личный облачный сервер. PHP – технология, доступная на большинстве вебсерверов, операционных систем и платформ. То есть, мы сделали хостинг сервера ownCloud суперлёгким, потому что он написан на PHP.
• PHP – скриптовый язык, что означает, что один один серверный tar-файл будет работать на всех платформах без необходимости сложной кросс-компиляции и требования пакетов.
• PHP хорошо изучен. Множество людей хорошо знакомы с PHP. И даже разработчики, не знающие PHP, могут его легко выучить. Это очень важно для опенсорсных проектов, в которых порог вхождения должен быть как можно ниже.
• PHP быстр и производителен при правильном использовании. Множество больших веб-приложений вроде Википедии, Фейсбука, Вордпресса и частей Яху написаны на PHP. То есть, с этим языком вы можете сделать многое. К несчастью, на PHP так же легко писать плохие приложения. Об этом ниже.
• Для PHP существует огромная экосистема библиотек, компонент и драйверов. Для опенсорсного проекта вроде ownCloud это очень клёво потомму что это означает, что вам не нужно изобретать это с нуля. Мы стоим на плечах гигантов.

PHP – не самый хипстерский язык в мире. Даже наоборот, у него сравнительно плохая репутация. Я лично никогда не был большим фанатом выбора технологии на основе её клёвости или модности. Я думаю, разные технологии предназначены для разных задач, и делать выбор нужно объективно, без лишних эмоций. Так что я не понимаю религиозных дискуссий почему инструмент X всегда лучше, чем технология Y. Я думаю, все эти споры о правильной технологии возможны после определения курса (типа приложений - прим пер.).

Итак, я по сей день счастлив, выбрав PHP. До сих пор мы не встретили больших архитектурных технических проблем, которые нельзя было бы решить с помощью PHP.

Означает ли это, что PHP – совершенный язык и я супердоволен всем? Разумеется, нет. PHP был разработан в середине 90х, во времена, когда никто даже не представлял, как веб будет устроен сегодня. Некоторые из клёвых фич со временем сегодня превратились в кошмар. Много чего можно улучшить, и я думаю, даже разработчики ядра PHP согласятся со мной в этом.

Некоторые из очевидных недостатков:
• Безопасность. PHP сам по себе не является небезопасным, и, очевидно, возможно написать совершенные и безопасные приложения на PHP. Однако, PHP подходит к вопросам безопасности слишком легко, и не сподвигает разработчиков писать безопасный код. По правде говоря, в 90х все относились к безопасности беспечно. Так что в PHP немного возможностей, которые активно помогают вам писать безопасный код. С базами данных - путаница, из-за чего много людей до сих пор не используют prepared statements, что делает возможным sql-инъекции. Фильтрацию входных данных для защиты от XSS нужно делать вручную. Есть расширения и библиотеки для помощи во всех этих проблемах, но они не включены в язык.
• Время компиляции/конфигурация времени выполнения. Для прикола вызовите ./configure для компиляции php и посмотрите на опции компиляции. А затем посмотрите на все опции, которые могут быть установлены в php админом сервера. С одной стороны это клёво потому что админ может очень тонко настроить в PHP возможности ядра. Но для разработчика PHP-приложения, которое должно работать на всех PHP-серверах это кошмар. Вы никогда не знаете, какая опция включена или выключена. У нас в ownCloud есть много кода, который использует окружение и рантайм и проверяет, всё ли работает так, как ожидается, и если нет – адаптируется под него как необходимым образом. Это, увы, нельзя назвать стабильной платформой и хорошей абстрацией ОС.
• Некоторая неконсистентность в названиях функций и классов. Иногда нижние подчёркивания, иногда верблюжья нотация. Некоторые фичи реализованы через процедурный стиль, некоторые через ОО-API, а некоторые обоими способами. Нужно много чего подчистить.
• Статическая типизация. В целом это вопрос вкуса, но иногда я действительно хотел бы побольше статической типизации. Определите, что делает следующий код, если у вас в директории есть файл с названием “0”:
while ( ($filename = readdir($dh)) == true) $files[] = $filename;

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

Последняя статья на ArsTechnica and Apples представила Swift как преёмника Objective-C, включившим мою фантазию, как PHP следующего поколения может и должен быть сделан. “Сохранить обратную совместимость программ или исправить их недостатки? – Apple Swift“.

Существует старый и простой подход. Разработчики ЯП выпускают новую версию с исправленными недостатками, несовместимую со старыми версиями. Примеры – Perl и Python. Проблема в том, что практически невозможно переписать большой программный проект, чтобы сделать его совместимым с новой версией. В конечном счёте вы оказываетесь вынуждены работать с двумя версиями ЯП/фреймворка длительное время. Иногда библиотеки и зависимости доступны только для одной из этих версий. Миграция суперсложна и не может быть сделана по частям. Взгляните на Perl 6 и Python 2/3 как пример возможного кошмара. Оба существуют долгое время и множество ПО застыло где-то посередине процесса миграции.

Намного более позитивным примером является C++. Этот язык по-прежнему сильно отличается от C, но хороший момент в том, что он может быть смешан внутри приложения. То есть, в 90х C-разработчики могли использовать клёвые новые фишки C++ в некоторой части приложения без необходимости переписывать всё с нуля.

Apples развивают Swift как наследника Objective-C по-моему мнению очень разумно. Это полностью новый язык, но он выполняется в том же рантайме. Это означает, что разработчик может взять существующий Objective-C проект и начать писать новые фичи на Swift или заменять куски один за одним кодом на Swift. Затем это компилируется в один бинарник, не имеющий новых зависимостей по сравнению с Objective-C.

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

Таким образом, хорошим решением будет если PHP 6 или 7 добавят новый тег в начало php-файлов. Например, <?PHPNEXT вместо <?PHP. Чтобы оба способа полностью поддерживались новой версией PHP и могли быть использованы параллельно в одном приложении или даже одном файле. В секции NEXT дложен быть использован новый и улучшенный синтаксис.

Несколько идей для улучшений, который я бы с удовольствием увидел:
• Безопасность. Уберать массивы _GET, _POST и _SERVER и добавить нормальный API для нормальной фильтрации входных данных.
• Базы данных. PHP поддерживает тонны различных API баз данных. Некоторые из них очень старые, и не могут быть использованы. Всё должно быть стандартизовано, и остаться только OO-интерфейс. Мне кажется удачным будет начать с PDO.
• 32/64бит. Всякий, кто пробовал писать приложения, которые работают на 32 или 64-битной ОС, понимал, что переменные, особенно целые, ведут себя по-разному. Я понимаю, что это отголосок C/C++, но это, вообще-то, плохая идея. Я не хочу иметь разные части кода, которые нужно независимо тестировать.
• Убрать safe_mode, open_basedir и прочие устаревшие подходы.
• Убрать большую часть опций компиляции и рантайма. Всё PHPNEXT окружение должно работать одинаково насколько возможно.
• Типизация. Будет круто, если PHP добавит опциональную статическую типизацию. Например, объявим переменную как bool или int. В противном случае должно быть брошено исключение.
• Всегда использовать юникод.

Некоторые из этих улучшений реализованы в Hack – форке PHP, выполненном facebook. Hack в самом деле интересный концепт который движется в аналогичном направлении. В нём так же есть тег <hh так что код може тбыть смешан в одном файле. На данный момент неясно, сколько сил вложит фейсбук в будущем в эту разработку и насколько эта разработка будет адаптирована за пределами фейсбук. Я особенно обеспокоен насколько они открыты для изменений, которые для них не важны. Я предпочту официальный и более общий шаг от PHP-сообщества, который будет одного из следующих основных PHP-релизов.

Я надеюсь, моя мечта о более новом и чистом PHP, включая плавную миграцию, станет реальностью, в следующие несколько лет.

Очевидно, мы в ownCloud не сможем начать миграцию на этот новый PHP пока 95% установок PHP не перейдут на новую версию. Это займёт ещё 3-5 лет.

С этими изменениями большие проекты вроде WordPress или ownCloud получат реальный шанс перейти на более новый и чистый язык. Но, что важнее, это сделает PHP готовым к вызовам будущего.

с чем PHP не справился?

Помимо известного "PHP-это фрактал плохого дизайна" и "PHP sucks because"
могу добавить что в PHP
- чем выше уровень абстракции, тем сложнее работать
- сложно работать в декларативном стиле, делать декларативные описания

То есть, полнота по Тюрингу не означает удобства работы.


Можно заметить, как автор статьи жрёт говно, приговаривая "Говно, конечно, полно недостатков, да прямо скажу, оно воняет отвратительно, но оно так широко распространено, что мы решили это использовать. За годы практики мы научились лепить из говна инструменты и даже делать себе жилища. Кроме этого у меня появилась блестящая идея, как можно улучшить говно: нужно в него постепенно добавлять сахар. Я всегда мечтал о говне с сахаром."

Граждане пыхчане, а кто мне скажет, в чём Карличек обосрался?

@kostyl, автор статьи же