Изображение взято с wikimediafoundation.org
От переводчика: данный пост является вольным переводом статьи A possible future for PHP, написанной Frank Karlitschek, основателем компании ownCloud и разработчиком одноименного открытого продукта для создания облачных хранилищ .
Если посмотреть на последние статистические данные OwnCloud является одним из крупнейших проектов с открытым исходным кодом, написанным на PHP. Большинство из вас знает, что PHP используется для реализации серверной части OwnCloud. Мы используем и другие технологии, такие как C++ и Qt для настольных клиентов, Java для Android приложения и Objective-C для iOS, JavaScript для веб-интерфейса и многое другое. Но сердцем OwnCloud является серверный компонент, который базируется на PHP 5.3 или выше…
Было несколько причин для выбора PHP:
- Основной задачей OwnCloud — предоставить всем желающим свой собственный облачный сервер. PHP является технологией, которая доступна в большинстве веб-серверов, операционных систем и платформ. Так же мы делаем серверов OwnCloud намного проще, потому что они написаны на PHP.
- PHP — скриптовый язык, это значит, что один tar архив будет работать на всех платформах, и нет никаких сложных компиляций и сборок.
- PHP очень хорошо известен. Много людей знакомы с PHP. И даже разработчики, которые не знают PHP, могут достаточно легко его изучить. Это очень важно для проекта с открытым исходным кодом, ведь уровень требований для участников должен быть как можно ниже.
- PHP достаточно мощный и быстрый, если используется в правильном ключе. Много крупных веб-проектов, таких как Wikipedia, Facebook, WordPress и частично Yahoo написаны на PHP. Таким образом, вы можете сделать очень многое на нем. К сожалению так же относительно легко можно написать и плохой код. Но об этом чуть позже.
- Существует огромная экосистема из библиотек, компонентов/драйверов доступных для PHP. Для проекта с открытым исходным кодом, как OwnCloud это очень здорово, потому что это означает, что вам не придется писать все с нуля. Мы стоим на плечах гигантов.
PHP не самый “хитовый” язык программирования в мире. На самом деле все наоборот. Он имеет относительно плохую репутацию. Я лично никогда не был большим поклонником в выборе технологий, основанных на том, что это «круто» или это «современно» или это «в моде». Я думаю, что есть разные технологии для различных областей, и они должны оцениваться объективно и выбирать их нужно без участия эмоций. Так что я не понимаю религиозные дискуссии, почему инструмент Х всегда лучше, чем технология Y. Я думаю, что все это верные технологии для работы, конечно после справедливой оценки о разумности их использования.
Так что я все еще очень доволен этим решением использовать PHP. До сих пор мы не встречали больших архитектурных или технических проблем, которые мы не смогли бы разрешить с PHP.
Но значит ли это, что PHP является совершенным и я очень всем доволен? Конечно, нет. PHP был разработан в середине 90-х годов, в том время, когда никто не мог себе представить веб так, как он выглядит сегодня. Некоторые из интересных функций того времени превратились в кошмар сегодня. Существует много того что требует улучшения, и я думаю, что даже разработчики ядра PHP согласятся со мной здесь.
Некоторые очевидные недостатки:
- Безопасность. PHP сам по себе не является безопасным, но представляет возможность написать прекрасный и безопасный код. PHP решил реализовать довольно наивный подход к безопасности и не слишком поддерживает разработчика в написании безопасного кода. Справедливости ради, все были наивны в вопросах веб-безопасности в 90-ые годы. Таким образом, не так много в PHP возможностей, помогающим разработчику написать безопасный код. К примеру, путаница с базами данных, до сих пор много людей не используют связываемые переменные, что возможно допускает появление SQL инъекции. И фильтрация входящих данных для XSS и другие возможные проблемы должны быть разрешены разработчиком вручную. Существуют расширения и библиотеки, которые помогут разрешить все эти проблемы, но они не являются частью языка/ядра или не решают проблему полностью.
- компиляция/конфигурация. Просто ради веселья запустите скрипт ./configure для компиляции PHP и посмотрите на все опции компиляции. А теперь посмотрите на опции, которые можно установить в php.ini администратором сервера. С одной стороны это хорошо, потому, что администратор может включать и отключать львиную долю функций в PHP достаточно тривиальным способом. Но для разработчика PHP приложения, которое должно работать на всех доступных серверах с поддержкой PHP это кошмар. Вы никогда не знаете, какие функции доступны и активны. В OwnCloud у нас есть много кода, который зависит от окружающей среды и среды выполнения, и проверяет, что бы все работало как надо, или приспосабливается к ней по мере необходимости. Это, к сожалению не то, что вы называете стабильной платформой и хорошей ОС абстракцией.
- Есть некоторые несоответствия в функциях и наименованиях классов. Иногда используется подчеркивание, иногда CamelCase. Некоторые возможности доступны в процедурном стиле, а некоторые имеют ОО API, а некоторые даже оба. Существует много того, что должно быть очищено.
- Статическая типизация. Конечно это вопрос вкуса, но иногда мне очень хочется иметь больше статической типизации я действительно хотел бы иметь немного больше статической типизации в PHP. Угадайте, что делает следующий код, если у вас есть файл с именем «0» в каталоге
while ( ($filename = readdir($dh)) == true) $files[] = $filename;
Я действительно хочу видеть в будущем PHP переходящим на следующий уровень и улучшающим некоторые из этих недостатков, потому что большинство из них действительно этого заслуживают.
Но очень важно сделать это правильно.
Последняя статья в ArsTechnica и Apple продвигает к внедрению Swift как преемнику Objective-C, и тут я представляю, как следующее поколение PHP может и должно быть сделано.
Поддерживать обратную совместимость или исправлять свои недостатки? — Apple Swift
Сейчас существует старый, и честно говоря, очень наивный подход. Основная команда разработчиков языка программирования просто выпускает новую несовместимую версию, которая исправляет недостатки старой версии. Примерами являются Perl и Python. Проблема в том, что практически невозможно переписать большую часть программных проектов написанных на этих языках, для того, что бы сделать их совместимыми с новой версией. Таким образом, вы в конечном итоге работаете с двумя версиями языка программирования/фреймворка/приложения в течение очень долго времени. А некоторые приложения работают на старой версии и будут работать на старой версии. Различные библиотечные зависимости иногда доступны только для одной из версий.
Миграция является очень тяжелой и не может быть совершена по частям. Пожалуйста, посмотрите Perl6 и Python 2/3 как пример, каким ночным кошмаром это может стать. Оба существуют в течение очень долгого времени и много проектов «застряло» где то в середине миграционного пути.
Более позитивным примером является C++. Он все же очень отличается от C, но хорошо, что его можно использовать вперемешку внутри приложения. Таким образом С разработчики 90-ых могут использовать новые интересные C++ функции в одной части приложения, без необходимости переписывать все приложение с нуля.
Apple двигаются в продвижении Swift в качестве преемника Objective-C, на мой взгляд, это очень умно. Ведь это совершенно новый язык, но он работает в той же среде выполнения. Это означает, что разработчик может взять существующий Objective-C код приложения и просто начать писать новые функции Swift или заменить некоторые части старого кода другими, с новым Swift кодом. В конечном итоге это компилируется в двоичный код, который не имеет никаких новых зависимостей выполнения по сравнению с Objective-C.
Я надеюсь, PHP будет делать то, что делает возможным значительно развивать и совершенствовать язык, но, все же обеспечивая плавный опыт миграции, не так как с Perl и Python, когда выпустили совершенно новые несовместимые релизы.
Так же хорошим решением будет, если PHP 6 или 7 введет новый открывающий тег, например <?PHPNEXT вместо <?PHP. Оба режима полностью будут поддерживаться новой версией PHP и могут использоваться параллельно в одном и том же приложении или даже в одном и том же файле. А в PHPNEXT разделе будет использоваться новый и улучшенный синтаксис.
Вот несколько идей для улучшения, которые я хотел бы увидеть:
- Безопасность. Не будет больше _GET, _POST, _SERVER массивов, вместо них появится правильный API, который можно будет использовать для фильтрации всех входящих данных. (Прим.переводчика: В данный момент существует filter_input, который поддерживается PHP 5 >= 5.2.0)
- Базы данных. PHP поддерживает множество различных API базы данных. Некоторые из них очень старые, но они несовместимы в использовании. Все должны быть стандартизированы, чтобы существовал только один OO API. Я лично хотел бы увидеть PDO в качестве базиса.
- 32/64bit. Любой, кто когда-либо пробовал написать PHP приложение, которое запускается на 32-битных или 64-битных ОС признают, что переменные, особенно целые, ведут себя по-разному. Я понимаю, что это отголоски C/C++, но это действительно плохая идея. Я не хочу иметь различные части кода, которые необходимо проверять независимо.
- Уйдут safe_mode, open_basedir и другие древние концепции (Прим.переводчика: Опция safe_mode была помечена depricated в 5.3.0 и удалена в 5.4.0)
- Удалится большинство опций конфигурации компиляции и выполнения. Все среды PHPNEXT должны быть максимально приближены и стабильны, настолько, насколько это возможно.
- Типизация. Было бы здорово, если бы в PHP появилась дополнительная статическая типизация, такая, чтобы переменную можно было объявить как bool или int. А если в ней используется что-то иное, было брошено исключение.
- Чтобы всегда использовались строки в юникоде
Некоторые из этих улучшений были реализованы в Hack, который является своего рода отдельной веткой PHP разработанной в Facebook. У Hack действительно интересная концепция, которая развивается в том же направлении. Они также используют новый тег "<hh", так что код можно вперемешку использовать в одном файле, а еще они улучшили типизацию. На данный момент не ясно, сколько сил Facebook намерен тратить на проект в будущем, чтобы развивать Hack дальше и как его примут за пределами Facebook. Так же я беспокоюсь, насколько они будут открыты для изменений, которые не важны для них, кто и как будет их регулировать. Я бы предпочел, официальный и более общий подход от PHP сообщества, которое будет частью одной из следующих основных релизов PHP.
Я надеюсь, что мечта о более современном и чистом PHP, включая плавный путь миграции, станет реальностью в ближайшие несколько лет.
Очевидно, что мы в OwnCloud не сможем начать мигрировать в этот новый режим PHP, до тех пор, пока до 95% всех PHP установок не начнут работать с новой версией. Это будет легко, но потребует дополнительных 3-5 лет.
Делая большие проекты, такие как WordPress или OwnCloud, фактически появится возможность переехать в более чистый и современный язык. Но что еще более важно PHP будет готов бросить вызов будущему.
UPD: добавил примечание, о удалении safe_mode в 5.4.0. Спасибо Sway за наводку :), так же добавил примечание о filter_input, thx AmdY за комментарий.
UPD2: исправил несколько ошибок в тексте, спасибо hDrummer за предоставленные замечания.
Автор: TODOOM
