В последние дни было достаточно много было сказано разного про PHP. Всё началось с поста Фрактал плохого дизайна и продолжилось некоторыми неловкими попытками защитить любимый язык. Как ни крути, а в статье о «фрактале» — всё факты. Спорить с фактами бессмысленно. Давайте взглянем правде в глаза и объективно постараемся оценить сильные и слабые стороны РНР.
Если честно, то в вопросе PHP самому языку уделяется слишком много внимания. Да, статья «фрактал плохого дизайна» показала многие подводные камни при использования PHP. Но знаете, всем пофиг. Просто за годы использования, мы, разработчики, ни разу не искали подводные камни, и потому уже интуитивно избегаем нечетких конструкций. Да, конечно, примеры в статье абсолютно фееричны, но представляют скорее академическую критику языка. А PHP никогда не был академическим языком и всегда представлял сугубо практическую ценность. На ней и хотелось бы сосредоточиться.
Ничего личного. Только бизнес.
Первым и самым главным аргументом в защиту РНР стоит — «за него платят!». И это сильный аргумент. Правильно, платят, несмотря на всю критику. Ещё есть аргумент «PHP — отлично подходит для своих задач». А, вот какие это задачи?
Давайте разберемся.
Есть сфера, где у РНР нет конкурентов. Это рынок продуктов. Интернет-магазины, форумы, системы управления контентом — всё делается на PHP. Никакие Ruby и Python не могут ничего противопоставить продуктам на PHP. Установка любого приложения сводится к копированию файлов и запуска инсталятора. Никаких перезагрузок сервера, минимальная конфигурация, пару кликов и всё готово!
Системы управления контентом (Drupal, WordPress), системы электронной коммерации (Magento, OSCommerce) делаются и будут делаться на PHP. Никакой целесообразности продуктовым компаниям менять язык, потому что там якобы не такой дизайн. Они потеряют огромные деньги в попытке перейти на другую платформу. Вместе с тем они и потеряют огромный рынок разработчиков, готовых «допилить» любой софт под нужды заказчика. На Ruby и Python просто нет такой армии людей, готовых копаться в чужом коде и что-то допиливать или выпиливать, чтобы сделать сайт-визитку. Там люди серьезные и работать будут за серьезные деньги.
Легкость установки и наличие широкого комьюнити делают PHP инструментом №1 для разработки веб-сайтов. Точка.
Хорошо, а вот подходит ли PHP для разработки кастомных решений? Конечно, подходит. Есть много фреймворков — Zend, Yii, Symfony… Но вот тут ярких конкуретных преимуществ уже нет. Самое явное — наличие разработчиков. Сами фреймворки будут явно слабее того, что есть в других языках. Я не буду давать однозначных оценок, но учитывая, огромные заимствования из Rails, Django, Spring, попробуйте посмотреть в сторону других языков и фреймворков, прежде чем хвалить свой любимый фреймворк на PHP. Согласитесь, эффективнее будет подбирать инструменты исходя из задачи, а не из того, что «всё это можно сделать на PHP и на моем любимом фрейме». Говорю это вам, как человек, написавший многопоточный SMPP-сервер на PHP.
Сообщество.
В PHP огромное сообщество. Найти парня, который кодит на PHP очень легко. Но как мы, наверняка, понимаем, как раз в этом, а вовсе не в языке, основная проблема PHP. Каждый кодит как хочет и как умеет. Знаете, бесит, даже не то, что так пораждаются тонны гавнокода. Беда в том, что несмотря на огромное сообщество, все вместо того, чтобы использовать наработки друг друга пишут велосипеды. Программист, разрабатывающий сайт на коленке, на Друпале, на Symfony решает одни и те же задачи. Но каждый решает их по-своему. Кто-то клепает код, кто-то скачивает и настраивает модуль, кто-то расширяет бандл. Сколько платформ — столько и решений.
Немногие знают, что на Ruby фреймворков больше чем один. И несмотря на это большинство решений под Rails отлично работают под другими фреймворками. Некоторые вообще не привязаны к фреймворкам. Вот и возникает вопрос: что мешает PHP сообществу писать крос-фреймворковые компоненты? Когда уже наконец, мы перестанем писать такие фичи, как пейджеры, тэги, комментарии, activity streams (как бы их по-русски обозвать?), системы личных сообщений и т.п., а начнем скачивать под них готовые компоненты?
Беда: даже крупные разработчики фреймворков переписывают велосипеды. Посмотрите сколько было созданно Dependency Injection — компонентов. Почему все компоненты Symfony2 и Zend столь похожи? Ну кто начнет писать, что-то новое, а не переписывать то, что увидел у соседов?
Впрочем, я вижу и перспективу под этим. Благодаря тому же Dependency Injection теперь становится легко подключать различные сервисы. Не вижу причин, почему крос-фреймворковые компоненты нельзя реализовывать под видом тех самых сервисов. Согласитесь, было бы круто, если бы один и тот же компонент можно было использовать в Symfony, Zend и в других фреймворках. И это возможно. Но PHP сообщество не умеет договариваться и продвигать столь глобальные идеи. Предел возможностей — PSR-0 стандарт об именовании классов. Ну хоть автолоадер теперь один, и на том спасибо. Сейчас обсуждают стандарт кеша. Может через пару лет они и насчет сервисов тоже договорятся.
Проблема PHP в сообществе. То есть в нас. Мы очень замкнуты и сосредоточены на своих задачах. Вместо того, чтобы следить за миром PHP, и улучшать его, мы решаем свои задачи и пишем велосипеды. Сколько блогов о PHP и их компонентах вы читаете? Сколько блогов ведете? Сколько опенсорсных продуктов сделали? Давайте защищать честь PHP не словом, а делом. Пишите о нем, пиарьте интересные статьи, компоненты, фреймворки, не ленитесь делать ретвиты на хорошие материалы. Откройте шторы, за окном огромный мир.
Язык
Ну вот пришло время поговорить о самом языке. Беда в том, что вектор развития этого языка непонятен. С каждой эпохой он набирает фич других языков, не теряя обратной совместимости. Итого, у нас в одном флаконе и C и Java и Ruby и уже traits из Scala. Нету никакого понимания того, что такое PHP way, а что таким не является. Каждый новый мажорный релиз PHP концептуально меняет его идеологию. Вспомним скачок к ООП в PHP5, namespaces в PHP 5.3, traits в PHP 5.4. Что будет завтра? Кто его знает. Зависит от направления ветра и от парада планет.
При этом, сейчас модно копировать в PHP решения Java и говорить, что так PHP становится уровнем enterprise. Сейчас пытаются в язык мыслимыми и немыслимыми костылями ввести аннотации. Если в Java или Python аннотации — это часть языка, то в PHP это реализовуется парсингом комментариев через рефлексию. В фреймворке Lime2 тоже были аннотации. Знаете, как они реализованы? Регекспом парсился весь файл и оттуда вытягивались строки "// @Before" и "// @After". То как аннотации сделаны в Doctrine2 и Symfony2 не многим лучше. Как ни крути, но это костыли. Впрочем, раньше эти же люди для PHP и mixins пытались релизовывать.
Поймите, PHP не Java. Чем больше людей будут делать из PHP Java тем меньше будет разработчиков, которые смогут писать на PHP требуемом уровне. KISS, baby.
Лично я, считаю, что в самом PHP есть две мега-класные фичи. И почему-то они крайне недооценены.
1. Связанные методы.
$this->getSearchEngine()->in('Articles')->find('name','Obama')->orderBy('date')->all();С их помощью на PHP можно реолизовывать красивые и удобные DSL. При этом писать такие вложенные вызовы — просто песня. При работе в IDE выбираешь нужную функцию и подставляешь параметры. Добавить бы сюда монад и вообще б цены не было.
2. Кодогенерация. Казалось кто кроме PHP позволяет сгенерить файл и тут же его подключить? Это же реальная фича. Почему ею так мало пользуются? Сгенерированый код — лучше всякой магии. Зачем интерпретатору в реальном времени пробираться через толпу декораторов, прокси-классов и прочих надстроек. Сгенерируйте ему класс и пусть он его использует. Это быстро и удобно. Посмотрите, тот же Propel, где генерируются классы моделей и запросов:
$books = BookQuery::create() // retrieve all books...
->filterByPublishYear(2009) // ... published in 2009
->orderByTitle() // ... ordered by title
->joinWith('Book.Author') // ... with their author
->find();
А вот, как, например, с помощью кодогенерации можно заменить те же Dependency Injection Container'ы. Выбрасываем нафиг все абстракции и просто разрабатываем.
Я не утверждаю, что эти идеи должны стать PHP way. Просто стоило бы сосредоточиться на фичах самого PHP и развивать их, а не заимствовать идеи и внедрять их «костылями». Впрочем, тут всё сложно. Ведь язык, как и компоненты, каждый развивает как хочет.
Выводы
Что можно сказать. У PHP есть потенциал. Но он не раскрыт. Пока что сообщества Ruby и Python намного продуктивнее раздробленного сообщества PHP. Нам есть чего у них поучиться. Хватит устраивать холиворы. Давайте развивать PHP и делать его лучше.
Автор: Davert
