Согласно последней статистике, 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 дложен быть использован новый и улучшенный синтаксис.

Несколько идей для улучшений, который я бы с удовольствием увидел:

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

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

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

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

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

====

Комментарий переводчика:

Я перевёл эту статью, в основном, чтобы показать эволюцию типичного PHP-кодера.

Переиначивая известное выражение: программисты делятся на умных и упорных. Карличек, судя по этой заметке, является вторым и вряд ли первым. Человек, считающий некий инструмент с _врождёнными_архитектурными_недостатками_ неплохим только потому что он _распространён_, скорее всего только этот инструмент и знает. Если за годы практики он захотел не взять другой инструмент, а добавить сахара в прежний - значит он других инструментов не пробовал.

Очевидно, что софт, деплоящийся на VPS, может быть написан на любом языке, потому что его можно поставлять в tgz/git/deb/rpm/etc. При этом софт может установить свою копию интерпретатора со своими настройками (к вопросу о версиях PHP и php.ini). Фактически не было никакой необходимости ориентироваться на установленный в системе интерпретатор. Однако, Карличек пошёл по трудному пути, причём не просто трудному, а по пути ошибочного архитектурного проектирования. Чем это можно объяснить? Вероятно, только тем, что Карличек - упорный программист.

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

Перевод статьи "A possible future to PHP" Франка Карличека