[Перевод] Возможное будущее для PHP
Изображение взято с 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 введет новый открывающий тег, например
Вот несколько идей для улучшения, которые я хотел бы увидеть:
Безопасность. Не будет больше _GET, _POST, _SERVER массивов, вместо них появится правильный API, который можно будет использовать для фильтрации всех входящих данных.
Базы данных. PHP поддерживает множество различных API базы данных. Некоторые из них очень старые, но они несовместимы в использовании. Все должны быть стандартизированы, чтобы только один OO API существовал. Я лично хотел бы увидеть PDO в качестве базиса.
32/64bit. Любой, кто когда-либо пробовал написать PHP приложение, которое запускается на 32-битных или 64-битных ОС признают, что переменные, особенно целые, ведут себя по-разному. Я понимаю, что это отголоски C/C++, но это действительно плохая идея. Я не хочу иметь различные части кода, которые необходимо проверять независимо.
Уйдут save_mode, open_basedir и другие древние концепции
Удалится большинство опций конфигурации компиляции и выполнения. Все среды PHPNEXT должны быть максимально приближены и стабильны, настолько, насколько это возможно.
Типизация. Было бы здорово, если бы в PHP появилась дополнительная статическая типизация, такая, чтобы переменную можно было объявить как bool или int. А если в ней используется что-то иное, было брошено исключение.
Чтобы всегда использовались строки в юникоде
Некоторые из этих улучшений были реализованы в Hack, который является своего рода отдельной веткой PHP разработанной в Facebook. У Hack действительно интересная концепция, которая развивается в том же направлении. Они также используют новый тег » Я надеюсь, что мечта о более современном и чистом PHP, включая плавный путь миграции, станет реальностью в ближайшие несколько лет. Очевидно, что мы в OwnCloud не сможем начать мигрировать в этот новый режим PHP, до тех пор, пока до 95% всех PHP установок не начнут работать с новой версией. Это будет легко, но потребует дополнительных 3–5 лет. Делая большие проекты, такие как WordPress или OwnCloud, фактически появится возможность переехать в более чистый и современный язык. Но что еще более важно PHP будет готов бросить вызов будущему.
