Переходим с PHP на Perl, как это ни печально...

А как же PHP4???

А статейка не запоздала так на годик ?? Ощущение, что автор слабо знаком с PHP, да и то только со старой версией.

Что за бред про то, что мы не можем напрямую обратиться к элементу массива... Кто тестирует быстродействие пустыми циклами ?

Почему забыты затраты перла на форканье скрипта, на тормознутость cgi, на жручесть памяти мод перлом ... куда делись эти минусы, которые всегда вылезают первые ?

Куда делся зендоской оптимайзер ?

Автор пробовал когда нибудь сделать что-то серьезное на PHP и Perl - а потом перетащить это на сторонний хостинг ? PHP будет пахать всегда, так как все из одного флакона. А вот Perl - редко, ибо начинается "а нету этого модуля, и этого тоже нет". Делать без модулей, самим ?? Мне геморой не нужен, у меня пхп раз в десять удобней и быстрее для написания будет.

Так что не советую обращать внимание на эту статью, а просто самим попробовать и то, и другое.

> А статейка не запоздала так на годик??
Именно год назад я ее и написал.

> Ощущение, что автор слабо знаком с PHP, да и то только со старой версией.
Автор в данный момент зарабатывает на жизнь чтением курсов по языку
PHP3 в учебном центре Микроинформ (http://www.microinform.ru) и пишет
книгу под названием "Основы PHP4" (объемом примерно 600 стр). Пара
официальных исправлений в ядре PHP3 (см. changelist) - его рук дело.

> Что за бред про то, что мы не можем напрямую обратиться к элементу массива...
Имеется в виду то, что в PHP нет такого понятия, как "списковый
контекст", как в Perl (или контекст массива, как в Си). Поэтому мы не
можем использовать конструкцию (выражение_возвращающее_массив)[xxx], а
также не можем использовать что-то типа
FuncWhishReturnsObject()->property (последнее ужасно неудобно).

> Кто тестирует быстродействие пустыми циклами ?
Это - самый лучший способ проверить, на что способен интерпретатор.
Да, PHP3, PHP4 и даже Perl - интерпретаторы, но с оптимизирующими
трансляторами. О компиляции ни там, ни там речь и не идет (посколдку
компиляция - это трансляция в машинный).

> Почему забыты затраты перла на форканье скрипта,
Затраты ядра ОС, а не Перла. Кстати, а Вы знаете, как работает fork()?
Что такое страничное copy-on-write? rfork()? Таблица страниц ядра?
И как Вы думаете, сколько раз в секунду система, работающая на P100,
может вызвать fork()? (Ответ - около 20000, конечно, если потомки будут
своевременно умирать.)

> на тормознутость cgi, на жручесть памяти мод перлом ...
И то, и другое проявляется только в случае больших нагрузок на
сервер. Если скрипт большой, то зататы PHP и даже Perl на трансляцию
кода оказываются в сотни раз больше (правда, Perl тут все-таки на
порядок быстрее). У меня на руках проект как раз такого объема,
написанный целиком на PHP, который в свое умер из-за тормозов PHP:
http://www.enews.ru
В ближайшее время планируется переписать его на PHP4 И дать ему новую
жизнь.

> куда делись эти минусы, которые всегда вылезают первые ?
Первыми вылезают следующие минусы:
- практически невозможно использовать PHP3 для работы с небольшим
скриптом объемом, скажем, 150Кб - он парсится 6 секунда на PII-500;
- трудно писать большие скрипты, если язык очень плохо поддерживает
модульное программирование.

> Куда делся зендоской оптимайзер ?
По моим тестам, PHP4 действительно где-то в 10 раз превосходит по
скорости PHP3, но все же отстает в 4 раз от Perl.

А Вы никогда не копались в исходниках PHP4? ТОгда поясню на примере.
Как истинный транслятор (которым якобы является zend) ВООБЩЕ может
обрабатывать, например, такой код на PHP4:

-------------------------------------------------------------------
$v=считать_из_файла_1_или_0;

if($v==1) {
function A() { echo "A!"; }
} else {
function A() { echo "B!"; }
}

A(); // вызывается та A(), которая находилась в нужном if-e
-------------------------------------------------------------------

Так как то, какой именно if срабатывает, оказывается известным лишь НА
ЭТАПЕ ВЫПОЛНЕНИЯ, но не на этапе оптимизации, мы вынуждены заключить,
что тело функции A() транслируется (компилируется, если выражаться
неправильно) ВО ВРЕМЯ ВЫПОЛНЕНИЯ, а не во время трансляции кода!

А? Что? Не слышу! Где, Вы говорите, тут хваленый зендовский
транслятор?

Для примера, при использовании НАСТОЯЩЕГО транслятора Perl аналогичный
код:
-------------------------------------------------------------------
$v=считать_из_файла_1_или_0;
if($v==1) {
sub A() { print "A!"; }
} else {
sub A() { print "B!"; }
}
A(); // вызывается та A(), которая находилась в нужном if-e
-------------------------------------------------------------------
просто не откомпилируется - скажет, что A() определена дважды.

> Автор пробовал когда нибудь сделать что-то серьезное на PHP и Perl -
> а потом перетащить это на сторонний хостинг ?
Только этим автор все время и занимается. По моим оценкам,
Perl-скрипты переносятся лучше, чем скроиты на PHP. Иллюзия обратного
возникла у Вас из-за того, что Перл при малейшей ошибке выдает
Internal Server Error, а PHP в этом случае выводит сообщение прямо в
браузер. Как уже говорилось, модуль WebOut полностью решает эту и
многие другие возможности, заставляя все ошибки Perl направляться в
браузер, аналогично PHP, и делая кучу дополнительных действий.

> PHP будет пахать всегда, так как все из одного флакона. А вот Perl - редко,
> ибо начинается "а нету этого модуля, и этого тоже нет".
Вы, наверное, используете для хостинга компанию, берущую за услуги
0.24 (нет, 0.24 с половиной!) доллара в месяц. Неудивително, что у них
не установлены модули, которые уже по всему миру признаны
стандартными.


> Делать без модулей, самим??
Где Вы такое услышали? Вы в следующий раз потише - так и до инфаркта
можно довести... ;-)

> Мне геморой не нужен, у меня пхп раз в десять удобней и
> быстрее для написания будет.
Обратите внимание на слова "у меня".
Некоторые скрипты, действительно, гораздо удобнее писать на PHP, но
сложные скрипты к ним не относятся (к моему глубокому сожалению).

> Так что не советую обращать внимание на эту статью,
Неправильно.

> а просто самим попробовать и то, и другое.
А вот это - золотые слова.

И последнее - несколько слов насчет PHP4. Он ГОРАЗДО лучше PHP3 и
потихоньку приближается к Perl по возможностям (в частности, оператор
===, исправленный eval(), буферизация вывода и многое другое). Я не
имею пока никаких сведений о том, можно ли на нем писать 150Кб
скрипты, но примерно через полгода это станет ясно. PHP3 для этого
использовать нельзя ОДНОЗНАЧНО.

С нетерпением ждем продолжение цикла :
"Переходим с Perl на C++, как это ни печально..."
"Переходим с C++ на Assember, как это ни печально..."
...

я тоже буду с нетерпением ждать выше описанного цикла статей

> Автор статьи в данный момент зарабатывает на жизнь чтением курсов

забал дописать, автор этого сообщения зарабатывает на жизнь тоже индивидуальным/групповым обученим ПХП в Питере :-) Еще выезды в др. города для интенсивного обучения за 1-2 недели. Если автор данной статьи напишет о ценах, то автор этого сообщения скажет, что у него цены на тоже самое раз в 10-20 дешевле :-)

ерунда какая-то (ничего личного)

такое впечатление, что к концу статьи автор сам забыл, что хотел сказать...

немножко утрирую:

1. пхп, конечно, лучше перла, потому что а) проще синтаксис, б) .....
2. а вот если немножко постараться, то многие неудобства связанные с применением перла, можно победить и делать то же, но средствами перла
3. вывод: перл лучше пхп!

ну совершенно алогичный вывод! ни тебе серьезной аргументации, ни-че-го!!!

а слабО написать пример, на котором пхп просто сломается? задачу, с которой программист не справится, используя только средства пхп? вот тогда народ бы действительно почесал бы репу и задумчиво сказал бы "н-да... пожалуй..." а данная статья лично во мне не вызвала совершенно никаких эмоций. полагаю, что я не один такой.

пожалуй, соглашусь только с одним: никудышная поддержка модулей в пхп. но это не значит, что только из-за этого перл настолько лучше пхп, что последний стОит забросить подальше. вот только насчет модулей следовало бы написать в Зенд - мы сами вряд ли сможем это исправить ;))

да, и еще. в сети куча обзоров, сравнивающих перл с пхп. так вот рефреном в них идет следующая мысль: если вы супер-круты в перле, то нет большой необходимости перейти к пхп, ничего другого вам и не надо - вы только потеряете время, переучиваясь - возможности языков совершенно идентичны. а вот если вы новичок в программировании для веба или чувствуете себя недостаточно уверенными в перле, то пхп - то что вам надо. и с этим трудно не согласиться, как и с тем, что каждому - свое.

Да, с последним я согласен на 100%, так как сам начинал в свою практику в Web с PHP (конечно, после C++).

Насчет аргументации: вообще говоря, эта статья (не знаю, можно ли ее так назвать) была написана не с целью какого бы то ни было описания, чем же Perl лучше PHP, а для того, чтобы рассказать о том, что, оказывается, не так уж и страшна мысль о том, что (возможно) стоит переходить на Perl.

Поясню последнее. Дело в том, что почти ровно год назад я читал семинар в Вебклубе (http://www.webclub.ru) на тему PHP. И вот, весь этот семинар я доказывал сторонникам Perl (пытался доказать), что им стоит перейти на PHP. Впрочем, кого-то мне все-таки не удалось убедить, и я был этим очень сильно удивлен: вот же, все достоинства PHP и недостатки Perl как на ладони, чего они ломаются?! Однако теперь (как видите) я сменил свою точку зрения. И чтобы больше никто не повторял моей ошибки (ну, теоретически), я и написал эту... этот... текст.

С PHP не так все просто однозначно, как, возможно, многие из нас думают. Да, PHP4 сильно обходит своего предшественника по всем показателям. Но все же ему не хватает... э-ээ... не побоюсь этого слова, ПОЭЗИИ Perl. Знаете, это когда вы читаете какое-нибудь китайское или японское стихотворение в переводе (типа хокку, не знаю правда, китайская ли эта штука, ну да все равно), вы не понимаете, что же такого тут особо красивого - все не в рифму, правда, информация передана точно, и все можно понять. Это PHP. Зато если вы услышите это же стихотворение в оригинале на китайском (при этом посредственно зная язык), вы почувствуете его красоту (рифму), зато, возможно, затратите некоторые усилия на понимание смысла. Это Perl.

Perl красив, но он коряв. У него очень корявый синтаксис, но с помощью него можно делать такие... красивые, что ли... вещи, что, можно сказать, что и Perl красив. Один его по-настоящему НОРМАЛЬНЫЙ транслятор чего стоит.

Простите, я знаю, что опять никого не убедил, но это именно то, о чем я думаю.

А насчет цикла типа "Переходим с Си++ на ассемблер" - это, простите, злопыхательство. Си++ и ассемблер - языки совершенно неравнозначные и пердназначены для таких целей, к уоторых нет вообще ничего общего. С Perl и PHP это не так. Можно даже сказать, что они конкуренты (и хотелось бы, чтобы PHP4 победил, но только вобрав в себя все достоинства Perl, но никак иначе!).

Почему я читаю курс про PHP3, а не про Perl? Да потому, что именно PHP сейчас очень популярен, а также потому, что это - идеальный язык для того, чтобы начать работать в Web "с нуля". Perl же все-таки не был ориентирован на Web изначально, поэтому некоторые возможности приходится на нем либо программировать самому, либо пользоваться стандартными (и очень корявыми в своем большинстве) модулями. Кстати, ни одного НОРМАЛЬНОГО модуля для работы с CGI я так и не видел, пока не написал свой собственный WebIn и WebOut (впрочем, не мне судить, нормальные ли они получились, но, кажется, да).

И, раз уж зашел разговор о корявости кода, еще пара слов на эту тему. Те, кто хорошо разбираются в Perl, могут посмотреть исходные коды многих модулей. Например, CGI.pm. Это просто ужасно. Нет, это даже страшно.

Но подождите. Возьмем-ка какую-нибедь систему на "более правильном языке" - на Си. Хотя бы тот же самый Линукс. Так вот, он вроде как ЦЕЛИКОМ (!) написан на стандартном (!) Си, в то время как дядя Страуструп еще в конце 80-х доказал, что Си++ гораздо лучше подходит для написания сложных и надежных систем, которые постоянно развиваются. Что это - отстование компьютерных технологий на 12 (!) лет? И да, и нет...

Почему, как в думаете, так удачлива компания Микрософт? Не потому, что она монополист (хотя сейчас ей это, конечно, очень помогает). Есть мысль, что все это из-за того, что все (!) свои программные продукты они вот уже с 95-го года пишут на Си++, а не на Си. И больше ни из-за чего. Каково?..

Говорят, что скоро Линукс задавит Windows. Боюсь, что этого не произойдет никогда (хотя мне лично этого бы немного хотелось, потому что Линукс менее требователен и довольно устойчив - Windows2000 не в счет, я с ним не работал). Однако, на мой взгляд, произойдет следующее: Микрософт доведет свой Windows до уровня Линукса.

Ну да ладно, бог с ними, с операционными системами. Давайте покомаемся внутри какой-нибудь другой программы - например, внутри sendmail. Я как раз этим занимался в субботу с целью добавить в sendmail возможность авторизации по POP3, ибо спамеры уже за... э-эээ... Ну, вы понимаете. А многие наши клиенты имеют программы, несовместимые с авторизацией по SMTP. О чем это я? Ах, да, про исходники. Вы не поверите, что ТАМ творится внутри sendmail. Мало того, что он писан на стандартном Си, он еще писан в стиле раннего Кернигана и Ричи. Это когда функции задаются вот так:

int F(a,b,c);
int a;
char *b;
float c;
{ код
}

И это в 2001-м году?! Теперь я не верю, что sendmail вообще когда-нибудь выйдет на такой уровень, что в нем будут отловлены все ошибки (которые постоянно находятся в новых версиях).

Я все это говорю к тому, чтобы, во-первых, указать, что практически все исходники (Perl или Си - неважно) написаны из рук вон плохо (хотя встречаются и довольно приличные, но очень редко), а во-вторых, объяснить, почему не будет никогда статьи "Переходим с Perl на Си++".

Оглянитесь вокруг, как несовершенен мир. 99% так называемых "взломов" происходят из-за переполнения буферов фиксированного размера в недобросовестно написанных программах. И это - вина ИСКЛЮЧИТЕЛЬНО стандартного Си. Самые популярные протоколы - telnet и ftp - вообще никак не шифруют передаваемые данные, что открывает потрясающие возможности для перехватов различных паролей. Наконец, сам ОТЕЦ - протокол IP - НЕ ПРОЕКТИРОВАЛСЯ для обеспечения безопасных (с точки зрения гарантии отсутствия перехватываемых данных) передач - так написано в одном из RFC, видел собственными глазами. Правда, есть SSH, но с ним - отдельные проблемы, вот они.

Если смотреть с точки зрения обычных пользователей, то, кажется, за всю историю человечества НЕ БЫЛО НАПИСАНО ни одной нормальной терминальной программы для Windows, которая бы правильно работала с telnet на, скажем, Линуксе (я имею в виду, чтобы работали все клавиши, рамки там всякие и русские буквы). Во всяком случае, я такую пока не встречал - во всех есть какие-то мелкие и весьма раздражающие недоработки, например, не работают клавиши F5-F10, не отображаются русские буквы и цвета, наконец, глючит скроллинг, как в stelnet.exe. Создается впечатление, что вообще никто не подключается удаленно с Windows-машин к Unix-серверам при помощи Telnet. Что уж тут говорить о терминальных программах с поддержкой SSH...

Ой, что-то я отвлекса - наверное, к снегопаду...

Итак, вот как мне сейчас представляется будущая картина: Perl умрет, но PHP будет жить (это лет этак через 5). Perl умрет, потому что в нем не особо хорошо продумана концепция ООП, в этом PHP его по синтаксису (заметьте, только по синтаксису, не по возможностям!) обходит. Однако PHP также написан на стандартном Си (и куда только парни из Zend-а смотрели?!). Это очень сильно сдерживает темпы его развития (кто не верит, пусть посмотрит на его исходники - особенно на то, как там для копирования одной строковой переменной PHP в другую используется 4 строки и постоянные вызовы malloc/free). Это все-таки перебор для языка, предназначенного для работы с текстом. Однако в настоящий момент Perl все еще несколько превосходит PHP по возможностям и по скорости интерпретации (про трансляцию в PHP точно не знаю, уже объяснял, почему я в ней вообще сомневаюсь). Так что, в общем-то, скрипты на Perl работают быстрее, чем на PHP, и могут быть гораздо большего размера.

Отдельный разговор про издержки CGI. Я уже говорил, что они в общем-то довольно невелики, и что чаще всего простота большой системы оказывается важнее, чем издержка на запуск CGI-скрипта (потому как время трансляции кода куда больше). Не нужно экономить на спичках, это - прямой путь к краху. Но есть альтернативный путь - впрочем, он тоже плох, но не по причине его исходной неверности.

Использовать mod_perl, действительно, не очень удобно - опять же, потому, что он очень коряво написан, но не потому, что у Perl неправильная идеология. Однако тот, кто первым создаст такой mod_perl, который бы решал все проблемы нынешнего (утечки памяти, которые, впрочем, кое-как лечатся путем установки MaxRequestPerChild - так, кажется? - а также довольно неудачную концепцию организации сохранения значение ВСЕХ пакетных переменных между запусками, которой, кстати, в PHP нет), тот заработает себе безбедное существование и проклятия Zend-овцев на ближайшие 5 лет (а может, и дальше).

Конечно, если к тому времени Микрософт всех не задавит (а его Windows 2000 вроде как на это вполне способен, но, опять же, я лично с этим не сталкивался). Я боюсь, как бы Basic из ASP не начал обходить по популярности PHP или Perl, потому что если с Apache будет покончено, то вряд ли Microsoft возьмется писать, например, Perl для работы на Windows-серверах (а ActivePerl, по-моему, работает в этой роли из рук вон плохо).

В конце - еще раз цель статьи: показать, что есть в мире люди, которые, все взвесив, решают отказаться от PHP в пользу Perl (хотя раньше они придерживались соверенно обратной точки зрения).

Вообще то не правильно говорить что какой либо язык программирования лучше чем другой. Каждый язык высокого уровня в свое время разрабатывался для решения определенных задач и есть как универсальные языки программирования (Basic, Pascal, C, Perl, C++) так и специализированных (Parallaxis, Prolog, ...). Так вот, на универсальных языках можно решить практически любую задачу, но с разной степенью сложности и дальнейшей работы программы, а специализированные только конкретные задачи или только для конкретных архитектур. Так Parallaxis - для многопроцессорных (SIMD) машин, Prolog - для решения задач при разработке систем искуственного интелекта, причем для этих задач лучше всего подходят именно специализированные языки.
Так о чем собственно я . . .
Кто такой программист - человек, способный решить поставленную задачу с помощью средств вычислительной техники, т.е. составить алгоритм решения задачи и внести его в машину в понятной ей форме. Понятная ей форма - это машинный код, на высоком уровне который формируют компиляторы различных языков.
Так вот, на Западе для повышения эффективности конечного решения задачи, принято разделять между людьми: аналитик - разработка алгоритма решения поставленной задачи; кодер - внесение уже разработанного алгоритма в ЭВМ. Этот самый кодер как правило должен знать несколько языков, и как раз он и решает (просматривая алгоритм разработанный аналитиком) какой язык ему в данном случае лучше всего (эффективнее) применить. Для данного алгоритма он применит один язык, для другого - соотв. другой (или этот же), но всякий раз тот, который в данном случае будет для данного алгоритма эффективнее.
Т.о. нужно правильно понять задачу, найти ее оптимальное решение в виде алгоритма, и проанализировав получившийся алгоритм - выбрать наиболее подходящий для данного конкретного алгоритма язык программирования и собственно запрограммировать.
Итого:
- учите языки программирования
- чщательно обдумывайте задачи и оптимально составляйте алгоритмы их решения
- из известных вам языков программирования выбирайте для конкретного алгоритма конкретный язык.

Сровершенно с вами согласен. Но сейчас речь идет о совершенно конкретных языкаэ - Perl и PHP, и о их одинаковом предназначении.

<p>Совершенно поддерживаю автора статьи. я как-то давно провел такой опыт: взял наипростейший пхп скриптец и гигантский под <b>200 кб</b> перловый скриптище. ну и локально их запустил. пхп4 пыжился, пыжился и по капле наконец выдавил из себя все что надо, а вот заметить как перл сработал я просто не успел. причем пхп скриптец был ну совсем простой, типа хэло ворлд. а перловый - вебинтерфейс к почте. и кстати весьма криво написанный. но работал мгновенно. причем, заметьте, я опыт проводил ненаучным способом, чисто визуально проверял. и вот вам результат: сложнейшая перловка в 20 раз быстрее наипростейшего пхп. </p>
<p>так что, г-да любители пхп, ваш язык может и прекрасен и легок с чисто абстрактной точки зрения, только вот проблема в том, что мы с вами пишем не для себя, а для простого пользователя, которому абсолютно наплевать, на чем тот или иной сайт построен, на пхп или на перле или вообще на jsp. для пользователя главное, чтоб удобно было и чтоб все летало. причем "летные качества" стоят на первом месте, потому что большинство все еще на дайлапе сидит, да и просто потому, что жизня сейчас такая сумасшедшая пошла, везде успеть хочется.<br>
и вот вам еще один пример: как-то раз я решил проверить, что за проигрыватель такой sonique. установил, смотрю скины поддерживаются. бегом на оффициальный сервер. а он как раз на пхп сделан. я просто задолбался ждать, когда он там из себя хоть что-нибудь выдавит. а сервер кстати и прога принадлежат lycos, и я не думаю, что у них там трешка древняя стоит. в результате и прога и сервер потеряли потенциального потребителя, клиента. потому, что я нашел любительский сайтик с большинством скинов, сделанный на обыкновенном хтмл, без прибамбасов. и все летало. а это главное.<br>
и это не единственный пример. все сайты на пхп дико тормозят</p>
<p>так что перл по главному критерию - скорости полета стоит на первом месте, и пхп до него еще очень далеко.</p>
<p>п.с. согласен с автором статьи, что линукс - полная лажа, и что майкрософт всегда будет рулить. вообще, на мой взгляд, большинство оупен сорс проектов полная лажа.</p>

To Eugene: Это же как надо умудриться скомпилить PHP4 что-бы он на "Хело ворд" тормозил... ой что то ты там не договариваешь. Там случаем небыло конструкции типа sleep(50) ? :)

А теперь собственно говоря вопрос как к автору статьи, так и к другим, кто сможет мне ответить.

1. Как перенести с пхп на перл следующее http://www.perl.ru/ubb/Forum7/HTML/000213.html - жду ответа уже неделю, все полчат.

2. Больше наверное к автору:
"Перенаправление ошибок в браузер - 100% как в PHP
500-я ошибка побеждена. Теперь все работает в точности так же, как в PHP"
Если можно ткнуть носом в ссылки по этому делу, либо дать примеры кода.

Вообщето Perl это не только скрипт для
написания CGI скриптов.

Есть много и других задач, где удобно
использовать Perl. Мне например при
написании меого проекта часто надо делать
одноразовые програмки, которые один раз запустив,
получив результат можно и забыть.
Делать такую на C++ слишком дорогое удовольствие,
пока напишешь, скомплируешь, отладишь, так и день
пройдет. А на Perl из командной строки ввел пару
команд, и все рабоатет !
Конечно это можно сделать и на других скриптах,
например на Pyton или awk, но уж никак не на PHP.

Поэтому мнение автора, что Perl умрет через
5 лет неверно. Он может умереть как язык для
нписания CGI-скриптов, да и то если бы он
использовался только для них. Perl выжывет за счет своей разннобразности в применении.

Еще насчет обявления его переменных с $ @ % &
В свое время меня это тоже раздражало, но потом
привык, и стало все ясно. Они как раз хорошо
помогают разбираться в коде. По этим
знакам ясно какой контекст используется, и
какой результат должен получится.

Насчет $ @ % и &. Я тоже к ним привык. Однако это не помешает мне заявить, что лично мне эти выкрутасы, если и не мешают, то довольно неприятны. И уж точно они не помогают ничему (хотя, как вы правильно заметили, после некоторой практики и не мешают).

Модули WebIn и WebOut лежат у меня:
http://www.dizain.ru/dklab/work/modules/
Рекомендую качать zip-архив, так как они там посвежее. Для установки просто скопируйте содержимое в site/lib на своем Perl.

Насчет поимке дисконнекта пользователя: протокол CGI этого вроде как определять не умеет (хотя я и не уверен). Однако можно попробовать исхитриться, используя тот факт, что, кажется, STDOUT скрипта Apache перенаправляет прямо в сокет соединения. Так что достаточно будет вызвать select (см. документацию) и определить, можно ли сейчас писать в STDOUT. Если нельзя (как об этом заявит select), значит, пользователь отсоединился. Еще раз повторяю, что я не знаю точно, будет это работать или нет.

Польностью согласен со Svist.
Сам постоянно пользуюсь одноразовыми программками! :))))

Perl изначально не был задуман как язык для Web , поэтому не вижу смысла сравнивать
примочки PHP для Web с Perl. Perl богачи PHP синтаксически и это плюс по моему мнению На мой взгляд Perl + JavaScript(client) могут пока могут реализовать любые не реализованные на Perl возможности для Web , которые присущи PHP .

PS:
Я не так давно занимаюсь Web программированием.

Я прочитал и удивился,как я понимаю здесь высказываются програмисты которые пишут буквально на всем :). Мне похвастаться особо не чем,так, пара скриптов на Перле.Но я не вооруженным взглядом вижу что некоторые простые вещи проще делать на ПХП чем на перле. И еще хотел бы добавить по поводу неудобства языка, так мне кажеться это сказка про танцора которому ..... .
Итак заключение надо знать языков чем больше тем лучше.(мнение эмигранта)

Типа все круто, но вот я тоже склоняюсь в сторону перла. Всё же он работает побыстрей если правильно написан чем пхп. Одна у него проблема что он тяжел для редизинга, но и это можно исправить выташив все исменяемые вещи в отдельные бланки (как я обычно и люблю делать :))), так что пхп может служить только для сообщений типа :"Добрый вечер, сегодня такое-то числоб стока-то времени" и мило подвисать :)

Детский сад, ясельная группа. Модули типа CGI.pm пишут те, кто только начинает делать себе рекламу. SSH -устойчивейшая и широко используемая программа. На Перле пишутся мегобайтные проекты, которые уверенно фурыкают на Terrax и K. Короче, учите Perl ребятишки.

Я хорошо знаю perl, но не работал с PHP. Недавно вот попробовал PHP+MySQL. Конечно, быстренько и удобно писать различные опросники, доски объявлений и т.д. Но я обратил внимание на то (и это значительный минус), что PHP кроме как web больше то и не понимает. Пробовал для крона что либо накатать, так и не понял, как это запускать. Пробовал для почты что либо накатать на php - тоже не запустишь. А бывает ещё много других задач, например обработать огромный текстовый массив...

Первое. В этом форуме речь как раз и идет об использовании PHP и Perl для Web-программирования.

Второе. PHP как раз и планировался для использования в Web-приложениях. В то же время, его можно применять и в обычных, не-Web программах - в частности, для обработки текста. Достаточно запустить:
% php -q имя_скрипта.php

Третье. Предлагаю проверить Ваше знание Perl - особенно после заявления о детском саде, уж Вы не обижайтесь. Никто не возражает?

Итак, что неверно в следующем коде (см.ниже).
Как путем шести-семи нажатий на буквенные (!) клавиши исправить его, чтобы он был корректен?

sub Проверка
{
my ($а,$б)=@_;
sub ПроверкаАиБ
{
my ($н)=@_;
print "($а)"x$н . " - " . "($б)"x$н;
}
if($а<$б) { ПроверкаАиБ(); }
}

Разумеется, руссие буквы в названиях здесь заданы только для смеха. Считайте, что Perl их понимает (кстати, PHP4 - действительно понимает).

Хватит спорить, эти споры ни к чему не приводят. пару лет назад были споры между писюками и маками. и что? мак конечно прекрасен, божественен, но...

тут вот про coldfusion никто ничего не сказал.

Дискуссия весьма поучительна... хм...

Но напоминает жаркие баталии "желтых" и "синих" (кто не в курсе -- либералов и консерваторов) из "Пиквикского клуба" :)

ИМХО: языки сравнивать нечего -- объективно, Перл не удовлетворяет ни одному критерию семантически надежного языка (не буду распространяться на эту тему? это и контекстная зависимость и путаница с областями действия переменных -- получится очень-очень длинно). Пхп -- некоторым удовлетворяет :) Т. е. перл ПРОВОЦИРУЕТ ошибки, вместо того, чтобы ПРЕДОХРАНЯТЬ от них, ну, хоть как-то. Это довольно важная вещь, когда вы разрабатываете софт "на конвейре" в промышленных что ли масштабах (не надо смеяться :). Программы на перле легко писать (что и я делаю, когда нужен Q&D скрипт для обработки чего-нибудь... не для www), но ПРАКТИЧЕСКИ НЕВОЗМОЖНО поддерживать, т. е. модифицировать и развивать -- ну, обратите же внимание на ОБЩУЮ ругань по поводу перловых библиотек (CGI.pm, напр.), ведь это следствие и очень ясный показатель :) Причина -- в том... ох, не буду говорить в чем, чтобы не взвились все юниксоиды разом :) думаю, они и сами это знают. В пхпшных библиотеках дело обстоит все же чуть лучше (а честно говоря -- намного лучше) -- не наводит на размышления?

Что касается rutime: ежели перенести любую программу с одного произвольного языка на произвольный же другой -- в 9 случаях из 10 получите результат, который вас, скажем, не удовлетворит. Один и тот же алгоритм может быть реализован оптимально, или нет -- это зависит от опыта программиста, его отвественности, сколько у него было времени и сколько ему заплатили. И зависимость эта -- ох, слонжа... Поэтому приводить в качестве аргумента наблюдение, что какой-то сайт тормозит, ИМХО, не совсем корректно -- тормозных перловых сайтов тоже хватает.

Мне кажется, что на сегодняшний день никакого резона переходить туда-сюда нет ни малейшего ПРАКТИЧЕСКОГО смысла, хотя эстетически интересно, в свободное время, мне нравится. (Женщины говорят, что кое-что менять -- только время терять) Подавляющее большинство задач решаются примерно одинаково эффективно, если рассматривать не как штучное изделие, а как промышленный продукт -- все же искусством для искусства увлекаться при нашей жизни как-то не приходится. Качество исходных текстов (С) как перла, так и пхп примерно равное и отнюдь не такое плохое... хотя могло бы быть и получше... Пхп существует и как командный интерпретатор -- ну, итд, итп.

Короче, предлагаю пожать друг другу руки и, может, даже, пива выпить... :)

Кхм... Предложу свою точку зрения. Когда я десять лет назад начал заниматься asm, мне орали - брось его - займись бейсиком. Я изучил asm и взялся за бейсик. Затем, мне орали - брось бейсик - изучай паскаль. Я изучил бейсик, взялся за паскаль. Так продолжалось по цепочке - asm-basic-pascal-c-c++-perl. Ну, были еще мельком js,asp, и прочие, но не долго. Сейчас все орут - бросай бодягу perl, изучай php.

Я сел за пару дней изучил в основе Php (сами понимаете - после 4 лет Perl - php изучить не трудно). Не скажу, что я его знаю супер, но...

Pascal великолепно справлялся в то время с ДОС-программами, но попробуйте на нем написать 3d программулину.... Когда нужно быстродействие, но скорость написание не очень важна - берите asm и пишите 3d и т.п. Так вот,...

Перл действительно помогает решать средние и крупные задачки по обработке текстов и CGI. Кроме того он ОЧЕНЬ быстродейственный по сравнению с php. Он более формализован и ГИБОК по сравнению с php (см. CPAN - тысячи модулей УЖЕ ГОТОВЫХ И ОТЛАЖЕННЫХ, вплоть до обработки кредиток, графики, морфологии языков и пр.). PHP очень удобен при разработке - написать на нем что-то дело минут (на perl более-менее солидный сайт пишется несколько часов). Но ВСЕ, ЧТО ПОЗВОЛЯЕТ ЧТО-ТО НАПИСАТЬ С МИНИМАЛЬНЫМИ ПРОГРАММИСТСКИМИ НАВЫКАМИ НЕ МОЖЕТ претендовать на БЫСТРОДЕЙСТВИЕ.
Если интересно - почему так - на эту тему целую статью можно написать.

Поэтому я сделал вывод, что если нужна скорость разработки - надо использовать php, если мощь и гибкость - perl. Хотя "скорость разработки" у php применима только к web.

К тому же, php просто практически не позволяет делать obfuscated code, насколько я знаю. А в perl для этого - полное раздолье.

Забыл сказать. Что уж тут говорить про быстродействие, когда я считаю, что MySQL (и ижеподобные) - жутко тормозная вещь.

насчет того, что скл - вещь тормозная, полностью согласен.
насчет распития пива и более крепких напитков - где и когда?

последняя мессага была моей - немного не понял здешнюю фишку про анонимность. пиво предлагаю пить в ирландском пабе, что на тверской. там гиннесс просто великолепный.

ндя... ну, народ, и кто что кому доказал?!
много было высказано мнений, причем большинство - сторонниками перла. ну, не важно, речь не об этом... мое дело - сторона. никаких объективных доказательств преимущества того или иного языка так и не было высказано. так ничего и не продемонстрировали, как я и предполагал... да, пхп заточен под веб, перл изначально создавался для другого (и для других). но название данной статьи все же... эээ... немного эксцентричное такое... кричащее, что ли... на самом деле, автор не перешел на перл, если продолжает читать курсы по пхп ;)) так что, не соответствует действительности... ох, не соответствует... ;)) а если никто никуда не перешел и переходить не собирается - чего спорить-то? правда, это все больше напоминает дискуссии типа "вынь vs. линух", "мак vs. писи", "ie vs. nn" ну так ведь, да?
ну да ладно... хоть договорились (почти) где пива попить ;)) эх, жаль, не буду я у вас в обозримом будущем...
з.ы. в статье, как я и писал уже не хватает _примеров_, и не таких что "писал одно и то же, в одном случае упало, в другом случае - как проклятое пашет" или в том же духе. вы же не забывайте, что не всегда главное - выжать из компутера наносекунды, а с максимальной эффективностью и минимальными потерями времени решить задачу. нет, не следует это понимать так, что быстрее написать и быстрее получить деньги, вовсе нет... да и вопрос о скорости перла и пхп - спорный. как я писал, есть куча обзоров по данному поводу. и никто не может прийти к решающему выводу. все выводы носят рекомендательный характер и лейтмотив везде один. ну, об этом я писал в предыдущем постинге, не буду повторяться.

Лично мне под PHP3 работать крайне неприятно. PHP4 уже похоже на язык с
нормальными возможностями, там даже (!) появились функции типа array_pop и
array_shift (как сделать shift в PHP3, я так и не нашел в принципе), но глюков
там очень даже есть.

Во-первых, слишком много приходиться кодировать в лоб, например, писать явные
циклы for () {} там, где в Perl'е просто сделал бы map или grep.

Во-вторых, в PHP нет массивов. По сути массивы в PHP - это те же хэши, но с
числами-ключами. Крайне неприятно, что pg_fetch_array возвращает фактически
удвоенный хэш, где ключами служат И номера полей, И их значения.

В-третьих, в PHP просто невозможное количество функций на каждый чих, и без
справочника в соседнем окошке, к которому обращаешься каждые пять минут, писать
у меня не получается. Поди вспомни, какой sort тебе нужен на этой строчке:
uksort, uasort, ksort, asort, arsort или еще что.

В-четвертых, при таком количестве функций естественно, что часто это работает не
так, как ты думаешь, и даже не так, как написано в мануале. Классический пример
- когда-то в одной из версий min() возвращал максимум, а max() - минимум. Выход
новой версии - "примите у товарища брак и выдайте ему новый". В каждом
нетривиальном случае надо читать комментарии пользователей к функциям в
_онлайновом_ руководстве на php.net.

В-пятых, надоедает избыточное кодирование, буквопечатание и лишние, казалось бы,
проверки типа

if ( !( file_exists("$DOCUMENT_ROOT/$mustbe") and
is_file("$DOCUMENT_ROOT/$mustbe") ) ) {}

``It seems that is_file doesn't return true for a file that is 0 bytes... ''

В Perl это было бы просто

unless (-f "$DOCUMENT_ROOT/$mustbe" ) {}


В общем, каждый раз, когда с PHP есть возможность вернуться к Perl'у, я это
делаю.

Автор, который где то там зарабатывает чтением лекций никогда не скажет, что в перле вывод HTML осуществляется только так:

print "Content-type: text/htmlnn";
print "<html><body>n";
print "<h1>Hello!</h1>nHere is the numbers: ";
for(my $i=0; $i<10; $i++) { print $i; }
print "</body></html>";


На самом деле я поклонник Perl, а вышеупомянутую операцию можно с лекгостью прописать так:

print <<PPN;
Content-type: text/html\n\n
<html><body>\n
<h1>Hello!</h1>nHere is the numbers:
PRN
for(my $i=0; $i<10; $i++) { print $i; }
print <<END;
</body></html>
END

Естественно, строк между
print <<DESCRIPTOR;
DESCRIPTOR
может быть ГОРАЗДО больше.

А насчет быстродействия... Да Перл действительно работает гораздо быстрее. Но нельзя говорить, что PHP не имеет права на жизнь. PHP, как правильно кто то заметил выше - это язык, который не требует специальной подготовки. В этом беда Российского интернета, в сети так много информации и готовых скриптов, что господа Василии Пупкины, начитавшись книжек и скачав 2-3 скрипта начинают в неимоверном колличестве создавать так называемые WEB-studio, напрочь забывая, что каждому делу нужно учиться.

Блин, а че это он примеры кодов не прописал???

> Если автор данной статьи напишет о ценах, то автор этого сообщения скажет,
> что у него цены на тоже самое раз в 10-20 дешевле.
Дешевле - не значит лучше.

Насчет print < < маркер: это решение чуть лучше, чем куча print-ов, но все равно никуда не годится. Уважаемый Анонимус, а вы когда-нибудь слышали что-нибудь про трехуровневую идеологию проектирования скриптов в Web? Про отделение кода от дизайна и дизайна от шаблона страницы? Про интерфейсы шаблонов? Наверное, вы создаете и дизайн и код своих скриптов единолично (вот и цен-то у вас в 10 раз ниже), но мы не можем себе такого позволить - получается слишком долго и, главное, крайне некачественно. Нельзя ведь быть копенгагеном сразу и в дизайне, и в программировании. Вы вообще когда-нибудь слышали, чтобы хороший программер был также и неплохим дизайнером? Или чтобы классному дизайнеру не была противна сама мысль о программировании?

Насчет указанного выше примера - так он так записывается:

if(!@is_file("$DOCUMENT_ROOT/$mustbe"))
echo "File exists and it is file.";

Всего чуть-чуть длиннее, но зато гораздо более строго. Это ПЛЮС PHP, а не его минус.

А насчет отсутствия массивов - тоже неправда. Это же хорошо, что все массивы - одновременно и хэши, это гораздо более универсально, чем в Perl. И это тоже плюс PHP, а не минус. К тому же, в PHP хэши НАПРАВЛЕННЫЕ, а в Perl - нет, что часто порождает массу неудобств в Perl.

Да, Perl более пригоден для серьезного профессионального программирования, чем PHP - по крайней мере, пока. Но вы умудряетесь выдавать достоинства PHP за его недостатки (коих у него и так достаточно). Это просто уму непостижимо!

давайте пить пиво.

2Автор:

<flame>
Что такое шаблоны и отделение дизайна от кода, я придумал года четыре назад, еще когда не знал про HTML::Template, Text::Template, Template Toolkit и т.п. :-)

Программистов, у которых есть И художественный вкус, я встречал и встречаю постоянно, особенно среди Web-программистов. Если Автор к таковым не относится и таковых не встречал - это проблемы автора.
</flame>


>if(!@is_file("$DOCUMENT_ROOT/$mustbe"))
>echo "File exists and it is file.";
>
>Всего чуть-чуть длиннее, но зато гораздо более >строго. Это ПЛЮС PHP, а не его минус.

Чем это "гораздо более строго", нежели

unless (-f "$DOCUMENT_ROOT/$mustbe") ? Или, по вкусу, if (! -f "$DOCUMENT_ROOT/$mustbe") ?


В чем радость того, что в PHP массивы - это на самом деле хэши, я так и не понял, особенно когда так и не придумал, как сделать shift массива в PHP3 (хостинг был такой). Не перебирать же в лоб циклом весь массив и не переопределять его элементы, в самом деле. unset первого элемента не катит, так как в PHP массив - это хэш.

Еще меньше радости, когда sql_fetch_array возвращает результат - удвоенный хэш, с ключами И числами, И названиями столбцов. Если заранее не знаешь имена столбцов, ничего полезного с этим результатом без извращений не сделать.

В общем, когда я вынужден кодировать на PHP, я впадаю в депрессию. В этом плане радость Автора, "открывшего для себя" Perl, мне очень даже понятна.

В общем, очередной флейм на эту тему даже скучно как-то поддерживать. Хочу лишь наиболее грамотным программистам на PHP попробовать Perl.

Ну вы блин ребята и даете,кто умнее да кто код лучше напишет,а вот вы бы лучше написали у меня такая страничка и на ней есть то то и то и ходит туда народу столько то, и помог я сделать странички такие то. Вот бы нос утерли друг другу.А то пишите тут кто лучше знает,а кто хуже.А я вот на пару простых вопросов пока нашел кто поможет так чуть не умер.И еще есть такой хороший лозунг "Учить не учиться,много знать не надо"

Направленность ассоциативных массивов есть определенный порядок следования пар ключ-значение в них. То есть, перебирая массив, мы будем получать эти пары в том же порядке, в котором они заносились.

Насчет HTML::Template: уважаемый, может, вы еще и лебедевский Perser пововетуете? ;-)))
Ха-ха! ;-)

Насчет строгости: -f - это минус, а дальше - буква f. То есть, если мы напишем
$a=-f "aaa.txt";

и у нас существует константа f:
sub f { 10 }

то что получится в $a - результат проверки на существование файла "aaa.txt" или же результат вызова f("aaa.txt") с обратным знаком - то есть -10? Вот это я и называю нестрогостью, собственно. Ни больше, ни меньше. Теперь вопрос: а описан ли этот пример (кстати, один из самых простых) в документации Perl и что там о нем сказано?

Ну а насчет программиста-дизайнера в одном флаконе - небольшое отступление: что получится, если смешать бочку дерьма и бочку меда? Правильно - две бочки дерьма! А теперь попробуйте ответить по аналогии на вопрос: что получится, если бочку дерьма смешать даже с девятью бочками меда?.. А со ста бочками?..

Прочто творчество ПРОГРАММИСТА - это тоже своего рода искусство, но оно почти противоположно искусству дизайнера. Если чловек занимается двумя делами сразу, имея только одну профессию, он неизбежно производит на свет халтуру. На эту тему написано даже больше, чем вы можете себе представить. А насчет сочувствия... Это ваше дело, кому сочувствовать. Наверное, вы очень чувствительный человек, потому что в мире есть гораздо больше вещей, которым нужно сочувствовать. Посмотрите, например, какие примеры скриптов приводят на сайте Всероссийского клуба вебмастеров (да не в обиду будет сказано автору этих примеров!) - где тут, простите, отделение кода от дизайна - ну хоть чуть-чуть???
http://www.webclub.ru/content/programming_perl/article-595.html

А известно ли автору, что основой для разработки PHP служил PERL? Это, кстати, в спецификации ПХП3 в самом начале, кажется, и написано...
Это к самой статье..

По поводу sub f {10}

выражение $a=-f "aaa.txt"; ни в коем случае не вернет "-10".. $a=-&f; - другое дело..
Еще хочу заметить, что $a=-f "aaa.txt"; само по себе не верно, как вызов функции, определенной пользователем.. Параметр, вообще-то, должен быть заключен в скобки.

При чем же тут нестрогость, понять мне, видимо, не дано.. Поясните, будте добры

Best Regards

Ну что же, по полочкам. Вот скрипт a.pl:

#!perl -w
sub f { 10 }
print -f "a.pl";

А вот другой, отличающийся от него одним пробелом:

#!perl -w
sub f { 10 }
print - f "a.pl";

Первый выводит 1, а второй - 10. Это-то я и имел в виду.

Что вкуснее - курица или апельсин? Некорректное сравнение.

Если мне нужно написать веб-шоп или другой сайт с тяжелым динамическим контентом, я использую PHP - удобно. Удобно, если заказчик не может себе позволить co-location. Научился выводить тэги так, что дизайнеры, сидящие в Dreamweaver довольны и HTML-validator не ругается.

Если же мне нужна "одноразовая" программка, вызовы shell, демон, работа с деревьями и списками или чужие наработки ( модули ), то я использую perl.

Итак, PHP - легко встраиваемый в HTML и простой в освоении язык для генерации HTML.

А на perl мы решаем все остальные задачи.

Автор:
Если душе хочется универсальности, то очень быстро отказываешься от того, чтобы выводить страницы при помощи скриптов через оператор print. Например, так:

print "Content-type: text/htmlnn";
print "<html><body>n";
print "<h1>Hello!</h1>nHere is the numbers: ";
for(my $i=0; $i<10; $i++) { print $i; }
print "</body></html>";
==========================================
Согласен, но можно использовать следующую конструкцию:
#
<<HTML;
<p>Чистый HTML-текст<p>
HTML
#

Эта проблема решается только вмешательством в код Apache, причем самым что ни на есть нетривиальным образом. Я имею в виду, что не получится написать модуль для Apache, нужно править само ядро, причем в 10 местах.

Правда, в результате этой деятельности Apache всегда запускается под пользователем root - разумеется, переключаясь на нужного пользователя сразу после получения запроса ;-) Это может поначалу испугать, но на самом деле не все так страшно: в предположении, что код Apache написан без существенных ошибок, это не порождает дополнительных дыр в защите.

Боюсь, что это - единственный способ решения проблемы.

Интересующимся я могу выслать исходники с отмеченными местами, которые я правил: dk@dklab.ru

Apache и так запускается под рутом (иначе, как может работать suexec :)
Или имеется ввиду, что каждая копия апача работает под рутом?

Я буду очень благодарен, если Вы вышлите мне эти исходиники или напишете, как их получить.

Заранее благодарен,
Антон
(чуть Выше был вопрос мой)

Каждая копия Apache до того, как она получит запрос, работает под рутом. Он переключается в режим обычного пользователя после того, как все заголовки запроса обработаны и выяснено, какому виртуальному хосту предназначен запрос.

Так где же посмотреть на эти правки?

Буду еще более благодарен за ответ.
Антон.

Я же выслал их Вам по почте... Пишите мне: dk@dizain.ru - пошлю еще раз.

А мне и под ASP неплохо живется.. Сейчас все начнут кричать про Кривость микрософт и все такое, но.. Сходите на terraserver.microsoft.com и пусть кто-нить попробует сказать что он работает криво или медленно.. Там 7Тб информации и функционирует все это хозяйство уже 4 года без единого ребута.
Регардс.

Тут никто ничего не сказал про графику. Насколько я знаю, сгенерить картинку под php проще, нежели под перлом...
Да и никто не мешает использовать php и perl в одном проекте одновременно. Плюс все сходятся на том, что с php4 лучше и веселее, а некоторые просто утыкались в проблему и, не зная решения средствами одного языка, решали ее с помощью другого.
Если проблема в быстродействии, а сервера сейчас стоят под PIII-800, а будут под 1,7 и разница в быстродействии будет выражаться в милисекундах, если не меньше, так что стоит ли из-за этого городить лес? Никто же не плачется, что раньше программы на ZX Spectrum использовали 48 кб оперативной памяти на все про все, включая интерфейс. Просто языки следующих уровней всегда медленнее своих предшественников, но зато проще, на этом опять же сошлись. Да и использование связки php&mySQL - плюс. Без СУБД мы ни туды, и не сюды. Хотя perl тоже работает с СУБД через модули (интересно, кто-нибудь сравнивал здесь эффективность?)

Кстати? вопрос. Код длиною более 50 кб - это зачем? Что в нем писать? Если это перл - а CPAN зачем? Или же это общая масса всех используемых скриптов? Или же просто алгоритмика не применяется?

50 Кб - это очень небольшая новостная система на PHP (более-менее нормальная - 120 Кб). Насчет MySQL - думаю, PHP работает с ней в среднем быстрее, чем Perl, однако при обработке больших результатов последний обгоняет PHP. Проигрыш Perl - корявость и медлительность модулей с CPAN.

А что насчет вообще проблемы быстродействия - конечно, если машина выделена для обслуживания одного-единственного сайта, то быстродействие будет на высоте независимо от языка программирования. Но вот если (как это почти всегда бывает) на компьютере сотни (если не тысячи) виртуальных хостов - вот тогда-то все и начинает тормозить.

Вы 4 месяца обсуждаете эту статью! Может пора выводы сделать?

про sql_fetch_array - вы про параметры функции почитайте!
там много что интересного по поводу возвращаемого массива написано и как управлять содержимым этого массива!

Знание - сила ! Спасибо за пояснения автору!
Раз существуют и PERL и PHP, знать в этом
есть необходимость. У каждого язывка - своя область применения, а знание их плюсов и минусов лишним не будет.

> Интересно почему во всех примерах в книгах по пхп (когда хотят показать какой плохой перл) приводят пример

print \"Content-type: text/html\\n\\n\";
print \"<html><body>\\n\";
print \"<h1>Hello!</h1>nHere is the numbers: \";
for(my $i=0; $i<10; $i++) { print $i; }
print \"</body></html>\";

если намного удобнее написать так

print \'
<html><body>
<h1>Hello!</h1>\\nHere is the numbers: \';
foreach (0..9) {print}
print \'</body></html>\';

или вообще в одну строку

print \"\\n<html><body>\\n<h1>Hello!</h1>\\nHere is the numbers: \",(0..9),\"</body></html>\";

> на счет форм (конечно, в PHP это удобнее реализовано, но как обрабатывать нестандартные запросы? Например, script.pl?name, или такой news/26aug2001, в котором news не папка, а скрипт news.pl и реальное расположение файлов на диске может быть вообще вне публичных папок). В перле еще в начале парсинга формы можно, обнаружив ошибку, просто вывести ошибку и обрабатывать всю форму, а в ПХП?

> И еще на счет редизайна (легкости изменения дизайна), я не так давно отрыкрыл свой сервер гостевых книг (zbookpro.net о нем тут тоже есть статейка), так вот одно из главных его достоинств, то что можно полностью изменять дизайн книг (при всем при этом сам контент книг, как понимаете тоже постоянно изменяется)

Выдача страницы выглядит примерно так

# Выборка нужных сообщений, чтение дизайна и настроек конкретной книги
# Создание переменных шаблона, типа, $VAR{UserName}=\"Имя юзера\" и
# подстановка этих переменных в шаблон
# [UserName] заменяется на значение $VAR{UserName}
# расположение переменных в теле шаблона, а также наличие переменной,
# или её отсутствие заранее не известно. Переменных десятка 3
# $template - строка в которой хранится шаблон

$template=~s/\\[(\\w+)\\]/$VAR{$1}/gs;
# эта строка полностью создает нужную страничку

По моему более гибкой настроки дизайна быть не может, при этом он редактируется из броузера. Пробовал подобное на ПХП, даже одну переменную он заменял в 10 раз дольше, чем перл десяток. К тому же сделать в ПХП, чтобы одной строкой можно было заменить все переменные у меня не получилось

P.S. ПО webscript.ru для ответов на статьи тоже вроде на ПХП, в связи с эти вопрос, внизу страницы надпись Сгенерировано за: 52.96... (что эта страничка почти минуту создавалась?)

Ну конкретно эта страница долго генерируется. Но у меня за 15 сек. не вылазит

Здесь очень много написано "Perl намного быстрее PHP".
Хорошо...
Где примеры скриптов с подробным описанием конфигурации ОС, PHP, Perl и так далее?..
Чем обусловлены эти выводы?
Кто проводил тестирование?
Или просто "музыка навеяла"?

Кстати, сайт автора ( http://www.dklab.ru/ ) - Артемий Лебедев, наверное, в восторге...
столько его идей и все в одном месте...

1. Пример скрипта я уже приводил - это хотя бы пустой цикл (либо цикл, в котором проводятся какие-нибудь математические вычисления). Кроме того, Perl транслирует 120К кода меньше чем за секунду, а PHP - за секунды 4-5 на P600 (правда, это я о PHP3, о четвертом не знаю, не проверял пока). А насчет музыки - да, навеяла музыка журчащего винчестера, который записывал своп.

2. А идеями умного человека не грех и воспользоваться. На этом, собственно, и держится наша цивилизация - на опыте и идеях других людей. Впрочем, я рад, что Вы ко мне зашли. Если хотите, приглашу Вас на свои будущие курсы PHP4 в Учебном Центре Артемия Лебедева. ;-)

To DmitryM: PHP работает быстрее перла в простых скриптах, типа Hello world! и т.п. на которых проводят большинство тестирований, но стоит скрипт усложнить так ПХП начинает все больше тормозить. Я лично тестировал производительность ПХП и Perl для своих целей (мне лично всеравно было на чем писать, лишь бы быстрее работало, хотя Perl я значительно лучше знаю) Так мне нужен был скрипт, который создает страницы из шаблона, скрипт в принципе простейший, на перле всего 9 строчек (на PHP у меня получилось 18), шаблон был 18 КБ примерно, так вот при тестировании прогой WebStress, PHP работал в 10 раз медленнее перла, причем он заменял только одну переменную в шаблоне, а перл десяток. Я даже сам такого не ожидал, 5 раз проверил, результаты были одинаковы (хотя при шаблоне размером 100 байт PHP работал в 2,5 раза быстрее). Могу предоставить скрипты для тестирования, если кто хочет убедиться. И это действительно реальный пример скрипта, а не что-то надуманное

по-моему, вскоре всем web-программистам (именно web и только) по любому придется перейти на asp, сколько бы ни спорили про перл и пхп, потому как в то время как вы спорите практически ни о чем (для мелочи - пхп, для serious - perl) гейтс переведет всю сеть на свой язык и будет смеяться над вами, несмотря на то, что его asp не надежен и т.д. и т.п.

а лично автора я благодарю. он помог мне разобраться со многими вещами (apache, perl, установка и обслуживание). спасибо.

кстати, к вопросу о разных пользователях и виртуальных серверах. что мешает каждому выделить по собственному апачу?

Если пользователей 500 штук, это весьма накладно и сильно снижает производительность. Кроме того, чтобы добиться максимальной хффективности, в памяти должны все время "висеть" несколько "готовых к бою" Апачей. Если давать каждому по постоянно висящему Апачу, да еще плюс по парочке "всегда готовых", получится 1000-1500 процессов.

ну вы тут замутили дисскусию. молодцы! Автору спасибо! Я сам человек начинающий в пшп но в перле немного поработал. На мой взгляд перл лучше. А вот на счет Гейтса Я не согласен. Не сможет он даже со всеми своими деньгами перевести всех на ASP
Все таки надо использовать и то и то.

И в натуре даже эта страница тормозит дико ...... ;-(

> #!perl -w
> sub f { 10 }
> print - f "a.pl"

potomu chto NETU FUNKCII "- f", a est toka -X
perldoc -f -X
...
takoe lamerskoe zayavlenie ne delaet chesti 'Avtoru'.
iz vsego threada mozhno sdelat' vivod, chto 'Avtor' silen toka v phpX, a s perlom imel toka poverhnostnie kontakti, libo sil'no ne uglublyalsya v nego...

esli est' kommentarii - u are welcome (alchie@td-clan.org)

ПХП я совсем не знаю, программирую под веб на перл

Так вот продолжение :)...
Из написанного выше я вынес для себя следующее: АВТОР несколько не компетентен в области знания языка программирования Перл (мягко сказано ;), ничего личного), насчет корявости перла тоже хочу сказать - если руки такие то уже ничего не поможет ;)... насчет ООП - все можно в перл и довольно сносно, но для меня это несколько не то (раньше программировал на с++). Меня Перл удовлетворяет поностью, не знаю где вы там нашли сложности с $ @ % все там ясно если немного разобраться. Ничего против пхп я говорить пока не буду, кроме того что почти каждый день по почте (рассылка securityfocus) получаю извещения по поводу новых дыр в пхп :).

А вот и я, дорогая редакция. И сразу хочу сообщить о сенсации. Наш уважаемый alchie, вемирно известный специалист в области Perl-разработок (кто не знает - пусть наберет его имя хотя бы в Яндексе), сел в лужу. Да-да, это потрясающе, согласен!

Наверное, это произошло с тех самых пор, как он установил себе Windows 98 и не смог найти, как там установить русскую раскладку клавиатуры. А потому он пишет транслитом. Но это довольно естественно: сейчас весь цивилизованный программистский мир предпочитает русскому языку транслит, т.к. он наиболее хорошо переносим между операционными системами. Транслит - это признак профессионализма, и, честно говоря, я никогда не мог научиться читать на нем так же бегло, как делаю это на русском языке, в отличие от знаменитых программистских авторитетов, таких как Строс Бьернтруп или даже незабвенный Кнут. Как говорится, не боги горшки обжигают, а поcему продолжаю.

Наверное, в свое время в средней школе дорогой товарищ alchie решал такое уравнение:
2 + X = 4
Скорее всего (хотя я, право, никак не могу быть в этом уверен) учительница объясняла ему, что для того, чтобы удовлетворить равенству, нужно представить, что в уравнении в действительности стоит не буква X, а то значение, которое оно заменяет. При помощи компьютерных технологий, которые применил уважаемый alchie (об этом речь ниже) можно также определить, какое же значение соответствует X в данном случае. Можно утверждать, что если вместо X подставить 2, то равенство будет выполнено:
2 + 2 = 4
Это, наверное, вряд ли вызовет у alchie сомнения, особенно после того, как я все так подробно разъяснил (во всяком случае, я надеюсь на это).

Итак, теперь поговорим о том, какие же компьютерные технологии применил alchie для того, чтобы привести уважаемым читателям этого форума свой разгромный пример. Для этого он установил у себя Perl (наверное, кто-то ему помог, потому что специалисты из службы технической поддержки Microsoft, с которыми я связался за разъяснениями, заверили меня, что установить Perl сложнее, чем русскую раскладку клавиатуры). Далее автор заметки набрал следующую историческую строку:

perldoc -f -X

которую ему посоветовал один знакомый хакер. И он увидел там такой текст:
-X EXPR:
A file test, where X is one of the letters listed below. ... The operator may be any of:
-r File is readable by effective uid/gid.
...
-f File is a plain file.

Так как все настоящие профессиональные программисты не знают английского и, как я уже упоминал, пишут транслитом, алкающий глаз alchie смог разглядеть лишь первую строчку: "-X EXPR". Но он не вспомнил, чему его учили в начальной школе насчет коварства буковки X, которая в реальной жизни может принимать самые немыслимые значения! Он также не подумал о том, что автор статьи наверняка протестировал оба варианта с "-f" слитно и "- f" раздельно. И он даже не догадался, что -f в Perl - это вовсе не функция, а оператор, потому как нельзя стандартными средствами создать функции с такими извратными именами.

В общем, все видели то, что произошло. Земляне скорбят, поверьте, скорбят по той луже, которую расплескал севший в нее alchie.

P.S.
Сразу прошу прощения за то, что весь приведенный в этой заметке текст является на 99% обыкновенным флеймом. Дело в том, что БЕЗ моей заметки комментарии alchie молги вызвать улыбку разве что у программиста на Perl, пусть даже и только-только начинающего. Возможно, у кого-то они могли вызвать и смех, как это произошло со мной. Теперь, я надеюсь, даже бабушка-пенсионерка, прочитавшая распечатку нашего "диалога", захохочет во весь свой старческий рот. Именно эту цель я преследовал - сделать кислоту первоначально высказанного не мной флейма чуть слаще даже для тех, кто совершенно не знаком с программированием. Надеюсь, мне это удалось.

Воспрнимать это все на личный счет или не воспринимать - дело alchie. В любом случае, надеюсь, он получил хороший урок о том, что каждый мужчина должен отвечать за свои слова, если не перед кем-то из людей, так хотя бы перед богом (если он есть, конечно). Иных целей я не преследовал и не хотел никого обидеть.

P.P.S.
Специально для alchie и Paradox (если только это не одно и то же лицо, которое вот таким интересным образом раздвояется) даю ссылку:
http://www.dklab.ru/chicken

Да, кстати: так называемые "дыры" в PHP, хотя и обнаруживаются, но это НЕ дыры в безопасности. А следовательно, это все мелочи, и рано или поздно большинство ошибок будет исправлено.

Другое дело - дыры в КОНЦЕПЦИИ, как это имеет место в Perl. Я не хочу сказать, что Perl плохой язык, многие программы очень даже хорошо на нем писать - быстро и коротко. Но не удобно.

1.ne hotelos' bi perehodit' na lichnosti...
esli ya kak-to zadel lichnoe samolubie avtora - i'm sorry...
2./me uzaet normal'nuju OS - FreeBSD. i to chto ya pishu translitom - znachit toka to, chto mne v lom prikruchivat' kirillicu k linux-netscape-4.78.
3.v kakom iz nine suschestvuyuschih yazikov mozhno sdelat' operator s probelom v imeni????
4.plz... davaite otstavim flame v storonu? ya prosto sdelal zamechanie.
5.php sucks hotyabi potomu, chto tam >1500 funkcii protiv ~250 v perle... a tak nazivaemaya "koryavost'" perla - eto nichto inoe kak svoboda syntax'a...

АВТОР!!! Насчет того что Alchie и Paradox это одно лицо ты не прав абслютно... мы разные люди с разными концепциями и подходами к программированию, хотя оба в данный момент программируем под веб на Перл, стоит заметить что ни как не на так ВАМИ "уважаемый" АВТОР любимой винде, что ВЫ даже связались со службой поддержки мелкософта, что бы проконсультироваться :) как это там перл на виды поставить :)))... мдаааа большому кораблю, большое плавание, если установка какого-то программного продукта под мелкософт вызывает у ВАС такие затруднения, то очевидно, что и разобраться в ПЕРЛ вам ну ни ка не под силу ;)))) (учтите что не я начал флэйм).
Насчет того что ПЕРЛ неудобный язык программирования и сложен в понимании хочу спросить у АВТОРА, вы еще на каком-нибудь языке программирования кроме пхп пишите (ну или бейсика, это же любимое ваяние мелкософта). Для меня перл не показался таким сложным и замысловатым после хоть мало-мальски прочтенного мануала... Я вот прямо сейчас возьмусь за изучение пхп, не думаю что для этого мне понадобятся долгие месяцы, пары часов вникнуть в концепцию и узнать как там чего делается :)... И после написания пары скриптов выскажу свое субъективное мнение (я думаю что именно так и поступил наш "уважаемый" АВТОР)

continue...
esli avtoru hochetsya strogosti sintaksisa - uzaite pascal...
a mne nravitsya, chto mozno zalepit':

print foreach (@array[15..$#array]);

vmesto nudnogo, no bolee ponyatnogo:

for ($j = 15; $j <= $#array; $j++) {
print $array[$j];
}

(((:

Ну сижу изучаю значит ентот пхп... и возник у меня вопрос: чего это интересно нельзя сделать средствами перл, а пхп можно???
согласен с тем что пхп простой в использовании и написании, но и с перлом у меня не было никаких заморочек...
на данный момент мне понравилось только задание класса прямо как в С++, других преимуществ пока не вижу. А вот где это АВТОР увидел в пхп синтаксис написания программы дружественный дезигнеру пока не могу понять, если основываться только на том, что все это прописывается в самой хтмлке, то это еще не доказательство дружественности...
И в пхп можно навернуть такого что не всякий с первого взгляда поймет...

to alchie:
2. А я и говорю, что "настоящие профессилнальные программисты" используют транслит ;-) Кроме того, что значит - "нормальную"?.. Ее же уже ни одна компания не развивает, насколько я знаю. Какой она была 3 года назад, такой и осталось, только программ общеюниксовых понаписали, но они и не тольуо на FreeBSD работают...
4. Замечание это ваше было в высшей смысле забавное, свидетельствующее о том, что вы сами мало что в Perl понимаете! Хорошо, флейм в сторону.
5. Да, функций там много. Пока они (разработчики) не доперли, что нужно бы сделать области видимости (namespace), хотя бы как в Perl, так и будет. Впрочем, разница не очень велика: что подключать модули и использовать функции из них, что НЕ подключать модули и все равно использовать функции ;-) Просто не нужно эти 1500 функций сортировать по алфавиту, а нужно иметь тематическую документацию. А "свобода синтаксиса" - это плохо, а не хорошо - почитайте хотя бы классиков, а также послушайте тех, кто изобрел XML (в XML, правда, жесткость синтаксиса доведена до абсурда).

to Paradox:
Я подумал, что вы одно и то же лицо с alchie, потому что вы почему-то никак не отреагировали на его сообщение о -X, явно абсурдное для любого другого человека. Подозреваю (вы уж меня извините), что вы тоже знаете Perl кое-как. Это правда?.. Насчет того, на каких других языках я пишу, могу просто перечислить: C++ и C, Pascal, Perl, PHP, Java, Lisp + Scheme, Forth, Basic;-), Assembler 80586, C# и .NET, Modula2, SmallTalk, JavaScript; технологии: HTML, SQL; системы: Visual C++, Delphi; опыт администрирования ОС Linux, Windows 9x/2000, а также серверов Apache, ProFTPd, sendmail, pop3d. Сейчас, кстати, в основном использую Perl (кстати, прочитали бы вы название этой статьи, насчет которой, собственно, весь сыр-бор).

> И после написания пары скриптов выскажу свое
> субъективное мнение (я думаю что именно так и поступил
> наш "уважаемый" АВТОР)
Вот так всю жизнь и будете скрипты писать ;-)
print "<HTML>";
print "<HEAD>";
print "</HEAD>";
... ;-)

to Paradox 2:
> И в пхп можно навернуть такого что не всякий с первого взгляда поймет...
Вот вы этим и будете заниматься, пока напишете свою "пару скриптов". На любом языке можно писать криво, а в Web-языках симптомы "кривости" гораздо более выражены, чем во всех остальных. На самом деле, написав на Perl хороший шаблонизатор, действительно можно писать код, который будет гораздо более читаем, чем код на PHP (или на ASP или на JSP - все равно, хотя в последнее время у Sun видны явные и не совсем удачные потуги на отделение кода от шаблона страницы). Вы бы почитали мою книгу - http://www.dklab.ru/book по PHP, что я тут буду ее пересказывать...

Еще раз: я не утверждаю, что PHP лучше, чем Perl (почитайте-ка заголовок статьи еще раз). Я лишь говорю, что синтаксис Perl крив, и писать на нем неудобно - особенно начинающим. Вы правы, когда говорите, что со временем привыкаешь, но так НЕ ДОЛЖНО БЫТЬ. Язык программирования на то и язык, чтобы быть простым (в отличие от человеческих языков, за исключением эсперанто). В то же время, синтаксис PHP очень похож на то, что в идеале должно быть (хотя там и большое извращение с классами). Разве в НОРМАЛЬНОМ (с точки зрения синтаксиса) языке могло бы возникнуть такое утверждение про -X, которое выдвинул alchie?.. По-моему, исключено.

И то, что PHP имеет кучу других недостатков, делающих его неприменимым при разработке очень больших систем, вина разработчиков. Я уже говорил об этом. Разработчики Apache не подозревают, что их сервер будет использоваться для хостинга. Разработчики Sun не догадываются, что JSP можно серьезно использовать для создания активных страниц напрямую, а не посредством так называемой модели 2 с ведущим контроллером (что есть ужасный архаизм). Разработчики Perl считают, что "язык может быть законченным только тогда, когда в его синтаксисе использованы все клавиши на клавиатуре". Ну а разработчики PHP не понимают, что нормального ООП (с классами и областями видимости) сейчас нет практически ни в одном скрипт-языке, поэтому на это нужно делать основной упор (но у них все равно ничего не получится, потому что они в очередной раз написали ядро PHP на Си, а не на С++). Так что "какое бы решение вы не приняли, вы все равно об этом пожалеете".

voschem kazhdii iz nas ostaetsya pri svoem mnenii...
ya schitayu, chto svoboda syntaxa - eto odna iz sil'nih storon Perl'a

Hochu skazat' odno...
Shto Pro-Otzi samovo navarochinovo proyekta perl (UBB), nachinayut ponimat' preimushchestovo PHP.

Chitayte vnizu (OPTIONAL: PHP 4 or higher):
http://www.infopop.com/products/ubb/architecture.html

Господа!
При всем уважении, вы взяли один из споров, из разряда что лучше, пила или топор.
Аналигии искать долго не приходится (Delphi/Builder VS Visual, MFC VS WinAPI, Pascal VS C и т.п.)
Имеет ли смысл все это ?
очевидно, что под каждый проект должен быть свой инструмент, наиболее удовлетворяющий потребностям. Соответственно надо знать и то и другое, а потом делать выбор.

Народ а не устарело ли это все в наш 2003 год то??? Странно, но я только попал на эту статью 8-)
Пишу сам очень давно на .php пока изучал его матерился блягим матом. Потом привык и сейчас у меня нет такой проблеммы , которую я не смогу решить на PHP. Я писал не только простые сайты , но и большие порталы NVIDIA BIOS Collection в последней редакции , я писал с нуля. Сайт сейчас уже не существует. На Перл мне не пришлось писать, так как я PHP я выучил только потому что смог достать для себя левый заказик на 800$. Это и был первый и кажется наиболее большой проект (не буду писать что и какой). Сейчас же , смотря в исходники я смеюсь над своим же кодом. На Перловке потом уже приходилось немного ковыряться, но для меня очень тяжело смотреть на "страшный" синтаксис. :) Если бы я начал с Перл то тоже самое теперь бы говорил про PHP.
Програмировать начал с Паскаля и теперь на Си хоть и пишу но не много и также мучяаюсь с синтаксисом. Начал бы с Си, то на Паскале бы не пимсал 8-)

[quote]
Но подождите. Возьмем-ка какую-нибедь систему на "более правильном языке" - на Си. Хотя бы тот же самый Линукс. Так вот, он вроде как ЦЕЛИКОМ (!) написан на стандартном (!) Си, в то время как дядя Страуструп еще в конце 80-х доказал, что Си++ гораздо лучше подходит для написания сложных и надежных систем, которые постоянно развиваются. Что это - отстование компьютерных технологий на 12 (!) лет? И да, и нет...

Почему, как в думаете, так удачлива компания Микрософт? Не потому, что она монополист (хотя сейчас ей это, конечно, очень помогает). Есть мысль, что все это из-за того, что все (!) свои программные продукты они вот уже с 95-го года пишут на Си++, а не на Си. И больше ни из-за чего. Каково?..
[/quote]

C++ совсем не упрощает разработку сложных проектов.
Отсутствие уборки мусора в совокупности с отсутствием ключевого слова finally порождает серьезные сомнения в психическом здоровье тов. Строуструпа. Лично я бы вообще не стал делать исключений в языке, подобном С++. Модулей в современном смысле в С++ нет. Нормальных динамических структур нет (STL ные извращения не в счет). Стандартной GUI библиотеки нет.
В серьезном проекте я предпочитаю делать GUI и критические места на С, а ядро на каком-нибудь динамически типируемом языке. Аналогичный подход издользуется многими юниксистами.

В PHP лично мне не хватает встроенного темплейтового движка. Прикол в том, что PHP сам по себе это темплейтовый движок. Тем не менее, проблема резделения кода и дизайна там не решена.

> Отсутствие уборки мусора в совокупности с отсутствием ключевого слова finally
> порождает серьезные сомнения в психическом здоровье тов. Строуструпа.
Что-то я не понял юмора. Зачем в C++ finally? Там же есть автоматический вызов деструкторов для автоматических (-; переменных. Вот в delphi этого, например, нет, таи и используется finally в качестве затычки (и очень плохой и ненадежной, надо сказать). Сборку же мусора тоже можно дописать — чем я и занимался пару лет назад. Конечно, она получается в стиле Perl (со счетчиками ссылок) и требует аккуратности (например, нигде нельзя использовать «голые» указатели, только обертки — впрочем, эти обертки ведут себя точно так же, как указатели), но работает весьма прилично.

И вообще, на С++ можно писать очень оптимальный код. Буть там автоматическая сборка мусора, это бы многое замедлило. Используйте C#.

Это все религиозные предрассудки. Типа goto вреден, finally вреден, etc...
Некто Виталий Луговский выступает против присваиваний и циклов, типа нужно всегда использовать рекурсивные конструкции, свойственные функциональным языкам.
В ньюзгруппе c.l.c++ я видел огромный тред в несколько сотен мессаг на тему, допустим ли
void main(void){ и высасывания из пальца проблем, которые может породить данная конструкция.
Была удачная шутка Андрея Тарасевича, что деление - вредная операция, поскольку в знаменателе может оказаться ноль, и поэтому надо отказаться от деления.

Религия меня не волнует.
Иногда мне нужно использовать простые указатели. Просто *нужно*.
Иногда мне надо надежно выполнить определенный код в случае возникшего исключения, поскольку деструкторы решают проблему только в самых дубовых местах. В ряде случаев надо прибирать ручками, соблюдая определенную последовательность освобождающих операций.

Размещать все объекты в куче, и явно вызывать деструктор, как сделано в vcl - это более грамотный подход. Почему finally - это затычка? В Java тоже есть это ключевое слово. Наряду с уборкой мусора.

Почему затычка? Потому что finally — это однозначно затычка для языков, где нет нормальных деструкторов. Сборка мусора тут даже и не совсем при чем. Например. В Perl автоматическая сборка мусора, но там деструкторы работают на ура и очень удобны. Правда, Perl не умеет рвать кольцевые ссылки. В Java тоже автоматическая сборка мусора, зато нет деструкторов (забудешь написать вызов «псевдодеструктора» в finally-блоке — и кирдык, потом фиг найдешь, в чем же дело), зато кольцевые ссылки рвет нормально.

Еще раз: Java тут — плохой пример. Я вообще не в восторге от этого языка. Подробности: http://dklab.ru/chicken/nablas/23.html

Я не хочу встревать в спор и отстаивать ту или иную строну, а просто хочу высказать свою точку. РНР изначально создавался для Веб-итнерфейса. Прел же был создан задолго до такого понятия. Если нужно создавать домашнюю страницу или сайт, то использование РНР будет намного разумней. Однко при создании скажем КИС которая пишется с использование ВЕБ-технологий (интранет), придется остановится только на перле. Использование компилируемых языков делает процесс создания таких систем более медленным, что очень критично в современном бизнесе. Конечно тут можно вспомнить ASP, но если КИС объединяет десятки серверов с разными осями, то выбрать что-то кроме перла очень сложно.
Создание сложных систем требует использование ООП, оно прекрасно реализовано в перле, чего нельзя сказать о РНР. Такие системы часто используют демоны для сбора статистики, анализа и предварительного общета.
К тому же Перл обладает возможностью взаимодействия со многими другими языками, что иногда просто необходимо.

Теперь хотелось бы немного сказать в защиту Перла. Не согласен я с тем, что @, &, % делают перл неудобнее. Нужно исходить из того, что Перл это язык контекста, а эти значки и показывают контекст. Нужно просто понимать язык на его же языке.
@arr - список
@arr[1] - список (срез)
$arr[1] - скаляр.
Срезов, да и вообще понятия контекста не существует в РНР. Я не говорю, что это не достаток. Однако если хорошо понимать контекст перла, тогда он становится очень логичным и начинаешь понимать, что все знаки в нем совсем не лишни, а даже необходимы.
Для тех, кто не программирует на Перл, может показаться излишним такое понятие, как контекст или лексическая область видимости переменых. Но если в этом разобраться и начать контекст использовать, то его сразу будет нехватать в других языках.
Ведь только в Перл можно писать такие конструкции.
$a=12 if $b == 1;
print $_ while (<>);
print "$_, " for (1..4);
Зачем? да это же логичней, сказать присвой переменно что-то если выполняется условие. Т.е. на превое место ставится действие а не условие или организация цикла. Сразу понятно, зачем этот цикл создается.
А вот и еще использование контекста, меняем значения двух переменых.
($a,$b)=($b,$a);#в каком еще языке это можно сделать одним оператором?
Краткость записи - это тоже не маловажно в программировании.
ИМХО все это.

Про «прекрасную поддержку ООП в Perl» Вы, надо сказать, погорячились (-;
Поддерживается-та там все. Только НЕУДОБНО на этом писать ООП-программы настолько, насколько это вообще возможно. В результате может загнуться даже хорошо спланированная задумка (что происходило на моей практике уже несколько раз, один раз это было с системой «активный транслятор с Perl++ на Perl» :-). Там, правда, было дело в восновном в надежде на скорое появление Perl6. Ну ничего, может, еще продолжу.

Да и про «логичность контекстов Perl, если их понимать» Вы тоже, пожалуй, преувеличили. Понимание чего-либо не означает логику этого чего-либо. Возможно, это означает удобство, но никак не логику. Иначе мы бы попали впросак, когда начали задумываться, как именно мы ходим и почему не падаем. Логичен ли процесс ходьбы? Да не важно, ходим же.

Кстати, в Perl масса исключений из «контекстных» правил, которые мне периодически присылают в качестве комментариев в «статьям в защиту логичности»:
http://dklab.ru/chicken/nablas/20.html
http://dklab.ru/chicken/nablas/21.html

Но с сутью Вашего постинга я по большей части согласен.

Развели флейм :-)
Скажу только одно.
Если технологию Автора переписать под FastCGI, да подправить корявый код (извини, друг, но это так...), то PHP и mod_perl отдыхают.
PHP - потому, что ему не снилась такая скорость обработки данных,
mod_perl - потому, что perl - это не mod_perl.

В чем прелесть Perl.
В том, что чем больше ты усовершенствуешь свою программу, тем размер кода ее становится меньше. Perl - это образ мысли. Чтобы научиться программировать на Perl, нужно программировать на нем не менее 2-3 лет (чтобы выбить из своих мозгов другие стили программирования).

PHP vs Perl:
Уважаемая MicroSoft уже всем доказала, что синтаксис не главное в этой жизни - главное компилятор. Пример - .Net и ASP (поддерживает VB, JS, Perl ... синтаксис )
По поводу компилятора в pCode PHPшники возникать не будут :-)
Кстати, экспериментируя с модулями Автора, я написал простейший скрипт на Perl и очень удивился, когда интерпретатор PHP отработал его без единой ошибки.
Вывод: На Perl можно также ДЕБИЛЬНО писать, как и на PHP :-)

Вы знаете, Вы все правильнонаписали (хотя, может, излишне резковато). Не знаю, с какими именно модулями Вы экспериментировали (вероятно, со старыми). Новые вот тут:

http://dklab.ru/chicken/nablas/4.html
http://dklab.ru/chicken/nablas/6.html
http://dklab.ru/chicken/nablas/9.html

Что касается fastcgi. К сожалению, где-то год назад mod_fastcgi для Apache на Windows оказался совершенно нерабочим (он просто грохался, когда размер программы превышал где-то 5000 строк). Я же являюсь сторонником отладки скриптов на Windows, ибо так ко всему прочему еще и улучшается их переносимость (99% Perl-скриптов в Сети расчитана только на Unix, и это не смотря на то, что Perl — язык кроссплатформенный). Поэтому-то я до сих пор о нем и не упоминал, хотя версия CGI::WebOut (и даже частично WebIn) для него у меня где-то валялась.

Интересно (я не знаю ни ПХП ни Perl только VB):). Прочитал все статьи:). Может подскажете по Linux что лучше изучать (в плане чтоб администрить)?. Спасибо

Позвольте влезть со своими пятью копейками :) Забавно, что никто так и не приводил тут конкретных цифр. Постараюсь восполнить этот пробел :)

WinXP, 1200MHz / Linux RH 7.3, 1800MHz:
PHP: for($i=0; $i<100000000; $i++) $sum=+$i; - 149 / 157 сек
Perl: for($i=0; $i<100000000; $i++) { $sum=+$i; } - 83 / 66 сек
Perl: $sum=+$_ for(1 .. 100000000); - 42 / 30 сек

PHP: for($i=0; $i<100000000; $i++) $a[$i%10000]=$i; - 240 / 204 сек
Perl: for($i=0; $i<100000000; $i++) { $a[$i%10000]=$i; } - 107 / 89сек
Perl: $a[$_%10000]=$_ for(1 .. 100000000); - 91 / 57 сек

PHP-Linux: 4.3.1, PHP-Win32: 4.3.1, Perl-Linux: 5.6.1, Perl-Win32: 5.8.0. Под Windows - оригинальные бинарники, под Linux Perl из пакета, PHP - собран.

Как видно, Perl на простейших операциях, лействительно, шустрее. Особенно когда можно воспользоваться его гибким синтаксисом.

А вот практика. Берём и делаем запрос большого текста в MySQL:

my $dbh = DBI->connect("DBI:mysql:***", '***', '***') or die "Can't connect database: ".$DBI::errstr;
my $sth = $dbh->prepare("SELECT post FROM ib_posts WHERE topic_id=19689 AND forum_id=23");
$sth->execute;
while(my $res = $sth->fetchrow_hashref)
{
print $$res{'post'};
}
$sth->finish;
$dbh->disconnect;

и

$dbh = @mysql_connect("localhost", "***", "***") or die ("Could not connect");
@mysql_select_db("***") or die ("Could not select database");
$q="SELECT post FROM ib_posts WHERE topic_id=19689 AND forum_id=23";
$query = mysql_query ($q) or die ("Query '$q' failed, error ".mysql_errno().": ".mysql_error()."<BR>");
while($out = mysql_fetch_array($query))
{
echo $out['post'];
}

Выдаётся текст на 118кб. 130 запусков скриптов в разное время под разной нагрузкой. PHP отдаёт страницу со скоростью 4Мб/сек, а Perl - 0.9Мб/сек.

Словом, я для работы с MySQL пока предпочту PHP :)

А синтаксис - дело десятое...

Кстати, если результат не выводить, а занести в переменную и потом её регекспом обработать, то разница в пользу PHP получается ещё больше.

Вообще не видно зачем переходить на Перл если PHP проще и имеет те же возможности при этом обгоняя PERl во многих операциях. Просто нет смысла.

люди!!! прекращайте! как тут было сказано, Ваши споры это столкновения религий подобно (Pascal vs C/C++).

я ничего не знаю ни из РНР, ни из Перл.
я начинаю изучать РНР.

почему? потому что он проще. может быть это и хуже (в смысле моей будущей "переносимости"к Перлу). когда то я знал только Бейсик (это было 2000 лет назад :-) потом за 3 дня я познал Паскаль. и долго не мог понять С/С++. ну и бог с ним. пришло время и я понял С/С++ через JavaScript. мне было в свое время достаточно возможностей Паскаля.

надо будет мне познать Перл, если будет в этом необходимость, я его узнаю, выучу. начну понимать проги на Перле. пока не надо... пока я не знаю и РНР. но у меня есть время и я его (время) использую на познание РНР.

идея такая. программист использует те языки, которые наиболее удобны ему для решения каких-то конкретных целей. сейчас ему удобнее, бустрее, оптимальнее, красивее, элегантнее (нужно подчеркнуть) на одном языке, завтра - на другом.

А может всетаки не туда переходим, как это ни печально!
Сходите-ка на сайт http://www.delphikingdom.ru да попробуйте запросы в форуме, вот где скорость. Страницы генерятся практически влет(чего не скажешь об уважаемом webscript, который со своим php оставляет удручающее впечатление). Уж не знаю на чем они пишут свой ASP (уж не на Delphi-ли?)... ну конечно...бедный индеец в пролете.

К сожалению много времени прошло но держите:
--

Первого Января 1998 года Bjarne Stroustrup давал интервью журналу
'Computer'. Вообще-то редакторы предполагали, что он расскажет о семи годах
объектно-ориентированного программирования с применением языка, который он и
разработал.
К окончанию беседы выяснилось, что интервьюер извлек больше информации,
чем предполагал, и, естественно, редакторы решили урезать содержание 'для
пользы индустрии', но, как обычно получается в таких случаях, произошла утечка
информации.
Вот полный и нередактированный протокол интервью - это не похоже на
обычные запланированные вопросы/ответы.
Вам наверняка покажется это интересным.


---

Интервьюер - далее И., Stroustrup - далее C..

И. Прошло несколько лет с тех пор, как Вы изменили мир разработки программного
обеспечения. Что Вы теперь чувствуете, оглядываясь назад?

C. Вообще-то я думал об этих днях как раз перед тем как Вы приехали. Помните -
все писали свои версии 'C', и проблема была в том, что все это делали чертовски
замечательно. Университеты тоже чертовски замечательно преподавали этот язык.
Это привело к понижению компетенции. Под 'компетенцией' в данном случае я
подразумеваю феноменальность. Вот что породило проблему.

И. Проблему?

C. Да, проблему. Помните когда все писали на Cobol?

И. Конечно, я тоже это делал.

C. Hу вот, в начале эти ребята были как боги. Им платили кучу денег и
относились как к королям.

И. Да уж, вот это были времена...

С. Именно. Hу и что же случилось? IBM прямо заболела этим и вложила миллионы в
подготовку программистов, пока их не стало до ужаса много.

И. Вот так и я вылетел из этой сферы. Втечение года зарплата упала настолько,
что даже журналистом можно было зарабатывать больше...

С. Точно. То же самое случилось и с программистами, писавшими на 'C'.

И. Понятно, ну и что же Вы все-таки хотите этим всем сказать?

C. Однажды я сидел у себя в оффисе, и мне пришла в голову небольшая идейка, как
хоть немного восстановить баланс. Я подумал: интересно, что произойдет, если
будет язык программирования такой запутанный и такой сложный для изучения, что
никто бы уже не сможет заполнить рынок толпой программистов, пишуших на этом
нем? У меня уже были тогда кое-какие мысли по этому поводу. Вот, знаете
наверно, X10 и X windows. Это тогда была такая графическая система, которая
работала на Sun 3/60. У нее были все ингредиенты, которые мне были нужны -
комплексный синтаксис, сложные для понимания мрачные функции, псевдо
объектно-ориентированная структура. Даже сейчас никто не пишет напрямую под

И. Шутите?

C. Hичуть. Есть еще одна проблема. Unix был написан на 'C' - это значило то,
что любой программист, пишущий на 'C', мог очень легко стать системным
программистом. Помните сколько обычно зарабатывали большинство системных
программистов?

И. Да, я же ведь тоже этим занимался.

С. Так вот, этот новый язык должен был отделять себя от Unix путем скрывания
всех системных вызовов, которые так здорово связывают 'C' и Unix. Тогда ребята,
знающие только DOS, тоже смогли бы прилично зарабатывать.

И. Hе верится в то, что Вы это сказали...

С. Это уже происходит достаточно долго, но вроде сейчас большинство людей уже
уяснили для себя, что C++ - это пустая трата времени, но должен сказать, что
осознание этого происходило дольше чем я ожидал.

И. Hу расскажите поточнее, как же Вы все-таки сделали это?

C. Это была просто шутка, я никогда не думал, что люди воспримут эту книгу
всерьез. Любой человек, даже с половиной мозга, может понять что
объектно-ориентированное программирование интуитивно, нелогично и неэффективно.

И. Что?

С. И относительно 'повторно-используемого кода' - Вы когда-нибудь слышали,
чтобы хоть одна компания 'повторно-использовала' что-либо?

И. Hу, вообще-то не слышал, но...

С. Вот так-то. Hекоторые, кстати, пытались. Была такая компания из Орегона -
Mentor Graphics, в которой просто заболели тем, что пытались переписать все что
можно на C++ в '90 или '91 году. Я на самом деле им сочувствовал, но думаю, что
люди по крайней мере, научились чему-то на их ошибках.

И. Очевидно у них ничего не вышло?

С. Вообще ничего. Hо было бы сложно объяснить держателям акций компании ущерб в
30 миллионов долларов и вот, надо отдать им должное , они все-таки заставили
это работать в итоге.

И. Так все-таки у них получилось? Это доказывает что 'объектное-ориентирование'
работает.

C. Почти. Запускаемый файл получился такой огромный, что загружался 5 минут на
рабочей станции HP со 128Mb оперативной памяти. Я думал, что это станет камнем
преткновения, но это никого особенно не заботило. Sun и HP были очень рады
продавать до ненормальности мощные ящики с огромными ресурсами для выполнения
на них тривиальных программ. Знаете, когда мы в AT&T откомпилировали нашим
первым компилятором C++ программку 'Hello World', я не мог поверить своим
глазам: запускаемый файл получился размером 2.1Mb.

И. Да уж... Hо компиляторы с тех пор прошли долгий путь.

C. Вы так думаете? Попробуйте тот же пример 'Hello World' с последней версией
g++ - вы получите примерно пол-мегабайта. А кроме этого есть еще множество
примеров со всего мира. У British Telecom чуть было не возникли большие
проблемы, но к своему счастью они вовремя догадались свернуть проект и начать
все заново. И им больше повезло, чем Australian Telecom. А теперь я слышал, что
Siemens cоздает какого-то динозавра и все больше и больше волнуется по поводу
размера того, что у них получается. Hе правда ли забавно смотреть на это
всеобщее заблуждение?

И. Да, но C++ -то, в общем, вполне нормальный язык.

С. Вы в это так верите? Попробовали ли вы когда-нибудь сесть и поработать над
проектом на C++ ? Во первых, я расставил достаточно ловушек, чтобы просто так
работали только тривиальные проекты. Под конец проекта получается что одни и те
же операторы в разных модулях означают совершенно разные вещи. А теперь
попробуйте соединить все эти модули в единое целое, особенно если у вас их штук
100. Боже, я иногда не могу удержаться от смеха, когда слышу о проблемах разных
компаний, которые не могут сделать так, чтобы их модули общались между собой.

И. Я должен сказать, что совершенно сбит с толку всем что Вы сказали. Вы
сказали что сделали это для того, чтоб повысилась оплата труда программистов.
Hо это же бессмыслица.

С. Hе совсем так. У каждого есть его выбор. Я не предполагал, что все это так
выйдет из-под контроля. Hо все-равно, практически все у меня получилось. C++
cейчас уже умирает, а труд програмистов продолжает нормально оплачиваться -
особенно тех, кто имеет дело со всей этой чепухой - вы же понимаете, что
невозможно использовать эффективно большой программный модуль на C++ , если не
вы сами его написали.

И. Как это?

С. Hе понятно что-ли? Помните typedef ?

И. Конечно.

С. А теперь вспомните сколько времени приходится копаться в заголовках для
того, например, чтобы просто найти, что какое-нибудь там 'RoofRaised' - число с
двойной точностью. Представьте теперь сколько времени уйдет на нахождение всех
определений типов в большом проекте.

И. Значит, Вы утверждаете, что Вам все, что Вы хотели удалось...

C. Hу, вспомните сколько занимает реализация проекта среднего размера на 'C'.
Это около 6 месяцев. Hе достаточно долго чтобы парень с женой и детьми мог
заработать себе на нормальное существование. Попробуйте тот же проект
реализовать на C++ , и что получится? Вам понадобится 1-2 года. Hе правда ли,
это замечательно? Кроме этого: в университетах уже так давно не преподают 'C',
что теперь стало мало людей программирующих на 'C', особенно таких, которые
знают все о программировании под Unix. Как вы думаете : сколько парней смогут
сообразить что делать с 'malloc' , после того как втечение многих лет они
пользовались 'new' и никогда не заботились о проверке кода возврата?
Большинство программистов на C++ вообще не выбрасывают этот код возврата. Что
произошло со старой доброй '-1' ? По крайней мере было сразу понятно, что у
тебя где-то ошибка без всяких там 'throw', 'try' и 'catch'...

И. И все же, наследование экономит кучу времени?

С. Hет, я же говорил... Замечали, в чем разница между стадиями планирования
проектов на 'C' и C++ ? Для проекта на C++ эта стадия в три раза дольше. Время
уходит на то, чтоб убедиться что все что надо наследуется, а все что не надо -
нет. И все-равно без ошибок не обходится. Кто слышал когда-нибудь об утечке
памяти в программе на 'C' ? Теперь нахождение этих утечек - целый труд.
Большинство компаний сдаются, так и выпускают продукт, зная что утечка памяти
существует.

И. Hо есть различные программные инструменты...

С. Большинство из которых написаны на C++.

И. Если мы опубликуем все это, то Вас просто могут линчевать, понимаете ?

C. Сомневаюсь. Как я сказал C++ уже уходит в прошлое. Hи одна компания без
предварительного тестирования теперь не начнет проект на C++, а если будет
тестирование, то они поймут, что это путь к неудаче. Если не поймут - то так им
и надо. Знаете, я пытался убедить Dennis'a Ritchie переписать Unix на C++.

И. О Боже. И что же он сказал?

C. К счастью у него присутствует хорошее чувство юмора. Я думаю и он, и Brian
понимали что я тогда делал. Он ответил, что может мне помочь написать версию
DOS на C++, если я захочу.

И. Hу и как? Вы захотели?

С. Я написал DOS на C++. Могу дать вам demo. Она у меня работает на Sparc 20 в
другой комнате. Просто летает на четырех процессорах и занимает всего то 70
мегабайт на диске.

И. Hа что же это похоже на PC ?

С. Вы, очевидно, шутите. Видели же вы Windows'95 ? Я о них думаю как о своем
величайшем успехе.

И. Знаете, эта идея насчет Unix++ заставила меня задуматься. Ведь где-то может
сидеть парень, которому придет в голову сделать это...

С. Hо не после того, как он прочитает это интервью.

И. Я сожалею, но врядли мы сможем опубликовать даже часть этого интервью.

С. Hо это же история века. Я просто хотел чтоб мои приятели-программисты
помнили меня за то, что я для них сделал. Знаете как сейчас оплачивается
программирование на C++ ?

И. Последнее, что я слышал - настоящие профессионалы зарабатывают $70-80 в час.

С. Понимаете теперь? И я уверен, что он заслуживает этих денег. Отслеживание
всех этих ловушек, которые я встроил в C++ - не легкая работа. И, как я говорил
раньше, каждый программист на C++ чувствует себя связанным тем обстоятельством
что он должен использовать каждый элемент языка в каждом проекте. Вообще это и
меня часто раздражает, даже тогда, когда это служит моим целям. Hо сейчас,
когда прошло столько времени, мне уже начинает нравиться этот язык...

И. Имеете ввиду, что раньше Вам C++ не нравился?

С. Hенавидел его. Он даже выглядит неуклюже, вы не согласны? Hо когда стали там
выходить разные книги... вот, тогда-то я и увидел полную картину.

И. Погодите, а как насчет ссылок? Вы подтверждаете что улучшили указатели 'C' ?

С. Хмм. Я и сам не знаю. Вообще я думал, что да. Потом я как-то говорил с
парнем, который писал на C++ с самого начала. Он говорил, что не мог запомнить
были ли ссылки на его переменные или нет, поэтому он всегда использовал
указатели.

И. Обычно на этой стадии я говорю 'большое спасибо за интервью', но сейчас это
как-то не к месту.

С. Пообещайте мне, что опубликуете это.

И. Я извещу Вас, но мне кажется, что я знаю, что скажет мой редактор по этому
поводу.

С. А все-равно, кто этому поверит? Кстати, не могли бы вы мне прислать копию
этой записи?

И. Это я могу.

(c) ?

Полная чушь. Страуструп такого интервью не давал — это ясно даже ребенку. А сочинить такую ахинею мог лишь человек, вообще не умеющий программировать. Конечно, если он это сочинял на полном серьезе.

Ну понаписали - до конца не дочитать. Сайчас я пишу на Perl, ранее писал на C. У меня опыт был такой - надо было текст разбирать один на C, так я решил написать подпрограмму для разбора шаблонов (т.е. поиска определенной последовательности с получением найденного результата). Так вот каково было моё удивление, когда на большом тексте программа на C работала примерно в два раза МЕДЛЕННЕЕ, чем на перл (а я думал будет раза в 4 быстрее ;). Так что вот.
P.S. естественно, код подпрограммы парсинга я максимально оптимизировал (конечно я в этом не профи, но все же).

Почитайте: http://dklab.ru/chicken/perl6/

Для меня, лично, perl - это регулярные выражения. Такой скорости обработки огромного кол-ва информации одной строчкой оптимизированной "регулярки" я не встречал. Perl+FCGI дает потрясающие возможности по производительности. Даже если использовать мой доморощенный парсер, который сканирует переменные и целые конструкции в обычных JS, HTML..., подрубает нужные библиотеки, работает с достаточно объемными запросами к mysql(тут, правда, заслуга самого mysql) и пр., скорость выполнения ошеломляет. Для примера, я писал несколько модулей для оптимизации контента для вывода на мобильные телефоны известных производителей. Хотя сами производители и не особо заботятся о наличии UAPROF для некоторых моделей, или запаздывают с их выпуском, но мне хватило тех, что я собрал (порядка 120 UAPROF). Для некоторых моделей требовалось очень сильно "извращаться", прежде чем они стали понимать то, что я им преподношу. Был написан wml/xhtml-парсер, который динамически конструировал конечный контент основываясь на модели телефона (т.е. с таблицами, графическими изображениями и пр.). Были написаны модули для отсылки бинарных sms с настройками, закладками, сервисами и пр... Вся эта каша работала настолько быстро (она и сейчас работает, т.к. проект скоро будет запущен), что я не переставал удивляться... Всё было проверено эмулятором, который непрерывно "насиловал" сайт, подставляя разные модели. Естественно, реальные модели телефонов тоже работали. Я уже молчу про "космический корабль", который был написан для наполнения базы достаточно разноплановым контентом. Была задача сделать интеллектуальную систему, которая сама себя дополняет новыми UAPROF и пр.... Достаточно большие расчеты для того, чтоб вывести маленький, но красивый сайтик.

Слишком далеко я углубился... Так вот, всё это написано на Perl5+FCGI.
Когда я дал посмотреть результат супер-программеру на PHP, он долго чесал затылок, смотря на регулярные выражения, говоря, что это не должно работать...

Спорить я не люблю, и, безусловно, каждый программист пишет на своём любимом языке. На том, языке, в котором он "съел собаку".

Я просто хочу сказать, что Perl - это действительно нечто большее, чем язык программирования. Это философия целая:)

Всем, удачи!

p.s.: единственное, чего не хватает в нынешних "регулярках", так это обратного плавающего поиска. не люблю всё фиксированное. хочу вот так (?<=[^\;]*)...примерно:)

Кароче! Вы меня все задрали! Что лучше перл или пхп??? Я для себя выбор сделал и никто меня не переубедит, что пхп круче перла. Если Вас никто не убедит в обратном, то это Ваше право!
Каждый дрочит так как хочет! :) В смысле каждый юзает то, что ему нравится!

print "Content-type: text/htmlnn";
print "<html><body>n";
print "<h1>Hello!</h1>nHere is the numbers: ";
for(my $i=0; $i<10; $i++) { print $i; }
print "</body></html>";
Этот вариант, конечно, не лезет ни в какие ворота. А что если нужно сделать редизайн? Лучше сразу повеситься. В то же время, в PHP можно комбинировать обычный html-такст с кодом скрипта. Например:
<html><body>
<h1>Hello!</h1>
Here is the numbers:
<?for(my $i=0; $i<10; $i++) { print $i; }?>
</body></html>

Что и куда нелезет, всё лезет Perl нужно учить лучше
print qq{
Content-type: text/htmln


<html><body>
<h1>Hello!</h1>Here is the numbers:
for(my $i=0; $i<10; $i++) { print $i; }
</body></html>
};
Хотите простоты учите PHP
Хотите програмирования Perl

нето написал
&foo();
print qq{
Content-type: text/htmln

<html><body>
<h1>Hello!</h1>Here is the numbers:
$ii
</body></html>
};
sub foo{
for($i=0; $i<10; $i++){ $ii.= $i; }
}

Ребята, всем давно известно, скорость и красота вашей програмулины не зависят от средства, все идет от головы :)

Поддерживаю полность автора , увидел кусок скрипта - все, диагноз один-копаться, копаться и копаться в этих скриптах меняя дизайн, бессмысленно убивая СВОЕ! время.

print "Content-type: text/htmlnn";
print "<html><body>n";
print "<h1>Hello!</h1>nHere is the numbers: ";
for(my $i=0; $i<10; $i++) { print $i; }
print "</body></html>";


И этот пример не вызывает умиления, тем более что ты сам все ЭТО забабашил :)

print qq{
Content-type: text/htmln


<html><body>
<h1>Hello!</h1>Here is the numbers:
for(my $i=0; $i<10; $i++) { print $i; }
</body></html>
};

Если ВСЕ скрипты написаны в таком виде - то о чем вообще тогда можно говорить!!!
О каком вообще! редизайне может идти речь, при ТАКОМ написании скриптов(хоть perl, хоть php возьми).

И всетаки перл гораздо сложнее в редизайне нежели ПХП.

ПХП рулит однозначно, че вы тут развели плин.. ;)
1. у пхп проще синтаксис
2. пхп не медленнее перл. впринципе они примерно равны, в одном чуть быстрее перл в другом быстрее пхп.
3. на перле нет практически ничего, чего нельзя сделать в ПХП
4. в пхп намного больше специализированных веб и не только функций

2 Rumata )) - стандартный подход паскалиста, как я ))
2 ALL Никогда не мог себя заставить писать на С, а от PHP просто заторчал... дело не в синтаксисе!
А про обсуждение статьи... думаю ушли явно в сторону ибо в статье было сказано примерно так: БРЕЗЖИТ СВЕТ Perl ))
Как маленькие - столкнулись между собой остроконечные и тупоконечные, трактористы и мышевики и лупят друг по дружке из рокет-ланчеров...
Тяжеловато было читать, но дочитал все доконца ибо ждал развязки... суть утонула... жаль.

==============
У меня опыт был такой - надо было текст разбирать один на C, так я решил написать подпрограмму для разбора шаблонов (т.е. поиска определенной последовательности с получением найденного результата). Так вот каково было моё удивление, когда на большом тексте программа на C работала примерно в два раза МЕДЛЕННЕЕ, чем на перл (а я думал будет раза в 4 быстрее ;). Так что вот.
==============
Браво! Вы умудрились на С написать такую гадость которая работает гораздо медленей чем аналог на скриптовом языке...
вот это тебе может пригодится в разборе твоих шаблонов http://pcre.org/
А вообще программы написанные на С работают в сотни-тысячи раз быстрее чем на перле, чем сложнее прога, тем больше разница... :)

ИМХО, вот все говорят про редизайн в ПХП - это круто и просто, а в perl - стрёмно и тяжело. А я хочу спросить:"Никто случаем про шалоны в perl не слышал ??? Для чего их интересно придумали?"
Я бы не сказал, что менять дизайн в шаблонах тяжелее, чем в ПХП.(особенно, если ПХП-код между стоками ХТМЛ занимает порядка 50-100 строк) Кто-то со мной не согласен? А вообще-то, эта дискуссия не имеет смысла - для тех кому в облом, либо напрягает учить perl могу только посочувствовать. Такой свободы синтаксиса и способов написания одного и того-же выражения как в perl, я (говорю за себя) не видел нигде.

почему-то никто не упомянул про мультипарадигменность Perl'а
--
имхо, спор этот из разряда холиваров, так что смысла - 0
==
2Валера: кто тебе сказал про скорость работы?
работают программы на Си и Перле примерно одинаково. А вот то, что Перл ещё транслирует программу ты забыл.

Да на пхп уже давно не просто удобен, быстр, а еще и функционален...
На нем можно все написать и совсем нет нужды лезть в дебри перла...

В крайнем случае PHP + C++ - всёЁ... На перле пишут те, кому в падлу учить пэхапэ...

+ ко всему php гораздо быстрее развивается... сравните php3, php4 и php5...

2айрон и никому твоя мультипарадигменность не нужна.... )))

То что PHP чаще меняет номер версии вовсе не означает, что он развивается интенсивнее Perl'а.
Вдобавок, это еще спорное мнение, какой из языков более функционален - PHP или Perl.

В любом случае все доводы ведут к тому, что PHP не лучше, чем Perl.

Перл язык не объектный и не просто корявый, а безобразно уродливый. Попишите регулярными выражениями и вы начнете регулярно выражаться. после выхода 5-го ПХП, да если честно, то и после 4-го только слепой маразматик считающий, что можно писать не объектно большие проекты может использовать Perl. А если кто то заступится за синтаксис перла - http://www.linux.org.ru/view-message.jsp?msgid=392747 идите плачьте и смейтесь)

Вообще лихо! Коменты больше трёх уже лет пишут ;) Я за это время изучил РНР (в т.ч. и по Котеровскому самоучителю - кстати неплохой, но помницца с ошибками в кодах досадными) и даже успел на вебскрипте.ру своих статей напубликовать немножко... :)

В общем, скажу авторитетно :))) РНР лучше :) Я на нем даже утилитки для себя пишу под Винду ;)

А знаете почему РНР лучше? Потому что я его знаю, а Перл нет :) А Перл я не знаю потому же, почему например не умею работать с vi - потому что я себя люблю. А ребята, которые придумали Перл и vi - людей не любили ;) Вот и всё что можно об этом написать ;)

з.ы. 2Dmitry - уж не знаю чем PCRE не ко двору пришлись - штука рульная однозначно! Они меня здорово выручали неоднократно, в РНР-реализации ессно ;) Вот еще если бы работали побыстрее - цены бы им не было!!! :) На все строковые функции с удовольствием бы забил - чисто регулярными выражениями бы всё делал :))))))) (гоню)

=))
А статейка не запоздала так на 6 годиков ??
:DDDDDDDDDD ржунимагу

PHP, PHP и еще раз PHP :)

Какая жутя! =)))

Вобщем с поправкой на бессмысленность спора скажу, что ПХП для написания сайтов годится куда лучше. Скорость разработки больше, объём кода меньше, работать в команде проще. Т.е. чужой ПХП-код понять гораздо легче, чем чужой код на Перле. Плюс ко всему если ПХП и проигрывает (немного, местами) Перлу в скорости, то эти полторы секунды становятся пренебрежимо малы, когда заказчик хочет видеть на главной странице навороченную Флешку. Допускаю, что Перл быстрее посчитает колличество буковок в "Войне и Мире" или замечательно решит какую-нибудь другую задачу. Но в написании сайтов это мало помагает. ;)

"Неоправданно сложнее..."

аффтар памойся

Интересно, а автор первого камента еще жив - а?

Я Дмитрий Котеров, через пять лет я понял - Perl ГО?*%ВНО!

P.S. Бл:?*ть опять с Perla на PHP переходить...

А если взять регулярные выражения и обработку текстовой информации, то выясниться, что ПХП рядом с Перловкой даже близко не стоял!!! :-))

И ваабще ПХП - язык для «делетантов-тимуровцев», которым мозгов не хватает врубится в Перловый синтаксис!

Зачем учить С++, когда есть Бейсик = зачем долбаться с Перлом, когда есть ПХП :-)))

2Voldemar: "выясниТСя", "дИлетантов", "врубитЬся".

Дилетантов вы упоминаете в смысле противопоставления их профессионалам. Профессионал - тот, кто своей деятельностью зарабатывает себе на жизнь. Смотрите в словаре. А при наличии огромного числа успешных заказных проектов на php понятно, что ваше заявление несостоятельно.

Все сук!

А интересно будет заметить, основные перечисленные недостатки ПХП завязаны на его медлительности, так? Смотрим дальше... с возможностями современного ПХП код на нем в 2-3 раза меньше основного ХТМЛ наполнения(по крайней мере у меня так). Совать пользователю страницу объемом более 80-100 кб - не то. Итого, те самые злосчастные 150 кб. Едем дальше... скорость пхп5 раза в полтора-два меньше скорости Перл(поправте и киньте камень). скрипт в 150 кб на том же П-500 мутится за 0,5-1 секунды, так? НО КТО ПОЛЬЗУЕТСЯ П-500 ПОД СЕРВЕР? у нас на машинах скрипт в 150 летает...
С другой стороны, программа программе рознь. Я и товарищ писали скрипты для нахождения простых чисел. У меня до 1000000 за 3 часа, у него за три дня - до 500000. Как ведь скрипт построен, что у автора в башке... Мое скромное мнение: если надо катать сайт - не морочиться и юзать ПХП, тем более, что автор раскаялся и написал неплохие книги-самоучители...

Я сочиняю драйвера в основном для промышленного оборудования, которое производят конторы выплачивающие мне денюжки ;) Пишу на С и нескольких разных ассемблерах. Вот, захотелось освежить в памяти Веб-программирование и глянуть, чего тут новенького. Набрел на старенькое :) Все равно, автору спасибо за информацию, полезные ссылки и тонкий юмор.

P.S. Как человек, терпеливо и вдумчиво прочитавший всю дискуссию от начала до конца, могу предположить, что два, предшествующих моему, поста от "Автора" написал скудоумный шутник-подросток.

Кому сейчас нужна скорость? PHP значительно проще для начинающих, поэтому и популярнее. А куча функций хоть и значительно сложнее Perl'овских вариантов, зато доступна всегда и для чайника проще найти нужную функцию в документации чем вспоминать универсальный вариант. Perl'овские объектные системы опять таки требуют изучения и для начинающих их мощность не важна. Вот поэтому PHP выигрывает - на нём значительно проще написать программу. Нет необходимости читать документацию на систему шаблонов - сразу используешь <? ?>. А про heredoc и в PHP мало кто знает.

Сравнивая перл и пхп вы сравниваете кулинарию и фестфуд. Потребителей быстрой и дешевой еды всегда полно и производителей пропорционально, иногда даже выглядит оригинально. Но если начинается Творчество с большой буквы, то только ПЕРЛ!

Интеренсая дискуссия. Согласен с последним комментатором: сейчас появилось полно народу, по сравнению со временем, когда была написана статья и первые комметарии. Программят все кому не лень, и представить, что все выберут язык посложнее и интеллектуальнее, сложновато. Большинство будет программировать на Дельфях и VB, а писать сайты на пхп (когда-то сам писал на Delphi, но он стал неудобен [для меня], пользовательский он какой-то, как один большой визард)
П.С. Я с перлом не знаком)), но очевидно, что он сложнее для освоения, чем пхп.
Интересно, где-то посередине (какой там год был?) было замечание на счет генерирования этой страницы за 50 сек. - у меня внизу подписано 1.17 секунды =)

У меня история изучения такая бейсик ( в школе, еще на БК001 :))) можно не считать,
Pascal после первого оказался намного функциональнее и мощьнее :)
С++ этим языком проникся :) очень нравится и сейчас, код не побоюсь слова намного КРАСИВЕЕ чем у паскаля. Да и в общем язык очень сильный.
С веб программированием начал знакомиться совсем недавно, т.к. собираюсь устраиваться в соответствующую фирму. Первые впечатления PHP - удобный и простой язык, все интуитивно понятно и учится очень быстро. А вот перл для меня стал просто кошмаром :) Код выглядит оооочень коряво и запутанно, регулярные выражения просто в ступор порой вводят :) взять хотябы одно из первых с которыми пришлось встретиться m:(.*)[/\\](.*):); Ну это на первый взгляд, а вообще буду дальше грызть гранит перла :) Всетаки в этой "корявости" чувствуется скрытая поначалу мощь и гибкость. Конечно каждому проекту лучше подбирать свой язык, но поначалу скорее всего буду дублировать для себя, чтоб определиться.
Насчет этой странички: Сгенерировано за: 0.6383200

<Сравнивая перл и пхп вы сравниваете кулинарию и фестфуд. Потребителей быстрой и дешевой еды всегда полно и производителей пропорционально, иногда даже выглядит оригинально. Но если начинается Творчество с большой буквы, то только ПЕРЛ!
--------------------------------
Гы ща выйдет PHP6 а потом судя по всему что то типа PHP++ :)
И все, это наступит эра PHP, perl сам помрет со своими сторонниками... :)

По поводу генерации страницы , Здесь много других факторов влияющие на генерацию страницы

C выходом PHP5, в котором есть и полноценная поддержка ООП, и высокая скорость, и еще много чего, необходимость в Perl попросту отпала. Достаточно зайти на http://www.hotscripts.com, взглянуть на цифры, и все станет ясно.

:) классный "блог"!
шесть лет, если вдуматься, народ копья ломает .. прям психологический срез рунета (причем в исторической динамике) - тут тебе и "ржунимагу" и целые страницы кода .. история развития социума в преломлении Сети ..

в одном таком "форуме" я вычитал, что какого-то сторонника ПХП в Перле бесит наличие $ перед именами переменных .. тоже ведь показатель интеллекта .. и он ведь готов был спорить - доказывать , что это признак убогости Перла :) , (а не скудности его - ПХПшника - ителлекта)

поэтому я не буду дискутировать о недостатках ПХП :)

предлагаю другую тему для дискуссии - я продаю Perl в два раза дороже чем PHP - это объективная реальность - я могу делать код по функционалу и оптимальности нехуже ПХПшного и мне работать не сложнее чем с ПХП (я делаю это быстро), и это хорошо продаётся, а значит - будет жить, пока его покупают (причем так неплохо) - даже несмотря на то , что в моём коде с листа только я и разберусь :)

Перл - таинственная и дифицитная вещь, о нем мало знают, наслышаны много легенд про его "навороченность" и устойчивость, а перловщики - люди на вид загадочные (так мой манагер говорит) ... а о чем там спорят яйцеголовые - конечного пользоваля не волнует и не понятно ему ... и он мне платит :)

:) классный "блог"!
шесть лет, если вдуматься, народ копья ломает .. прям психологический срез рунета (причем в исторической динамике) - тут тебе и "ржунимагу" и целые страницы кода .. история развития социума в преломлении Сети ..

в одном таком "форуме" я вычитал, что какого-то сторонника ПХП в Перле бесит наличие $ перед именами переменных .. тоже ведь показатель интеллекта .. и он ведь готов был спорить - доказывать , что это признак убогости Перла :) , (а не скудности его - ПХПшника - ителлекта)

поэтому я не буду дискутировать о недостатках ПХП :)

предлагаю другую тему для дискуссии - я продаю Perl в два раза дороже чем PHP - это объективная реальность - я могу делать код по функционалу и оптимальности нехуже ПХПшного и мне работать не сложнее чем с ПХП (я делаю это быстро), и это хорошо продаётся, а значит - будет жить, пока его покупают (причем так неплохо) - даже несмотря на то , что в моём коде с листа только я и разберусь :)

Перл - таинственная и дифицитная вещь, о нем мало знают, наслышаны много легенд про его "навороченность" и устойчивость, а перловщики - люди на вид загадочные (так мой манагер говорит) ... а о чем там спорят яйцеголовые - конечного пользоваля не волнует и не понятно ему ... и он мне платит :)

Странно но mod_perl не каждый хостер поддерживает, они предпочитают mod_perl на выделенные сервера ставить а там суммы за хостинг на порядки выше, зато PHP да же на самый вшивый хостинг вешают.. хорошо это или плохо.. но если б крутой так сказать mod_perl был более доступен возможно PHP не стал бы столь популярным.

PERL можно использовать в любых проектах, не только в вэб программировании! Это несомненно огромный ПЛЮС для самого интерпритатора! То есть CGI это совсем не минус, как кажется всем PHP'шникам!

Есть ещё некая гордость за знание perl, просто работаю с PHP'шниками и они както с уважением относятся к человеку знающму perl.

В данный момент, как мне кажется, толчёк Microsoft asp.net вообще реально чувствуется.
В начале данного блога уже говорилось что возможно когданибудь вэб приложения будут писать на Бейсике, это уже происходит. Всё чаще выбор хостинга падает на Windows.
Я думаю что конечной точкой станет включение PHP в ASP.NET , как для Perl так и для самого PHP.
Потому как при выборе на чём писать php или vb , средненький кодер выберет VB. А поддержка PHP Микрософту нужна только чтобы повалить Apache...

По своему опыту знаю, что на Perl пишут мало "сайтов" - перловики заняты более масштабными проектами обычно ;)

Согласен с Павлом Кудиновым. На пхп вообще много пишут "любители" (ну и профессионалы конечно тоже), а вот перлы работают в серьезных корпорациях и под веб не очень много пишут...

Переходим с PHP на Perl, как это ни печально... 06.02.2001

Даже смешно - копий поломано - всё не осилишь... ;)
Переходим ? - не перешли... Как тарахтели на пхп так и тарахтят.
Сухой остаток - ПХП более-менее сносно научился поддерживать ООП причем ещё в 4ой, ща пятая - вообще на 4 с +
перл к сожалению ниасилил, чего оно там научился не знаю...
Но по опыту общения с сайтами - что перловые, что нарисованные на пхп по скорости генерации примерно одинаково идут (речь идёт не о жутко профессиональных ;) - сейчас скорость генерации ограничивается вызовами SQL...
Нужно срочно поднять вопрос "Переходим с скуэль на чонить другое - как это не печально..." =).

А кстати, кто там там думает, что у мелкомягких, на их серваке на асп с 7'ю Тб инфы -одна машина, которая не перезагружалась уже года 4 - да поможет Вам гуууугл в поиске такого определения, как кластер...

by MaximusMX

мда...
как оказалось обработка форм на этом сайте написана плохо, так как каждый может подписаться "Автор".... например как это сделал я в этом и предыдущем сообщениях.

2Бармалей
так что не факт, что это были слова автора. по крайней мере я в этом сомневаюсь.

Что же касается копий, то не вижу причины их ломать, ибо глупо ставить под один шаблон Perl и PHP. Цель разработки и суть и предназначение PHP - это в первую очередь Web дизайн. И писать большой сайт, или форум на Perl просто нецелесобразно. Если же нужна работа с большими массивами данных или файлами и т.д., то тут PHP тоже не место. Не его это и точка. вот странно, но почемуто не пишут сайты, на Pascal, а ведь можно...

ЗЫ. Каждый будет писать на том на чем ему более свободно общатся с железным мозком в рамках поставленой задачи.

Сабж прикольный получился, много разных мнений кто за перл кто за пхп, соглашусь с тем что каждый пользуется тем инструментом(в данном случаи язык программирования) какой он лучше знает и эффективнее применяет. сам я начинал свой тернистый путь веб-программирования с perla лет 5 назад, особо не угляблялся в это дело создавая сайтики не с целью продать а просто понять саму сцть, постепенно появились какие-то варианты на подработку. но суть не в этом опять же.
так же пробовал писать на пхп, решил тупо переписать движок какой у меня был на перле, что у меня получилось с переменным успехом ия решил забить на это. сейчас прожолжаю писать на перле и меня он во всем устраивает. И с каждым разом больше удивляеюсь его гибкость и тем конструкция какие можно в нем навернуть, регулярные выражения это вообще отдельная история с помощью них можно реальный шаблонный движок навернуть и не надо использовать какие-то дополнительные модули, а конструкции типа $tmpl =~ s/\<%exec (.*?)\%>/eval($1)/gcse;
вообще кайф. в общем я сужу со своей колокольни, как и многие здесь,
и во многих попросах я думаю столь крутой программер даже в тех же моментах что касается синтаксиса perlа.
просто подвиду итог своего субъективного мнения в защиту перла, но при этом не собираюсь кидать камни в огород пхп, мое мнение сводится к тому, что если чел освоил нормально перл то ему не составит труда написать пару функций для решения каких-то ключевых моментов пусть то будет таже обработка шаблонов, что исключит из тела маразм типа
=====
print "Content-type: text/htmlnn";
print "<html><body>n";
print "<h1>Hello!</h1>nHere is the numbers: ";
for(my $i=0; $i<10; $i++) { print $i; }
print "</body></html>";

На самом деле я поклонник Perl, а вышеупомянутую операцию можно с лекгостью прописать так:

print <<PPN;
Content-type: text/html\n\n
<html><body>\n
<h1>Hello!</h1>nHere is the numbers:
PRN
for(my $i=0; $i<10; $i++) { print $i; }
print <<END;
</body></html>
END
====

а благодаря множеству модулей какие написаны для перла легко осуществить взаимодействие сайта с разничными система тотже почтовый сервер, ldap, не говоря уже базах даных и друх специфических задачах.

в общем пока писал этот бред потерял мысль, понятное дело сколько можно было выпить пока читаешь весь этот флейм:) но теперь и мой флуд запечетлиться на этой борде.

Почему Perl лучше PHP:

1. В PHP нет use strict и use warnings - все можно установить только глобально.

2. Perl значительно стабильнее PHP, программа которую ты написал будет на нём ещё очень долго работать (это частично и проблема Perl - многие ругают Perl, но пишут при этом по стилю на Perl 4). Perl очень хорошо тестируется на совместимость кучей модулей из CPAN.

3. Большая проблема PHP если ты размещаешь сайт у кого-то - это его настройки. С помощью настроек можно многое отключить. Например http://textpattern.com/faq/266/the-following-php-functions-are-disabled - там длинный список того что можно отключить (как я понимаю, поэтому они их не используют - список того что они используют весьма короткий).

4. Очень хорошая поддержка в Perl Unicode - просто обозначь файл как UTF8 и всё.

5. В PHP одинаковые операторы сравнения строк и чисел. Поэтому надо применять '===', strval и intval.

6. В PHP ОЧЕНЬ много функций для того чтобы делать почти одно и то же.

7. В PHP нет поддержки namespace - мне лично достаточно уже этого.

8. Мощные расширения:
autobox и autobox::Core позволяют использовать встроенные типы как объекты
Perl6::Junction (из Perl6, пример: all($x,$y,$z)>5).
Attribute::Signature - проверка типов параметров подпрограмм

9. Типизированные переменные (по желанию и не для встроенных типов)

10. Анонимные подпрограммы

11. Ориентация на тесты.

12. Встроенные регулярные выражения (qr// и др.).

13. CPAN.

Perl постепенно вытесняется PHP, это объективный процесс. Он обусловлен тем, что PHP оптимизирован под скорость компиляции: это гарантирует изоляцию скриптов, что весьма важно для массового виртуального хостинга. Mod_perl никогда не будет доступен за маленькие деньги, поскольку на общем Apache кто угодно может писать в соседский пакет. Много дешёвого хостинга -- много быстро обученных программистов.

Но, программируя на Perl и PHP в течение 10 лет, могу определённо сказать: PHP следует использовать только там, где Perl недоступен из-за требований хостеров. В остальных ситуациях (у меня это заказные Intranet-системы) писать на Perl гораздо эффективнее. Это просто экономия рабочего времени (замечу: без малейшей потери в качестве). Разумеется, при этом необходимо соблюдать дисциплину, но без этого нигде нельзя. И если тут всё в порядке, то с поддержкой проблем не возникает.

Смешно сегодня читать предсказания автора о кончине перла и линукса. И особенно смешно, что причиной тому было бы то, что написаны они на чистом си, а не на си++.

А про причину популярности винды (всё пишут на с++) - так это вообще просто анекдот :-))))))

автору 5

спасибо!

кто не писал на перл - тот автора не поймет !!! - ЭТО ФАКТ!

А какже PHP5???!!

А какже PERL6 ???!!

print "PERL рулез !!!" unless $@;

Интересно, сколько еще будет жить данная дискуссия?
Хотя это, наверное, риторический вопрос.
А вот Перл и ПХП будут жить до тех пор пока не сделают им обоим достойную альтернативу. Ну, или же не будет какого-нибудь очередного прорыва. Хотя и тогда уже, скорее всего просто и тот и другой модернезируются. Но это уже от разработчиков зависит.
Сейчас же не умирает ни тот, ни другой. И тот, и тот развиваются. Просто направления все расходятся немного в стороны. Действительно, сейчас большиство сайтов пишется при помощи ПХП. А почему? Да потому, что предложение растет быстрее спроса. Действительно появляется очень много программистов, которые прочитав один какой-нибудь самоучитель, и то наполовину, тут же бросаются писать проекты. Тут уже разумеется им не до перла. К тому же, как верно сказал Saint Father ( я продаю Perl в два раза дороже чем PHP), код на Перле действительно гораздо дороже чем код на ПХП. А большинство заказчиков сайтов, ввиду столь обильного предложения услуг, не станут переплачивать за разницу генерации в несколько секунд и надежность. К тому же им практически невозможно будет обосновать такую разницу в цене, между сайтом на ПХП и сайтом на Перле.
Крупные же компании, в которых работают специалисты, способные понять хотя бы суть этой 7-летней дискуссии, будут заказывать на перле. Посмотрите просто вакансии того же яндекса.

Для большинства сайтов так и останется приоритетным ПХП. Для крупных же проэктов, больших сервисов и т.д. однозначно Перл. ПХП ведь и задумывался именно для создания не слишком больших сайтов. И название его, Personal Home Page, говорит само за себя.
Поэтому спорить кто будет жить, как в 2001году PHP3 или Perl (пардон, не помню какой он тогда был версии), так и сейчас PHP5 или Perl6 - не имеет особого смысла.
Всегда найдутся люди, выбирающие ПХП, и люди изучающие Перл.
Хотя, на мой взгляд, стоит знать и то и другое. Всегда хорошо иметь выбор.

Привет всем ... мдя дискуссия на несколько лет , и закончится ли вобще.

вот лично мое мнение:

ПХП прост, понятен, легок в освоении, НОВИЧКАМ... и как многие уже высказались дешев...
Перл сложнее, быстрее дороже ...
и еще много как + так и - у каждого есть

Лично мой опыт на текущим момент это всеголишь 2 года, причем я самоучка... 2 года назад даже HTML незнал с чего начать

но теперь как настоящий анат понимаю что PHP мне мало, поэтому открываю для себя новые горизонты знаний возможностей и скоростей :), писать сайты за час уже устал а для больших проектов PHP уже слабоват, и никакие кеши не помогут, когда с системой(сайтом) роботают 20- 30 а то и все 200 тысяч человек.

стремись к лучшему но не забывай с чего НАЧИНАЛ :)

ИМХО: PHP не умрет, и Perl тоже останется жить !!!

Нихрена себе:)! Я уже и школу успел закончить, и в универе диплом получить - а ТУТ все спорят!8-() Да это ж языки настолько же разные, насколько и похожие! Они могут прекрасно дополнять друг друга: если работаешь профессионально - не помешает выучить возможности и преимущества обоих, и применять по ситуации.

Лично я программирую на perl'e, были поползновения в строну php, но они быстро закончились. Просто наработана большая база по perl и переносить в php не хотелось. В общем я бы сказал что perl и php похожи как пежо или фольцваген.

Эти машины сделаны для передвижения со средней скоростью для большинства. И они свою функцию выполняют. Так же и эти языки, нет никакого смысла спорить что лучше, это бесконечный спор. Тем более что работы всем хватит и php-шникам и perl-овикам, осталось куча проектов на этих языках и все они будут существовать.

Приведу лишь два примера:
ag.ru - написан на Perl
vkontakte.ru - написан на PHP
Не думаю, что теперб у кого то возникают мысли о
том, что тот или иной язык не может выдерживать
большие нагрузки.
По последниму посту видна очень распространеная
ситуация, Perl появился раньше и у людей остались
знания, а так же огромные базы наработанной
информации поэтому осваивать PHP для них нет
смысла. НО новичкам, которые начинают свои
познания web-программирования советую изучать PHP,
а уж если надо действительно серъезные проекты
писать то на Java.

Да что вы заладили, перл...пхп...
Common Lisp наще все!!!!!!! :D

Глупый спор.
я вот забросил perl когда научился на php кодить...

[b]ааааааааа11111адинадинадинадинадин я тоже оставлю здесь свой след :) я осилил всю дискуссию, от начала до конца, хочу памятник себе :D[/b]

ну а если по теме то... язык программирования, язык разговора.. если бы мы могли писать проги на русском и на китайском языках, на каком бы мы писали? конечно на том который уже знаем, и который любим :) если кому вдруг при изучениее китайский понравится больше - пожалуйста.. но без надобности учить китайский, когда есть возможность продвинуться в русском - пустая трата времени имхо

я перл не знаю и не собираюсь знать, по крайней мере для создания динамических веб-сайтов
пхп мне нравится тем, что в нем все очень просто и не надо геморриться насчет синтаксиса или еще чего-то, это время тратится на обдумывание общего алгоритма и структуры проекта...

а вообще, забавно, за 7 лет холивара только 1 (!!!) человек решил перейти с перла на пхп, ну а кто он, думаб все и так догадались - это сам превеликий Афтар :)

Помнится когда я сюда первый раз зашел, было это много лет назад, даже представления не имел о PHP и Perl. Сегодня, в этой области, за плечами уже две CMS, почтовики, менеждеры и еще много разного, по мелочам. В итоге, для себя, не нашел ничего лучше связки PHP+MySQL.

Говоря о PHP vs Perl, я не в курсе кто кого вытесняет, откуда, куда и вообще зачем. По видимому я не в теме. А для реализации даже сегодняшних прикладных задач, не летая где-то высоко в облаках, PHP хватает за глаза.

P.S. А вообще хорошо что этот сайт еще жив

Большинство народу которые за php и против перла никогда не имели дела с огромными проектами.
Огромные это когда чисто код, без данных, без html и тп, исходники, логика, занимает больше 10 мбайт(50 например, для меня это нормальное дело).
Про быстродействие выше уже говорили, но это не самая большая проблема.
Поддерживать такие проекты на php просто нереальный геморой, доказывать это не буду, это ИМХО основанное на своем опыте, геморой испытаный на своей жопе.
Ещё скажу, что каждый язык нужен для своих целей,
если простой скрипт написать, сайт визитку там... почему бы не использовать PHP?
если надо простых демонов писать, сервисы тяжелые, с распаралеливанием работы и тп... про php лучше не вспоминать.
У перла есть ещё одна такая весчь офигенная, его можно как связку использовать,
можно связывать различные продукты и по сокетам тебе и через STD потоки и встраивать как embed библиотеки...
вот например в перле путевых шаблонаторов нет, они или глючные(HTML::Template::Pro и его наследник CC2 вроде, клевые, быстрые, но изза утечек памяти в mod_perl нельзя использовать),
или тормознутые(мазон, темплейт тулкит)
Зато php как шаблонатор великолепен, и у меня на паре сильно нагруженных проектов работает связка perl+php
перл обрабатывает готовит структуры данных, и передает в embeded php, для этого есть спецовый модуль, и все работает очень быстро, в секунду отдается несколько сотен страниц без кеширования.
Кроме перла и пхп есть ещё MS.net, java и много чего ещё.
чтобы решить что использовать, надо думать головой, оценивать и тестировать... и в общем знать надо на что каждый продукт способен, для этого надо все ручками потрогать, а не кричать, я мол обхожусь без перла и поэтому он мне нахер ненужен, php рулит перл отстой, неконструктивно как-то.

Да... старый сайт ничего не скажешь... Ну что сказать в итоге.. Набредя на эту статью я искал информацию о perl тк думаю начать изучать его.. Вобщем думаю нестоит связываться с perl тк для разработки сайтов (в моем случае) php будет достаточно...

мути сам

а чем глючный HTML::Template::Pro, вроде бы пока багов не заметил.

поздравляю автора - вашу статью коментируют уже 7 лет))
расскажите как изменился мир за это время...

пора уже уходить с php3 все-таки на перл или нет?)))

Гы прикольно не статья, а машина времени ... Считай семь лет назад парили про какой-то РНР3, када щас 5 полным ходом юзается...

- Автор,Вы есчо живы? =)
- Я собираюсь на Perl написать симулятор! (произносить криком :-) )
И воббще,как дела? =)))

Автор не только жив но и изжал несколько ОЧЕНЬ ХОРОШИХ КНИГ и ведет проект denwer.ru !

Вот уждействительно, эпическое обсуждние.

По поводу Perl лишь скажу, что перед ним открывается новое будущее с вводом Parrot.
PHP широко распространён и на рынке труда специалистов PHP ищут многие комании, которым нужна быстрая разовая работа по созданию сайта или веб-магазина.

Сейчас изучение Perl или PHP - вопрос скорее общего профессионализма. Либо ты быстр и ухватис и обслуживаешь сотню мелких проектов в год, либо ты целеустремлён и сосредоточен на в лучшем случае десятке основательных проектов, в которых ты не фигура на месяц, а полноценный член команды. Рыноктруда диктует направление.

Мой выбор - Perl. Но и PHP я не упуска и виду, неизвестно, куда повернёт Рынок, особенно в условиях Кризиса.

Перешёл с PHP на PERL и радуюсь жизни, теперь даже под страхом жестокой расправы не буду ни чего писать на PHP. Проще? Делайте свои паги в ворде, там ещё проще. Я за скорость, эффективность и красоту! Да и вообще PHP это первоначально обрубок PERL-a. Пока что вперёд батьки не смог пробиться, хоть и очень старается.

прочитал все от начала доконца, так как изучаю пхп где то только пол года, и вот только хачу сделать свой первый более менее серьезный сайт.Все заставило призадуматься так как особо опыта у меня еще нету, и тут дело каждого пока напишу на пхп, потом если припрет тогда уж и посмотрю что там в перле,а пока мне и пхп хватает :)

прочитал всю тему, думал что поседею...
Слушайте, люди, может быть не в тему, но есть еще Ruby и фреймворк под него RubyOnRails.
Они стоят своего изучения? Сейчас знаю перл и рнр на среднем уровне, перл больше нравится.
Не для работы или продажи, а просто для себя хотелось бы узнать Ваше мнение о руби. Это мертвый язык или развивающийся?

Perl намного сложнее, но на нём можно сделать практически всё.

Perl намного сложнее, но на нём можно сделать практически всё.

Так, коменты работают, поэтому можно написать более подробный отзыв.

Программирую на перле уже лет 5. До этого был опыт с FoxPro (если кто помнит). Понимание языка приходит года через 3. Безусловно для этого нужна хорошая литература, найти которую очень и очень не просто. Далеко не в каждом магазине можно купить. Тиражи у книг маленькие.

Ларри Уолл - лингвист. Это очень многое значит. Для меня перл очень похож на русский (тоже трудный язык для иностранцев - падежи и прочее). Но на перле одну и у же вещь можно сделать несколькими разными способами и это собственно девиз перла. Разбирать чужой код не просто - но это уже культура программирования - надо оставлять комментарии.

За последнее время не встречал задач для веб, которые бы невозможно было выполнить на перле.

Тем кто на распутье - посоветовал бы следующее: перл - это философия и с наскока её не понять - нужно время. Но если "занырнуть", то переныривать в другие языки точно не захотите. Ларри Уолл кстати не только умный человек, но и весьма весёлый, с большим чувстом юмора.

Доброго времени суток!
Да, статья это как машина времени :)
Не могу пройти мимо, хотя до этого пару тройку лет назад ходил мимо :)
---
Для меня когда-то PERL был дремучим лесом, но что-то манило в нем ... скрытая философия. Подстегнуло еще то, что операционная система, на которой я работаю с 2001 года, тесно связанна с этим языком - операционная система семейства UNIX.

На начальном этапе мы вибираем, в данном случае, тот язык программирования, который соответствует нашему уровню базовых знаний.
Опять же есть разница: или рынок труда требует или ты сам выбираешь.

Если у тебя домашняя страничка на PHP, то сложно понять минусы и плюсы языка. А когда у вас большой проект с тысячами запросов в минуту или даже в секунду, то придется задуматься.
Не использовать же 5тонный грузовик, для поездки на работу и обратно домой - не эффективно. А для перевозки 5 тонн груза использовать запорожец - не целесообразно.

Посмотрите историю создания языка PHP, в его названии фигурирует слово "Домашняя страничка". Это его изначальное применение.
Я например не знаю, как отработает мой PHP код написанный под версию 5.1.12 на новой версии 6.х? Что там опять переделают, что мой код просто не заработает.
А версия Perl на UNIX системе практически не изменилась 5.8.х => 5.10.x
Не велики изменения. Да и зачем. Там и так все есть и этого хватает - лично мне и для моих задач. Если не хватет, есть 80 тыс. модулей в CPAN.

Меня всегда пугало массовое использование чего либо - любая массовость, порою граничит с безрассудностью и не обдуманностью.

Прежде всего, хотелось бы выразить восхищение данной статье, которое вот уже десятилетие
остается актуальной, сохраняет позиции в Google и постоянно обновляется новыми мнениями!
Статья была написана, когда я еще совсем был малышом, хахха я только сейчас это понял, мне было
9 лет!!!

В этом (2001) году, как мне рассказывали, обещали конец света :) (ну который перенесли с 2000 на
год), и вот сейчас я пишу свое мнение перед новым концом света :) глядишь статья пройдет все апокалипсисы. Некоторые люди даже успели школу закончить и диплом в универе получить, чем я
сейчас и занимаюсь. Автор почему-то не отписывается :( действительно как буд-то умер, тьфу тьфу
тьфу.

Я не жалею, что потратил 3 часа на прочтение всех отзывов, и наконец вставлю своих 5 копеек.
Вот уже 5 лет, как я занимаюсь, программированием на PHP (сейчас больше делаю напор на
JavaScript, в основном на библиотеку JQuery, ибо заказчики требуют красивостей и в картинки
тычут, а более менее рабочая CMS не подводит, тем более новые возможности ООП в PHP не
могут не радовать), язык действительно приятен глазу, удобен в использовании и выводит ошибки в
браузер :-D но нынче мне захотелось чего-то большего! Устал уже от точь в точь одинаковых
скриптов (ну или примерно похожих), заинтересовался другими CGI, и конечно попал на PERL, я и
раньше про него много слышал, но в голове всплывали только регулярные выражения, коих хватало
и в PHP.
Нынче понял, что нужно развивать свои навыки и изучать, поглощать, как можно больше
информации и не становиться быдлокодером.
А вот после PHP, как-то очень странно воспринимать другие языки. Первым делом, в поисках
информации о Perl, я посмотрел его организацию ООП. Ух!

Просто огромная машина символов :)

package A;
sub new {
my ($class, $s)=@_;
return bless {'string' => $s}, $class;
}
package B;
our @ISA=qw/A/;
sub type {
my ($self)=@_;
print $self->{'string'}, "\n";
}
package main;
my $obj=B->new('ok');
$obj->type();

Не очень то восприимчиво для первого взгляда, но это мое мнение.
В общем друзья я для себя решил - Perl нужно учить! Как и другие языки программирования. В нем
действительно есть что-то таинственно и манящее. Почему нужно учить? Да потому что я так понял
вы выбрали профессию - ПРОГРАММИСТ! На одном PHP вы далеко не уйдете, будете работать в
каком-нибудь сайтоскороштамп и просто станете роботом по генерации PHP функций. Вы должны
развивать свой интелект и генерировать идеи :). Сейчас вот все выучили только пхп и что из этого
получилось? В Селиконе России - сделали сайт за 20 млн. рублей!!! на пхп!!!! да еще со слайдшоу из
бесплатного движка Joomla!!! (причем, тот тоже на PHP, а и еще с паролем 1) . Просто пазооор!
Пора уже надрать задницы этим китайцам и японцам! где наши лучшие программисты???
Вот просто душа за родину болит.

Сейчас у меня есть идеи по большому проекту, а времени на изучение Perla для дальнейшего
внедрения в проект нету! Нынче все летит со скоростью света! Поэтому буду усердно, в свободные
минуты познавать музыку Perla... Почему в свободные минуты? Кто не прочитал всех постов
сообщаю - "Для осмысления Perl, требуется хотя бы 3 года". Затем уже буду и его внедрять.

Дорогие друзья, не трате дорогие минуты жизни на порнуху :), создавайте вещи, а не приобретайте
их (слова группы MyAutumn ) и давайте уже не подводить нашего дядю Медведа (как наш Автор
Ельцина =D ), как тот долба*б с силиконовым прототипом первого российского мобильного
телефона через 2 года после финансирования или сколько? не помню не имени не срока.

Блин :) надо вообще отдельно от Сколково сбацать мегу команду :-D и сделать революцию :) как
раз меня кто-нибудь ознакомит с Perlom и его % & и $ :)

Блин, друзья, простите... Я так вечно могу рассуждать - тащите за уши! :) Надеюсь я вам не надоел,
если надоел - извините, по вашим отзывам я вижу вы все умные люди.

По-мойму автор статьи, где-то наверху указывал свое мыло, напишу как ему :) он года три не
отвечал на статьи :) нужно же все-таки узнать его мнение!!! :)
Всем удачи!!! Кому интересно со мной пообщаться или может выпить пива на выходных (Санкт-
Петербург), вот мое мыло:
$pop = "gmail";
echo "effect.mail@" . $pop . ".com"; // Регулярно проверяю, надеюсь всем понятно? :)

С уважением, Павел Третьяков. 19 Сентября 2011 года (обязательно проверю лет эток через 5 :-D)

Долго читал )) Решил быть первым в 2012...

Вообще конечно, меня сильно смущает в первую очередь тенденция комментариев, она говорит о
том как менялась культура кодеров за последние 11 лет, не зря сейчас все так называемые "быдло-
кодеры" на пэху перешли, оно и понятно, люди тянутся там где проще и быстрее. Это не камень в
огород, просто такова реальность. Криворучки есть везде, но в пэхе их сейчас на порядок больше.

Занимаюсь вебом с 97 года, пишу и на пехе и на перле. Поддержу автора в том - что перл это поэзия
ума при всем ужасе кода (пример с стихом на китайском как нельзя кстати). Развивая проект на
перле, как правило код сокращается, а не множится, как это не странно. То что можно красиво и
коротко реализовать на перле в пхп сделать на порядок сложнее (правда не факт, что быстрее). Сейчас работать с проектом на перле одно удовольствие, с прямым опп - сайт как конструктор, о
каких вообще шаблонах речь? :) Вы о чем господа? Довелось работать над проектом где сайт
собирается в интерфейсе админки из модулей купленных как в аппстор у апплов, со всеми связями
иерархие и зависимости. Причем все это очень прилично выглядит и взаимодействует jq -> ajax ->
perl. Хотите делать такое на пхп? Вот я например не извращенец. Плюс перл сейчас стал набирать
популярность в разработке серверных приложений для онлайн игр.

С другой стороны если нужно сделать что-то совсем быстро и просто - пэха выручает. Но в этом и
отличие сторон. Не кого не хочу обидеть, но в моем представлении - за перл я сожусь тогда, когда
хочу сделать что-то качественное, а за пхп, когда подшабашить. Хотя у меня есть друзья и
знакомые, которые со мной частенько спорят об этом. Из них очень серъезные разработчики,
которые создают такие проекты как cms-bs.ru, lingualeo.ru, hotboom.ru (в моем понимании проекты
современного формата, со всеми вытекающими последствиями)

Также никто не отметил того факта, что скриптик, можно просто пустить на серваке в фоновом
режиме (скажем для обработки данных) на перле это делать намного приятнее. Согласитесь?

Говорили по поводу переменных $, @, %, & - поддерживаю, то что такая структура придает коду
больше ясности, особенно когда разбираешься с чужим кодом.

Срез истории на одной странице.
А уже тринадцатый год ))

В нём Ну вообще-то странный спор... Perl для веб разработки среди скриптовых языков по многим причинам. Ну во первых Perl существует лет так 30, а PHP без году неделя. Perl многократно превосходит по функциональности любой язык. В Perl нет глюков и т.п. а код компактный и удобный... Что же касается популярности PHP, то это скорее рекламное, а не реальное... Очень много пишут на Java к примеру. Но Java очень далёк от идеального языка... Так что это не аргумент. Как и необычность синтаксиса программ на Perl. Это вопрос привычки и аргумент для делитанта... И несмотря на всю очевидность преимуществ Perl многие не пишут на нём, хотя он специально разработан для работы с текстом. А Веб страница это не более чем текст...