В таблице "Perl/Php Translation (http://www.cs.wcupa.edu/~rkline/perl2php/)" представлены соответствия типовых конструкций Perl и PHP, призванных облегчить перевод скрипта с одного языка на другой.URL: http://www.cs.wcupa.edu/~rkline/perl2php/#datastructs
Новость: http://www.opennet.me/opennews/art.shtml?num=9656
код на Перле вобщем компактнее
по мне так PHP читабельней, а лаконичность кода, не настолько ж она и влияет, обработка чаще всего всёравно на сервере
>по мне так PHP читабельней, а лаконичность кода, не настолько ж она
>и влияет, обработка чаще всего всёравно на серверетоварисч жжот :)
если на сервере - то значит мгновенно и в любом объеме %)
и вааще нии**ет что там на сервере!
Гы-гы :)
Да, "читабельность", понятие субъективное. Если конечно речь не идёт о количестве чит-кодов, которые были найдены в php (а также ещё не были найдены). Тут конечно php впереди планеты всей ;)Что же касается параметров, которые можно более менее объективно измерить, то смотрите вот эту статью: http://tnx.nl/php
И потом расскажете, что читабельней, 3079 основных функций языка, или 206 :)
Там же написано: пых был собран со всеми возможными расширениями, какие вообще возможны. Сравнение некорректно: собери core без расширений, тогда сравнивай.
Т.е. твой "Hello World!" на PHP будет использовать все 3079 функций? ;)
Я ща найду find /usr/local/lip/perl|grep pm$ и их сделаю use. Это будет недецкая жесть.
>Т.е. твой "Hello World!" на PHP будет использовать все 3079 функций? ;)Не понял, причём тут мой "Hello World!"? Я говорю о нормальных программах, которые могут сделать что-то полезное. Hello World, конечно, можно и на php написать :)
>Я ща найду find /usr/local/lip/perl|grep pm$ и их сделаю use. Это будет
>недецкая жесть.О том и речь, что в Perl, в отличии от PHP, вся дополнительная функциональность вынесена в модули. И нет плоского, как блин, пространства глобальных функций. Которые, к тому же, ещё и называются, как бог на душу положит.
Но нет проблем, отключаем в PHP все модули, оставляем только core (при этом теряем возможность работать с регулярными выражениями, но даже на это закроем глаза). Думаете, картина сильно изменится? В core всё равно входит функций на порядок больше, чем их встроено в ядро Perl. И почему так происходит, в статье, которую я привёл, прекрасно объясняется. Прочитайте, всё-таки, до конца :)
>>Т.е. твой "Hello World!" на PHP будет использовать все 3079 функций? ;)> Не понял, причём тут мой "Hello World!"? Я говорю о нормальных программах,
> которые могут сделать что-то полезное. Hello World, конечно, можно и на php
> написать :)Нормальные программы на PHP используют те фукнции, которые им нужно, а не все
3079.>>Я ща найду find /usr/local/lip/perl|grep pm$ и их сделаю use. Это будет
>>недецкая жесть.> О том и речь, что в Perl, в отличии от PHP, вся дополнительная функциональность
> вынесена в модули. И нет плоского, как блин, пространства глобальных функций.
> Которые, к тому же, ещё и называются, как бог на душу положит.Открою тебе страшную тайну: в PHP ты также можешь это собирать
модулями. И их не много - пару десятков.А по поводу модулей перла...
$ grep ^p5- /usr/ports/INDEX|wc
2643 81823 1935030
Это уже пафос просто.А по поводу имён функций, ты знаешь, вон китайцы на китайском
разговаривают весьма fluent, и никаких проблем - дело привычки. И даже
не смей говорить им что у них язык кривой.> Но нет проблем, отключаем в PHP все модули, оставляем только core (при этом
> теряем возможность работать с регулярными выражениями, но даже на это закроем
> глаза). Думаете, картина сильно изменится? В core всё равно входит функций на
> порядок больше, чем их встроено в ядро Perl. И почему так происходит, в статье,
> которую я привёл, прекрасно объясняется. Прочитайте, всё-таки, до конца :)Прочитал. Высосана из пальца методом женской логики.
Arguments and return values are extremely inconsistent.
Слава богу что return values не зависят от контекста вызываемой
функции. И без статьи даже бы и не знал что есть что-то там
inconsistent. Спасибо, просветили ;)PHP has separate functions for case insensitive operations.
С чего это недостаток? Для меня это вообще роли не играет. Perl вообще в плане функций
в основном эмулирует C-аналоги. Вообще не терплю эти сокращения eq,
gt, le, lc...PHP has inconsistent function naming. См. замечание про китайцев.
Всё равно я на память их все не помню - по любому полезу в
документацию. Моя основная (архиважнейшая) проблема - как мне называть
мои функции и помнить что они делают.PHP has no lexical scope.
Даже и не знаю что это. Я ж тупой. ;) Может быть лишняя сущность сверх
необходимости? А вот то что в перле мне в функциях нужно писать
направо и налево local и my - весьма раздражает.PHP has too many functions in the main namespace.
;) Афтару нужно было не в программисты идти, а в политики. Там такие
нужны. А то скоро Шуфрича на рыбалку позовут, Черновола на охоту или в
баню, а дело-то, сам понимаешь, опасное, и место демагогов будет вакантно.PHP lacks abstraction and takes TIMTOWTDI to bad extremes.
Насчёт абстракций - есть. И по тому списку что там можно пройтись
критическим взглядом весьма много пересчитав рёбрышек автору. Лень ;)
Слишкам многа букф.
>Нормальные программы на PHP используют те фукнции, которые им нужно, а не
>все
>3079.
Ну только зачем тогда все остальные жрут память ? - выключить их для конкретного скрипта нельзя :)
>Открою тебе страшную тайну: в PHP ты также можешь это собирать
>модулями. И их не много - пару десятков.
>
>А по поводу модулей перла...
>$ grep ^p5- /usr/ports/INDEX|wc
> 2643 81823 1935030
>Это уже пафос просто.
Ну пара десятков - отнюдь и не пара, а около 2 сотен - см. ПЕКЛ, ПЕАР и тд. Но шлавный косяк в том, что они все требуют инсталляции, динамически их хрен подключишь. Или - хрен отключишь :) К тому же, то они в пекле, то в пеаре, то в ядре - бардак полный. Да и документация отдыхает.>Arguments and return values are extremely inconsistent.
>Слава богу что return values не зависят от контекста вызываемой
>функции. И без статьи даже бы и не знал что есть что-то
>там inconsistent. Спасибо, просветили ;)
Тоже маразм: то false === returnvalue, то 0, to 1, to '' , то array()... полный бред. Гораздо приятнее, когда значение учитывает контекст. Хотя это наверно дела вкуса.>PHP has separate functions for case insensitive operations.
>С чего это недостаток? Для меня это вообще роли не играет. Perl
>вообще в плане функций
>в основном эмулирует C-аналоги. Вообще не терплю эти сокращения eq,
>gt, le, lc...
А РНР то эмулирует, то не эмулирует, то С-аналоги, то перл-аналоги...>PHP has inconsistent function naming. См. замечание про китайцев.
>Всё равно я на память их все не помню - по любому
>полезу в
>документацию. Моя основная (архиважнейшая) проблема - как мне называть
>мои функции и помнить что они делают.
Да, но когда ты вдруг называешь свою функцию именем, которое уже зарезервировано? А не помнить на память и лазить в доки - только время терять. Плюс - полный маразм, когда системные функции вдруг изменяют названия или параметры.>PHP has no lexical scope.
>Даже и не знаю что это. Я ж тупой. ;) Может быть
>лишняя сущность сверх необходимости? А вот то что в перле мне в функциях нужно писать
>направо и налево local и my - весьма раздражает.
Ну локал и май - можно и не писать... А то, что ты не знаешь - сам себе уже ответил.:) Все равно РНР выдает предупреждения при отсутствии объявления переменных. Я пишу в стрикте, и эти пердупержения достают. А когда имеешь дело с преобразованием скалярной переменной в массив - то вообще _нужно_ заранее писать array(), а то хрен тебе он преобразуется... По поводу политики отсутствия глобальных переменных - это следствие того, что РНР - язык для хоть и продвинутых, но домохозяек :) "мы мол боимся, что их начнут не так использовать" - цитата разработчика.>PHP has too many functions in the main namespace.
>;) Афтару нужно было не в программисты идти, а в политики. Там
>такие нужны. А то скоро Шуфрича на рыбалку позовут, Черновола на охоту или
>в баню, а дело-то, сам понимаешь, опасное, и место демагогов будет вакантно.
Тут пожалуй соглашусь, НО!!! если бы эти функции реально делали что-то полезное... и если бы они это делали быстро и красиво... а то тот же ХХsort() - сколько их, а зачем? и почему все функции по массивам возвращают массивы, а сорт - работает со ссылкой? Делали бы уж в едином стиле...>PHP lacks abstraction and takes TIMTOWTDI to bad extremes.
>Насчёт абстракций - есть. И по тому списку что там можно пройтись
>критическим взглядом весьма много пересчитав рёбрышек автору. Лень ;)
>Слишкам многа букф.
Опять же, почти соглашусь, с замечанием по поводу единого стиля.Но вот реально, зачем в РНР символ $ перед переменными, если он ровным счетом ничего не определяет??? только мешает. Абсолютно уродская работа со ссылками, при заверении разработчика, что ссылки ничего не ускоряют :) - проверено, ускоряют, но геморрою в коде добавляют изрядно. Работа с массивами и объектами - взято все худшее из жабы и перла, все лучшее удалено нах.
Потом:
* No namespaces
* All functions are global
* No anonymous functions
...
И главное,
Wants to be Perl, but doesn't want to be Perl.Из всего этого я делаю вывод, что РНР - это язык скомпилированных макросов. А не язык программирования.
При всем этом успешно использую его под веб уже 3 года. :)
Ваше сообщение наполнило мое сердце тихой радостью.
Надеюсь, что людей разделяющих ваши взгляды, много.
Ибо чем больше вас, тем выше зарплата у программистов.
>Ваше сообщение наполнило мое сердце тихой радостью.
>Надеюсь, что людей разделяющих ваши взгляды, много.
>Ибо чем больше вас, тем выше зарплата у программистов.
Я действительно буду рад, если твои утверждения, взятые из твоих надежд, оправдаются и/или имеют ненулевые основания под собой в реальности окромя твоего воображения.
Приятно встретить искреннего человека, ага :)
долго можно спорить по поводу читабельности кода и вреда синтаксического мусора. на PERLе конечно бывают безумные конструкции (perlstyle может сильно различаться у разных прогеров), но это интереснее чем на любом языке писать как на фортране - своеобразная изюминка. большое количество скобок (разной степени фигурности :]), все эти $, @, %, &, $$ определяющие тип данных облегчают восприятие
+1
если нормально разобраться, то перл - очень стройный язык.
еще мне нравится в перле (по сравнению с пхп) то, что за свои косяки я отвечаю я сам, а не какой-то дядя из php development team (или как там это у них называется).
к тому же, на перле я могу решать очень большой набор задач, не ограниченных только вебом
если бы перл не поставлялся штатно в системе - вряд ли бы решали свой большой круг задач
А в Windows XP он(Perl) штатно поставляется?
круг задач небольшой, но по сути задачи разные...
Может, по-Вашему, РНР в вендах штатно поставляется? :)
венды вообще не надо приводить в пример. это эмулятор ПК, предназначенный для домохозяек :)
Не подскажете, в какой системе перл поставляется штатно?
>Не подскажете, в какой системе перл поставляется штатно?
Видимо на всех тех, которые вы не видели. Любой Unix-like, начинаю с какой-нибудь солярки 90-х годов.
Любой unix-like?
Во FreeBSD он ставится из портов, точно так же как и PHP.
Подозреваю, что в большинстве дистрибутивов линукса - аналогично.
>Любой unix-like?
>Во FreeBSD он ставится из портов, точно так же как и PHP.
>
>Подозреваю, что в большинстве дистрибутивов линукса - аналогично.правильные подозрения
Из basesystem в фряхе его выкинули только недавно. Весь RELENG_4 прошёл под знаком PERL in basesystem.
>Из basesystem в фряхе его выкинули только недавно. Весь RELENG_4 прошёл под
>знаком PERL in basesystem.
Да и пятёрка, насколько я помню, так же шла с перлом в базе.
Чудесно решаю много задач ВООБЩЕ не связанных с веб (CLI в PHP вы кончно слышали ?)И про косяки - вы сами написали все - и модули и все остальное и отвечаете за них на перле ? И весь перл написан вами ?
В таком случае, ничто вам не мешает писать свои расширения и для PHP. Как и ядро поправить - уж если вы в одиночку смогли полностью переписать все исходники PERL, то уж PHP для вас - просто пару пустяков.
Читайте bugtraq, он ответит на ваш вопрос про косяки.
реализаций PERL много - под windows например 'эктивперл'
приведите пожалуйста пример рабочего кода выполняемого в среде ActivePERL (последних релизов):
создется подключение к 21му TCP порту (банальный FTP) хоста - если в течении одной секунды создать сокет не удалось (порт закрыт), то выдается сообщение типа 'ПНХ!' :)
тогда могу сказать что за часть своих косяков отвечаю сам
ActivePerl и установлен, кусков рабочего кода под рукой нет;разговор не об этом.
просто, когда необходимо производить несколько сотен раз одинаковые операции с разными файлами или сетевыми устройствами(через telnet/snmp/rsh), то написать 50 строк на perl и запустить из командной строки выполнятся(записывая логи) - бывает занимает меньше времени.
Плюс нет опечаток(если аккууратно писать и перед запуском прогнать тест :-))
А перл нужно собирать с поддержкой мускуля?
Надо ставить модуль p5-DBI
Спор ни о чем.
Имхо ПХП - это вообще НЕ ЯЗЫК программирования, это набор макросов в стиле полу-перл,полу-С. Насчет удобства - конечно можно спорить, что лучше - 123786 функций в ядре или 200+817263 модулей. Программы и на ПХП, и на перле могут быть одинаково читаемы и не читаемы, в зависимости от автора, но ПХП по-любому изначально ориентирован на интеграцию в хтмл, и тэги <? ?> читаемости не добавляют, но главное, что меня раздражает в ПХП - то, что везде чувство какой-то недоделанности: то дофига ненужных функций, а нужной нет, то нужная есть, но использовать ее медленнее, чем какой-нибудь аналогичный `...|grep|awk|`. Про зачаточную объектно-ориентированность вообще молчу. А уж документация местами такая, что тошнит по-полной. Пеклы, пеары, модули - черт ногу сломит.
Может, ПХП и станет версии к 10-й полноценным, логичным, документированным и тд., хотя сомнения есть в этом :) А пока для веба приходится использовать такой ПХП, как есть, и мне кажется, что в этой области он лучше всего подходит. Перл же - как более взрослый, лаконичный, быстрый и т.д. - для использования во всех остальных приложениях.
Все было хорошо, пока автор не дошел до HTML elements.
html-код не является php-кодом.
в перле есть минимум три различных способа вывода этих самых html elements (Mason, CGI, Template Toolkit).Да, еще очень хорошо бы смотрелся ниже примерчик PostgreSQL database access.
В перловом коде разница была бы только в одной строке.btw: php умеет работать с placeholders в sql-запросах?