Язык php и perl
Переходим с PHP на Perl, как это ни печально.
PHP, конечно, язык хороший… Во всяком случае, синтаксис у него на порядок проще и яснее, чем у Perl. И конструкций/инструкций меньше. Это достоинство. Например, в Паскале конструкций еще меньше, но это не мешает ему называться почти что одним из самых алгоритмизируемых языков.
С чем очень неприятным сталкивается каждый программист, который переходит на Perl? Конечно, с тем, что ошибки скрипта выводятся в log’и сервера, а не прямо в браузер. И нельзя это никак переключить (есть, правда, один стандартный модуль с громким параметром fatalsToBrowser, но в browser он выводит только эти самые fatals, а предупреждения — по-прежнему в логи). В PHP ошибки по умолчанию выводятся туда же, куда и обычные данные.
Следующее мерзкое свойство Perl — постоянно выдавать 500-ю ошибку. За подробностями, якобы, обращайтесь к логам сервера. Ага, сейчас… Причем эта самая 500-я ошибка выдается из-за того, что какой-то print проскочил раньше вывода заголовка «Content-type». В PHP никто не проскочит раньше его. Потому что там отслеживается: если что-то печатается, а заголовка нет, то вначале передаетс я именно заголовок «Content-type».
Теперь насчет управления переменными. В PHP любая переменная начинается с «$». Никаких там мерзких «@», «%», «&» и других символов для переменных разных типов. Они — пережитки Юниксовского shell-а (кто не прочувствовал, посмотрите установочный файл Apache, написанный на csh — он занимает около 100 Кб). Зачем они интерпретатору? Он ведь и так знает, кто есть кто.
Обработка форм. Пожалуй, в PHP она работает почти идеально. И быстро. И с поддержкой массивов (правда, только одномерных). А также с поддержкой закачки — теперь для организации upload-а не нужно делать вообще ничего — сиди и жди, пока файл не придет, а потом забирай его из временной директории.
Базы данных. Чтобы обращаться к базам данных, нужно использовать модули, многие из которых имеют просто феноменально большой размер, что, конечно, сказывается на быстродействии. А в PHP поддержка БД встроена. Имеется практически полный набор функций для работы с почти всеми известными человечеству базами данных. На все случаи жизни.
Если душе хочется универсальности, то очень быстро отказываешься от того, чтобы выводить страницы при помощи скриптов через оператор print. Например, так:
Я думаю, достаточно перечислять, чем PHP лучше Perl-а. Интереснее будет посмотреть, где он хуже. Итак…
Удивительная медлительность. Так, пустой цикл в PHP выполняется в 70 раз медленнее, чем в Perl. егулярные выражения работают в 10 раз медленнее. Строковые операции — примерно в 5 раз медленнее. И как только они умудрились так написать.
Вообще никакой поддержки модульности. Правда, ее можно все-таки организовать вручную, и потом работать с «модулями», почти как в Perl. Но получается очень медленно. Основное время выполнения скрипта оказывается затраченным на подключение модулей.
Немного недоделанный интерпретатор. Так, если функция возвращает массив, мы не можем обратиться к его, скажем, пятому элементу при помощи Func(10,20)[5] — только через промежуточный массив. Но, кстати, это не так уж и обременительно.
Пожалуй, все. Всего два крупных недостатка, но каких…
Совсем недавно я убедился, что все достоинства 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
В PHP конструкция получается более тяжеловесна.
Кроме того, в PHP и не пахнет Perl-скороговоркой.
Заменим все шестнадцатеричные числа в тексте на их десятичные представления.
Perl
Одно и то же действие, но даже короткий 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 есть и другие средства разработки.
PHP/Perl: когда их нужно использовать, а когда не стоит
Как и у любого языка программирования, у PHP и у Perl’a есть свои положительные стороны и недостатки. Автор статьи предлагает своё видение того, когда их стоит использовать, а когда нет.
Очевидно, что автор не считает PHP «правильным» языком для построения Web сайтов и предлагает писать на нём только их предварительные версии, которые впоследствии будут переписаны с использованием, например, Java.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
есть у моего факультета сайт, написанный студентами-выпукниками на java. кроме тормознутости и антиюзабельности падает регулярно чуть ли не раз в неделю. при этом замдекана или её шестёрка звонят уже-не-студенту-автору-сайта и просят пофиксить/перезагрузить
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>с использованием, например, Java.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Все дело в волшебных руках! Знаешь, на чем написан ЛОР?
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>написанный студентами-выпукниками на java. кроме тормознутости и антиюзабельности падает регулярно чуть ли не раз в неделю
Руки вытаскивать из задницы и отчищать их от вазелина не пробовали?
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
> Все дело в волшебных руках! Знаешь, на чем написан ЛОР?
таки на редкость неудобный сайт, этот ваш ЛОР..
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Perl + PHP вместе взятые с хорошим запасом заменит Python.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
а может на C переписывать стоит?
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>таки на редкость неудобный сайт, этот ваш ЛОР..
Кстати да, сложно не согласиться.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
фтопку PHP с пистоном. Perl рулед!
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>предлагает писать на нём только их предварительные версии, которые впоследствии будут переписаны с использованием, например, Java.
/me считает что автор либо жуткий графоман, либо его мозг сильно поврежден
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
> с использованием, например, Java.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>/me считает что автор либо жуткий графоман, либо его мозг сильно поврежден
Похоже, что модераторы ЛОРа заказывают статьи вида «PHP vs. Perl vs. Python», «Qt vs. GTK», «KDE vs. Gnome» etc и затем подтверждают их же в новостях, чтобы не сайте не утихал постоянный флейм
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
А сайты на асме так вобще должны летать! Причем желательно чтобы асм был запущен на голой железяке без какого-либо излишества вроде опреационки или консоли. ну скажем на кластере из XScale.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
тема python не раскрыта
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
> А сайты на асме так вобще должны летать!
асм для манерных. нормальные ребята пишут непосредственно в кодах
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
When should you use PHP?
* Creating an intranet site. * Prototyping an application that will be converted to Java or some other language. * Creating a Web database application. * Deploying an inexpensive or quick solution. * Using ready-made apps from Sourceforge.net or other sites.
Ну-ка покажите мне, где тут говорится, что пехапе не надо использовать для сайтов? как раз наоборот. Если слово application у кого-то вызывает однобокую ассоциацию с веб-сайтом, то ему ближайшей стене.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
В вэбе приходилось программировать и на perl, и на php. Если использовать mod_perl и иметь руки, растущие из правильного места, то php не нужен.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>Очевидно, что автор не считает PHP «правильным» языком для построения >Web сайтов и предлагает писать на нём только их предварительные версии, >которые впоследствии будут переписаны с использованием, например, Java.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
>о ему ближайшей стене. Да зачем последние мозги выбивать, пусть лучше попробует хоть английский выучить с небольшим запасом имеющегося.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
Лор удобнее и понятнее быдлофорумов на попсовых пых-пых движках. И не тормозит никак. 🙂
>php хостинг распространённее
Венда тоже распространённее, однако это не делает её лучше.
Re: PHP/Perl: когда их нужно использовать, а когда не стоит
> Perl’s greatest claim to fame has always been the tight integration of regular expressions
бла бла бла бла. вот эту тему я слышу от любителей перла не в первый раз. но, если честно, это несерьезно
> One of perl’s strengths has always been the strong database interoperability through the DBI and DBD libraries
как будто в других языках нет библиотек для работы с бд на любой вкус.
> A replacement for shell scripts:
плохая идея. всему своё место+зависит от того что знаешь лучше.
если автор не осилил шелл, не читал abs и т.д. это не значит что шелл отстой.
> One of the worst things about shell scripting—whether in bash, sh or csh—
csh вообще давно в топке покоиться(дада я знаю есть современные его версии, но. нафиг их. ksh/bash давно их подвинули. ещё с выходом system v r.4)
> is that the syntax of the scripts themselves is fairly hard to read
опять бред. во-первых чья бы корова мычала. во-вторых что-то у меня проблем с shell скриптами нет, они отлично читаются благодаря простоте и стройности(конечно можно написать жуть всякую на чем угодно, но это не показать).
дальше я читать не стал. про php я даже не стал открывать статью. ибо всё ясно. дорогие любители perl, не осилившие других языков. я ничего против perl не имею, я уважаю perl, perl-хакеров и ларри волла(его вообще обожаю, один из самых харизматичных персонажей:).
у perl есть традиции, культура и т.д. он хорошо подходит для многого при наличии прямых рук.
но! хватит рвать тельняжки «да perl рулез, потому что в нем регулярки» ибо вы просто показываете своё невежество. рекомендую всё-таки преодолеть религиозные комплексы и ознакомиться с некоторыми другими языками, сейчас они умеют много, чего не умеет(к сожалению) perl.
хотя, perl 6, возможно, изменит ситуацию.
php и perl, part 1
отрицательного отношения к perl`у никогда не испытывал. как бы первый php был создан именно на нём, что уже говорит кое о чём. но само изучение постоянно откладывалось «на потом». в своё оправдание могу сказать словами из анекдота * : «не учил потому, что он мне был на фиг не нужен».
но хорошему (или плохому, смотря с какой стороны посмотреть) приходит конец. неожиданно знания этого чудо человеческой мысли понадобились. те несколько дней, что мы провели в обнимку, надолго нам запомнятся.
теперь главное: статья не тема святой войны между “паладинами perl” и “быдлокодерами php”. после пристального ознакомления смею заверить: быдлокод скорее возможен на perl; php более строг и при умелом обращении программирование на нём сводится к сплошному удовольствию.
для начала хочу заметить, что переход с си-подобного языка на perl сопряжён с некоторого рода трудностями (зная c или javascript гораздо проще будет освоить php).
самая главная проблема при программировании на perl для web это ошибка 500. подавляющее большинство, попробовав написать первую программу замечают, что она же является и последней. попытка что-то спросить (особенно если упомянуть, что до этого программировал на php) приводит к пачке насмешек, что тоже не способствует популяризации языка. подход php более удобен: ошибка выводится в браузер, но это, в свою очередь, начинающих очень нервирует. и когда новички узнают про оператор @, писку ихнему нет предела; ошибка забарывается, не успев начавшись. плохо ли это? очень! но, как и в html, можно писать логически неверные вещи — интерпретатор всё благополучно «скушает» и выдаст именно тот результат, который требуется. perl`у этого для быстрого вхождения не хватает.
едем дальше. простой perl-код:
приводит к неожиданной ошибке. правильно так:
. да-да, не забываем фигурные скобочки. javascript и php понимают оба варианта.
«пустяк», скажут перловчане? вот ещё код:
. круто? ещё бы! а работает? однозназно да! только не так, как требуется. чтобы побороть подставу и заставить заработать условие как нужно, потребуется маленькая правка:
. прямо скажу, засада оказалась тоже весьма неожиданной. строковые данные следует сравнить иначе, нежели целые.
ещё одна подстава, и снова связана с условием:
пишем, радуемся, запускаем и получаем ошибку 500. почему так? а потому, что в псевдо-си-подобном perl нет операнда elseif. код требуется изменить:
ума не приложу, зачем вместо elseif понадобилось использовать elsif. но так есть.
Автор публикации
x64 (aka andi)
Похожие записи
Любви и богатству все возрасты покорны: великолепная восьмёрка
Как мы сами воруем свои деньги
Тупые американские законы! Или нет?
11 комментариев
1) а как Вы думаете, почему php попёр в гору, а perl остался уделом избранных? уж не из-за того ли, что php, встретив ошибку, выводил её в браузер пользователю, а перл «ласково» ругался 500 ошибкой и посылал смотреть логи? php более дружественен к людям, пишущем на нём. в перле есть хорошие методы борьбы с 500 ошибкой, но почему они не доступны сразу и из коробки?
2) функции сортировки геморроя не создают. если человек, пишущий на php, не знает какую либо функцию, он просто вобъёт её в поиск и мгновенно получит ответ. а вот поиск по ограничителям регулярок в перловских манах не особо удобен;
3) слова «в перле обычно пишут не так» следует понимать как «я пишу не так». и обратная запись сравнения не всегда удачно вписывается программистами в код. порой с первого раза даже непонятно, что, собственно, код делает;
4) если человек не знает, что сравнивает, это уже явно не косяк языка, а недостаточная проработка архитектуры программы. и нескольких сравнений уж точно можно избежать. сомневаетесь? javascript в помощь. и чем же asort/rsort не устраивают? как я уже говорил, это функции, и достаточно один раз прочитать их описания, после чего всё встанет на свои места:
— sort — сортировка по значениям, после работы хеш превращается в список;
— rsort — аналогично предыдущему, только сортировка в обратную сторону;
— asort — сортировка по значениям с сохранением ключей;
— arsort — аналогично предыдущему, но значения располагаются в обратном порядке.
5) когда в оправдание сказать нечего, уже стало за правило символами мериться. если делали синтаксис си-подобный, глупо было не использовать что-то более привычное.
вообще, холиваров на подобные темы много: php vs perl, mysql vs postgresql, и ещё пачка. так получается, что одни вещи являются инструментами для жжёных старообрядцев, а вторые пусть и не такие мощные, зато более удобные и дружественные.
а здравствуйте. да что Вы, какая агрессия? просто думал, что прибежал кразноглазый фанат перла, который до смертного одра будет считать, что чистый код может быть только на перле, а всё остальное (особенно пхп) — быдлокод. прошу прощения, если показался слишком резким.
да, куча функций, конечно, больная тема. и разработчики уже, думаю, порядком себе локти покусали. тем более, что простанство имён появилось только в версии 5.3, так что людям приходилось довольствоваться «затычками». но! для конечного пользователя, в принципе, всё равно: запомнить одну функцию с кучей параметров или несколько простых процедур, каждая из которых выполняет свою сортировку. я это не поддерживаю, с одной стороны, но с другой как сделали, так и стало (а кому надо, уже привыкли). ну и по поводу начинающих программистов тоже неоднозначно. скорее, постоянный 10-кратный if зло не меньшее, чем десяток функций, выполняющих, по сути, одно и тоже.
ну и про elsif. дело тут даже не в том, что быстро привыкаешь. когда мне потребовался перл, в недоумение повергла ошибка в месте else if/elseif: ни одно из этого не подходило. пришлось зарыться в маны, и только там нашёлся ответ. аналогично было, когда мне потребовался перебор, и отказались работать break/continue. да, здорово, когда новый язык похож на что-то уже знакомое. но когда он оказывается «похож, но некоторые операторы названы по другому», это уже злит, не говоря о том, что мешает работе.