Perl vs PHP: perl против PHP
Основная разница между Perl и PHP
Сама природа Perl и PHP различна. Perl — это язык программирования — универсальный инструмент для решения очень широкого круга задач. Perl не разрабатывался специально для Web-программирования.
PHP изначально предназначался для разработки Web-приложений. Он пытается сочетать мощь полноценного языка и преимущества узкоспециального средства. В поисках компромисса, PHP приобретает целый ряд спорных качеств.
Ядро языка
Perl, как и любой полноценный язык, имеет некоторое ядро — набор функций и правил, которые не зависят от платформы, операционной системы и прочих обстоятельств. PHP такого ядра практически не имеет. Отсюда проистекает целый ряд особенностей PHP.
Переносимость
Набор функций PHP, который оказывается в распоряжении программиста, практически полностью зависит от провайдера. («Правильные» провайдеры всегда пишут, с какими опциями был собран их PHP.)
Эта разница весьма ощутима. Например, если сайт разработан с использованием Smarty, то он заработает далеко не на всяком хостинге. И происходит это только потому, что аппарат Smarty использует POSIX-расширение механизма регулярных выражений.
Если ваше PHP-приложение написано с использованием функций, которых хостер не предоставляет, или вы использовали библиотеки, которые зависят от таких функций, то расширить набор функций PHP самостоятельно чаще всего нельзя.
Perl в этом смысле более стабилен. Он везде одинаков и Perl-код гораздо более переносим.
Количество функций
PHP предоставляет (потенциально) великое множество функций. На настоящий момент их более 3000. На реальном хостинге вы обнаружите около 1000 из них. Такой широкий набор выразительных средств не идёт на пользу языку. Разные программисты знают разные наборы операторов. Это затрудняет чтение чужого кода, обмен кодом и совместную разработку.
Perl же предоставляет программисту ограниченный набор стандартных инструментов. Это дисциплинирует программиста и облегчает обмен кодом и опытом. При этом, программист совсем не скован и всегда может получить требуемые возможности, подключив соответствующий модуль.
Синтаксис
Так уж получилось, что внешне программы на Perl и PHP чем-то похожи. Можно сказать, что если человек чуть-чуть знает Perl, то он чуть-чуть знает и PHP, но если человек хорошо знает Perl, то PHP он знает по-прежнему лишь чуть. Обратное тоже верно.
Перечислю некоторые особо выразительные отличия.
Конечно, обеспечить немыслимое количество функций PHP можно было только ценой удлинения их имён. Это не могло не сказаться на синтаксисе языка. То, что в Perl называется pop, в PHP array_pop. То что в Perl — join, в PHP — implode. Решение одной и той же задачи на PHP обычно более громоздко.
Напишем функцию, которая возвращает три значения (1, 2, 3).
Perl
# функция
sub a { return (1,2,3) }
# вызов
($a, $b, $c)=a();
PHP
# функция
function a() { return array(1,2,3); }
# вызов
list($a, $b, $c)=a();
В PHP конструкция получается более тяжеловесна.
Кроме того, в PHP и не пахнет Perl-скороговоркой.
Заменим все шестнадцатеричные числа в тексте на их десятичные представления.
Perl
$text=~s/([0-9A-F]+)/hex($1)/ige;
PHP
$text=preg_replace_callback('/[0-9A-F]+/i',
create_function('$t', 'return hexdec($t[0]);'),
$text);
# или
$text=preg_replace('/[0-9A-F]+/ie', "hexdec('$0')", $text);
Одно и то же действие, но даже короткий PHP-код в два раза длиннее, чем Perl-аналог.
Зрелость языка
Безусловно Perl является гораздо более зрелым языком, чем PHP. Он гораздо меньше подвержен изменениям при переходе от версии к версии и снабжён более развитыми средствам разработки.
Достаточно сказать, что в PHP механизм указателей находится в зачаточном состоянии. Perl миновал этот этап развития лет десять назад. В PHP не предусмотрена такая структура данных, как массив. (То, что в PHP называется «массив», в Perl называется «хэш».) В этом смысле PHP находится на уровне awk.
Одним словом, PHP ещё долго будет меняться, создавая множество проблем разработчикам.
Адаптированность для Web-разработок
При ведении именно Web-разработок, PHP обнаруживает ряд существенных преимуществ.
Во-первых, интерпретатор PHP интегрируется в Web-сервер, что в разы увеличивает производительность. Perl способен догнать PHP по производительности, только если использовать не CGI-подход, а mod_perl. Большинство провайдеров не предоставят вам такой возможности.
Во-вторых, Web-приложения на PHP проще отлаживать. Сообщения об ошибках часто выдаются клиенту, а не пишутся в error_log.
В-третьих, PHP имеет широкий набор встроенных функций, для работы по протоколу HTTP. Perl-программисты тоже могут получить в своё распоряжении все эти функции, подключив соответствующий модуль, но в PHP эти функции встроены.
Однако, почти все эти преимущества оборачиваются серьёзными проблемами с точки зрения безопасности ресурса.
То, что PHP встроен в сервер, затрудняет диагностику источника атак. Кроме того, PHP-код, потенциально, может нести гораздо большие угрозы, чем Perl-код.
PHP даёт большую свободу разработчику — PHP-скрипт может быть размещён в любой директории сервера. Но это тоже создаёт дополнительные риски. Во многих случаях, по невнимательности разработчиков, посетитель сервера получает возможность «залить» на сервер не только картинки и другие безобидные файлы, но PHP-скрипты, а это уже очень серьёзная опасность.
То, что PHP выдаёт сообщения об ошибках в ответ на HTTP-запрос, удобно для разработчика. Но с точки зрения безопасности это решение мне всегда казалось спорным, ведь любой посетитель вашего сайта может узнать об ошибках в ваших программах. А злоумышленнику может оказаться достаточно узнать версию вашего PHP, чтобы «сломать» ваш ресурс.
Одним словом, PHP «заточен» под Web-разработки лучше, чем Perl, но об это лезвие очень легко порезаться самому.
Документация
Perl имеет собственную систему документирования и снабжён прекрасной документацией на английском языке.
PHP тоже прекрасно документирован. Преимуществом документации PHP является то, что она переведена на русский язык. К недостаткам я бы отнёс её необъятность.
Качество кода
Конечно, качество кода во многом завит от программиста, но и язык может либо диктовать разработчику определённый стиль, либо расхолаживать.
Выше я уже говорил, что большой и не постоянный набор функций не способствует созданию программ, которые легко читать, отлаживать, адаптировать и переносить. Но основной проблемой PHP, на мой взгляд, является то, что этот язык позволяет смешивать HTML-код и PHP-код. Фактически, это смешение данных и кода.
Я не буду здесь вдаваться в философию, но человечество уже десятки лет назад осознало, что код и данные следует разделять. Для этого найдено множество изящных решений, от хедеров и конфигурационных файлов, до шаблонов и обособленных хранилищ данных. В этом смысле PHP представляется шагом назад; каким-то старорождённым.
Но если отложить философию и посмотреть на это с прикладной точки зрения, то ничего хорошего мы тоже не увидим. Объединение HTML- и PHP-кода не улучшает читабельность ни того, ни другого. Соответственно, сопровождение, модернизация и модификация программ тоже затрудняются.
Конечно, этот минус (на мой взгляд) PHP начинает играть существенную роль, только если web-приложение достаточно развито, кода много и разработчики не вынесли HTML-код в шаблоны или не обособили его как-то иначе.
Но существуют недостатки, «встроенные» в сам язык.
Так, например, мне представляется очень неудобным то, как регламентируется передача параметров функциям. Будет ли параметр передан по значению или по ссылке определяется не при вызове функции, а при её создании. Вызов же выглядит одинаково и в том и в другом случае. Это удобно, если автором всеx функций являетесь вы сами, и вы хорошо помните прототипы ваших функций. Но при активной работе в команде это приводит к путанице.
Точно также обстоит дело и с функциями, возвращающими указатели.
На мой взгляд, это самый большой из тех недостатков PHP, которые никак нельзя обойти.
Итого
Универсального правильного решения, что лучше Perl или PHP, не существует. В каждом конкретном случае решать вам. Ответ зависит и от масштаба ресурса, и от амбиций, планов и перспектив, и от конкретного хостера.
Я бы советовал поступать так:
• если ресурс не предполагает большой нагрузки (личная страница, страница небольшой фирмы), то надёжнее опереться на Perl и протокол CGI;
• если ресурс предполагает большую посещаемость, но его бюджет сильно ограничен, то можно воспользоваться недорогим виртуальным хостингом и PHP-движком;
• если ресурс велик и вы планируете поддерживать и развивать его долгое время, то лучше воспользоваться дорогим хостингом (собственным севером) и Perl под mod_perl. В этом случае ваш код будет работать много лет. Ресурс будет расти, вы поставите более мощный сервер, более свежее ПО, а Perl-код не потребует больших изменений и будет продолжать служить вам.
Это, естественно, достаточно грубые рекомендации. Если вы сомневаетесь — проконсультируйтесь со специалистом.
Кроме того, не надо забывать, что кроме Perl и PHP есть и другие средства разработки.