Автор: ShiningRay, 3 апреля 2006 г.
Эдвин Мартин < [email protected] >
Перевел: ShiningRay @ Nirvana Studio
Последние четыре года я занимаюсь разработкой PHP-приложений. PHP действительно легко писать. Но у PHP также есть несколько очень серьезных недостатков.
Ниже я приведу причины, по которым PHP не подходит для веб-сайтов большего размера, чем небольшие любительские сайты.
1. Плохая поддержка рекурсии. Рекурсия — это механизм вызова функций сами собой. Это мощная функция, которая может превратить что-то сложное в нечто очень простое. Примером использования рекурсии является быстрая сортировка. К сожалению, PHP не очень хорош в рекурсии. Зеев, разработчик PHP, сказал: «PHP 4.0 (Zend) использует для плотных данных подход стека, а не кучи. Это означает, что количество рекурсивных функций, которые он может поддерживать, значительно менее ограничено, чем в других языках». См. ошибку 1901. . Это очень плохое оправдание. Каждый язык программирования должен обеспечивать хорошую поддержку рекурсии.
2. Многие модули PHP не являются потокобезопасными. Несколько лет назад Apache выпустил версию веб-сервера 2.0. Эта версия поддерживает многопоточный режим, в котором одна часть программного обеспечения может одновременно запускать несколько частей. Изобретатель PHP говорит, что ядро PHP является потокобезопасным, а неосновные модули — нет. Но в девяти случаях из десяти вы хотите использовать этот модуль в PHP-скрипте, но это делает ваш скрипт несовместимым с многопоточным режимом Apache. Вот почему команда PHP не рекомендует запускать PHP в многопоточном режиме Apache 2. Плохую поддержку многопоточного режима PHP часто называют одной из причин, почему Apache 2 остается непопулярным.
Пожалуйста, прочитайте это обсуждение: Slashdot: Сайты отвергают Apache 2?
3. PHP не работает по деловым причинам. Используя кэширование, производительность PHP можно увеличить на 500% [см. тест]. Так почему же кэширование не встроено в PHP? Потому что Zend, производитель PHP, продает собственный Zend Accelerator, поэтому они, конечно, не хотят отказываться от своего коммерческого продукта.
Но есть и другая альтернатива: APC (позже Zend запустил Zend Optimizer, бесплатный ускоритель-переводчик)
4. Нет пространства имен Представьте, что кто-то сделал PHP-модуль для чтения файлов. Одна функция в модуле называется read. Тогда модуль другого человека может прочитать веб-страницу, которая также содержит функцию чтения. Тогда мы не сможем использовать эти два модуля одновременно, потому что PHP не знает, какую функцию вы хотите использовать.
Но есть очень простое решение — пространства имен. Кто-то однажды предложил добавить эту возможность в PHP5, но, к сожалению, он этого не сделал. Теперь, без пространств имен, перед каждой функцией должно стоять имя модуля, чтобы избежать конфликтов имен. В результате имена функций становятся ужасно длинными, например xsl_xsltprocessor_transform_to_xml, что затрудняет написание и понимание кода.
5. Нестандартные символы формата даты. Многие программисты знакомы с символами формата даты, которые пришли из языков UNIX и C. Несколько других языков программирования приняли этот стандарт, но, как ни странно, PHP имеет свой собственный набор совершенно несовместимых символов формата даты. В C «%j» представляет день года, а в PHP — день месяца. Однако, чтобы еще больше запутать ситуацию: функции strftime и date_format Smarty (популярного шаблонизатора PHP) используют символы форматирования C/UNIX.
6. Сбивающая с толку лицензия. Вы можете подумать, что PHP бесплатен, как и все модули PHP, упомянутые в руководстве. Неправильный! Например, если вы хотите генерировать PDF-файлы на PHP, в руководстве вы найдете два модуля: PDF и ClibPDF. Но оба они имеют коммерческую лицензию. Итак, для каждого модуля, который вы используете, вы должны убедиться, что согласны с его лицензией.
7. Несогласованные правила именования функций. Имена некоторых функций состоят из нескольких слов. Обычно существует три способа сочетания слов:
прямое сращивание: getnumberoffiles.
Разделяйте подчеркиванием: get_number_of_files.
Закон верблюда: getNumberOfFiles
Для большинства языков выберите один из них. Но используется PHP.
Например, если вы хотите преобразовать некоторые специальные символы в объекты HTML, вы должны использовать функцию htmlentities (непосредственное объединение слов). Если вы хотите использовать противоположную функциональность, вам нужно использовать его младшего брата html_entity_decode. По какой-то особой причине в имени этой функции слова разделены подчеркиванием. Как такое могло быть? Вы знаете, что есть функция strpad. Или он str_pad? Каждый раз приходится проверять, что это за символ, или просто ждать ошибки. Функции нечувствительны к регистру, поэтому для PHP нет разницы между rawurldecode и RawUrlDecode. Это тоже плохо, потому что используются оба и выглядят по-разному, что сбивает читателя с толку.
8. Чертовы волшебные кавычки Волшебные кавычки могут защитить PHP-скрипты от атак SQL-инъекций. Это хорошо. Но по некоторым причинам вы можете отключить эту настройку в php.ini. Поэтому, если вы хотите написать гибкий сценарий, вам всегда нужно проверять, включены или выключены магические ссылки. Такая «фича» должна облегчить программирование, но на самом деле она его усложняет.
9. Отсутствие стандартной структуры. Растущий веб-сайт без общей структуры в конечном итоге станет кошмаром для обслуживания. Фреймворк может облегчить многие задачи. Наиболее популярной моделью фреймворка сейчас является MVC-модель, в которой разделены уровень представления, бизнес-логика и доступ к базе данных.
Многие веб-сайты PHP не используют модель MVC. У них даже нет рамки. Даже сейчас существует несколько PHP-фреймворков, и вы можете написать их самостоятельно. Статьи и руководства по PHP ни словом не улучшают этот фреймворк. Хотя разработчики JSP используют такие платформы, как Struts, а разработчики ASP используют .Net, похоже, что эти концепции широко понимаются разработчиками PHP. Это показывает, насколько профессиональным является PHP.
Подвести итог
В чем проблема?
Для очень маленьких проектов это может быть вполне удовлетворительный язык программирования. Но для более крупных и сложных проектов PHP показывает свою слабость. Продолжая исследовать, вы найдете решения некоторых проблем, о которых я упомянул. Итак, если решение известно, почему бы не исправить его? И почему эти исправления не упомянуты в руководстве?
Хорошо, что язык с открытым исходным кодом очень популярен. Но, к сожалению, это не лучший язык. Я надеюсь, что все проблемы однажды будут решены (может быть, в PHP6?), и тогда у нас будет язык с открытым исходным кодом, который будет одновременно открытым и простым в использовании.
К этому моменту, если вы хотите запустить проект с более чем 5 страницами сценариев, вам лучше рассмотреть C#/ASP.Net или Java/JSP или, возможно, Python также будет лучшим выбором.
Источник этой статьи: http://workgroup.cn/CS/blogs/php/archive/2006/06/29/1354.aspx .