1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie. Узнать больше.

Perl vs PHP

Тема в разделе "Софт", создана пользователем Vaulter, 20.11.03.

  1. Vaulter

    Vaulter Активный участник

    1.622
    0
    плюсы минусы...:p:
    один из минусов перла насколько мне известно - для работы с mySQL надо подключать модуль (там же все на модулях)
    один из минусов PHP - скорость
     
  2. VL

    VL Участник

    1.695
    0
    Vaulter

    Вроде все наоборот. ПХП выигрывает в скорости когда библиотеки установлены как модули.
     
  3. Гадский Поттер

    Гадский Поттер Читатель

    5.138
    0
    VL , не-а. И памяти он при этом жрёт - "мама не горюй"...
    Vaulter , а в чём минус перла "надо подключать модуль"?
     
  4. Vaulter

    Vaulter Активный участник

    1.622
    0
    Гадский Поттер
    в том что лень...
    в PHP уже то все есть.
    а программисты как известно ленивый народ )
     
  5. luka

    luka Активный участник

    704
    0
    Мля... а давайте сравним во сколько раз perl обойдёт по всем параметрам подделку под ЯП, если юзать mod_perl?
     
  6. Облом

    Облом Участник

    442
    0
    luka
    Не забудьте ещё посчитать, сколько при этом у вас будет занимать в памяти один процесс httpd и сколько времени у него на fork'и будет уходить. И тогда встанет вопрос КПД. Плюс затраты на переделку скриптов под mod_perl и т. д.

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

    Облом добавил [date]1069387410[/date]:
    Vaulter
    Это вопрос идеологический. PHP проще в изучении, безуловно. Минус его, однако, в том, что непросто расширить его функциональные возможности. В этом смысле модульность Перла является плюсом.

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

    А в смысле производительности на стандартных задачах PHP обычно обходится выгоднее.

    Если нужно написать Яandex, то лучше брать Perl и запускать его через mod_perl. Но тут уже масса специфических деталей возникает. И сервер должен быть готов выдерживать большую нагрузку, опять же.
     
  7. jekaRU

    jekaRU Активный участник

    3.064
    0
    Перл,в принципе, по умолчанию обладает большими возможностями... PHP - "personal homepage" расшивфровывалось изначально.. теперь правда "PHP processor"
    тут уж кому что... php +1 ;)
     
  8. Drap

    Drap Читатель

    376
    0
    имхо php ~ perl

    всё что можно сделать на perl можно и на php

    Минусы perl:
    все скрипты должны лежать в cgi-bin
    обязательно знать путь к perl (usr/bin/perl или usr/sbin/perl)
    библиотеки

    Плюсы php:
    сессии
    встроенные функции
    ...

    тем не менее я использую perlовские регулярные выражения preg_replace() в написании php скриптов :)
     
  9. luka

    luka Активный участник

    704
    0
    Drap, скриптам пофиг где лежать, почитай доку к апачу. Путь к перлу не обязательно знать. Что библиотеки???

    Из плюсов пхп: что сессии??? что встроенные функции???
     
  10. Облом

    Облом Участник

    442
    0
    luka
    без паники :-)) вы тока не нервничайте :-)) PHP в самом деле проще в освоении, в основном за счёт того, что большинство тех функций, для которых к Перлу нужно подключать дополнительные модули (DBI, Sessions) и т. д., в PHP встроены и синтаксис их максимально упрощён :-)

    Drap
    Ну, почти всё можно сделать в PHP, но не всё. В частности, довольно геморройно писать системные приложения. Типа всяких панелей управления хостингами и управления эл. почтой. Просто потому что если нет доступа к CGI-версии PHP (очень частое явление), то не получится получить чужих прав. Или получится, то как-то геморройно.
     
  11. Vaulter

    Vaulter Активный участник

    1.622
    0
    Облом

    не скажи, все оч просто и в понимании, и в написании.....
    единственный геммор, это с разложением самого тела письма и его заголовков (но это и в Перле тоже такой же геммор) ;)

    кстати, минус PHP как модуля Apache - права у него будут Apacheвские...
    у перла незнаю ;)
     
  12. Облом

    Облом Участник

    442
    0
    Vaulter
    Я не имел ввиду обработку электронной почты :-)) Я перечислил эту задачу в числе системных :-)

    Для всяких фокусов с правами CGI в Apache 1.3 есть замечательные параметры User и Group. В Apache 2 пока не искал аналогов. Кажется, нужно другой mpm использовать. Но это уже другая история совсем...
     
  13. Nekto

    Nekto Почётный

    5.712
    0
    Хи-хи...
    Скажите. А что лучше? Паскаль или СИ? Пустой разговор...
    Чток касается Яндеска, то для подобных нагрузок интерпретаторы использовать не стоит. Я бы писал подобный движок на С++. Если нагрузки на порядок ниже (поиск по сайтам региона), то как perl, так и php справяться замечательно. Главное хороший сервер. И не кривые руки программера. Ну и БД хорошая. MySQL и ее реализация (ИМХО) полнотекстового поиска оставляет желать лучшего... Только не говорите про like...

    Скрипты могут у perl лежать где угодно. Как Апач настоить.

    Разложить письмо по заголовкам на Perl не сложно. Модули... На php - не знаю, не сталкивался.
    Облом

    Угу.

    Что меня добивает в perl - это синтаксис печати. На мой взгляд у php это реализованно удобнее.
    Ну и в логи лазить надо, в отличае от php.
    use CGI::Carp qw (fatalsToBrowser);
    Помогает далеко не всегда...

    А вообще, что по мне, так лучше всего - Java. Интересный язык. Хотя Perl - привычнее всего для меня.
     
  14. Drap

    Drap Читатель

    376
    0
    насколько я знаю скрипт индекса на Яndex написан на c++
    ps. ^ насколько я знаю:D
     
  15. Nekto

    Nekto Почётный

    5.712
    0
    Drap, насколько я знаю - именно на нем.
    И к нему была разработанна собственная БД.
     
  16. luka

    luka Активный участник

    704
    0
    Nekto, да и у гугла собственная БД. А зачем для этого универсальная БД... Из более приличных тяжеловесы только подойдут.
     
  17. Nekto

    Nekto Почётный

    5.712
    0
    luka, такие нагрузки не думаю, что даже Oracle выдержит... Так что, думаю выход один, действительно
     
  18. luka

    luka Активный участник

    704
    0
    Nekto, Оракл и любая другая БД явно из-за своей универсальности уступают самописной БД...
     
  19. Drap

    Drap Читатель

    376
    0
    2luka



    Подумай, прежде чем говорить, а если не знаешь то лучше молчи

    Стоймость лицензированной установки oracle9i на двухпроцессорный сервер около 85 тысяч У.ё, а то что она выдержит почти любой запрос я уверен на 99%

    ps. лучше oracle только mysql (патамучта бесплатный!!!)
    :) :) :)
     
  20. Nekto

    Nekto Почётный

    5.712
    0
    Drap

    Откуда такие сведенья? У меня сведенья о сумме в 8 раз меньшей. И она опримизированна на иные нагрузки. Я конечно уважую БД Oracle, но для полнотесктовых поисков у нее слишком мало возможностей и функций.
    Да, Oracle действительно выдержит запрос. Вопрос во времени выполнения... И оптимизации работы БД под этот фактор.
     
  21. luka

    luka Активный участник

    704
    0

    pgsql тоже бесплатный. Ты ещё скажи, что mysql лучше, чем pgsql. Бесплатных БД много больше, чем mysql.

    Под какие-то чётко определённые цели лучше иметь свою БД. Я имею в виду не распространённые задачи, а узкий круг специализированных. Не в деньгах дело. Я сомневаюсь, что www.google.com не могут позволить купить Oracle, но я сомневаюсь, что им нужна его гиперуниверсальность. От БД поисковой машины требуются чётко определённые цели. С учётом этих целей пишется БД, в которой внимание будет уделяться скорости обработки конкретных запросов.
     
  22. Drap

    Drap Читатель

    376
    0
    говорю
     
  23. Nekto

    Nekto Почётный

    5.712
    0
    Drap, ты не прав...
     
  24. Vaulter

    Vaulter Активный участник

    1.622
    0
    Nekto
    Drap
    да ну вы че ребята!...1. оффтопим 2. сравниваете такие вещи.....(типа HTML и XML).
    задачи то у Оракл и mySQL разные.....
    Оракл прежде всего это корпоративная БД, предназначеная прежде всего для обслуживания всех областей деятельности промышленного или иного предприятия....,не считая ОГРОМНЫЙ парк SQL администрирования БД
    а mySQL это заточенная штука под WEB технологии - быстрые запросы (относительно ;) )...равно как и отсутвие триггеров, процедур и остального...

    да и не забывайте, сколько лет на рынке одна БД и сколько другая ;)
     
  25. luka

    luka Активный участник

    704
    0
    Пара писем по теме...

    = RU.PERL (2:5055/201.26) =====================================================
    Msg : 115 of 118
    From : Andrew Velikoredchanin 2:5026/29 01 января 70, 00:00
    To : Alex Vader
    Subj : возможности PERL
    ===============================================================================
    Пpивет, Alex !

    Вторник Декабрь 09 2003, Alex Vader пишет к All:

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

    ...

    AV> Поясните пожалуйста, чем так хорош PERL ,что получил такое
    AV> распространение?
    AV> Что на нем удобно и легко делать? Что на нем делать нельзя или неудобно?

    AV> только просьба - без религиозного фанатизма

    ОК! Постараюсь. :)

    Из преимуществ:
    1. Модульная структура. Hа cpan.org ты можешь найти модули на все случаю жизни.
    2. Через mod_perl ты можешь использовать внутренние средства апача очень гибким
    образом. Я например, написал для своего сайта систему авторизации через кукесы
    (знаю что есть готовые - мне хотелось свою сделать :). Hа основе примеров это
    делается довольно просто. :) В общем в mod_perl вкусностей довольно много.
    Главное все их изучить. :)
    3. Hе факт, но по некоторым описаниям выходит, что перл работает быстрее PHP.
    4. Для разделения кода и HTML совнтую сразу использовать систему обработки
    шаблонов Template Toolkit. Я сначала делал все напрямую, сейчас все равно
    приходиться переходить на нее. :) Система довольно гибкая и удобная.

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

    С уважением, Andrew.

    --- GoldED+/LNX 1.1.4.7
    * Origin: (2:5026/29)

    = RU.PERL (2:5055/201.26) =====================================================
    Msg : 118 of 118
    From : Artem Chuprina 2:5020/400 01 января 70, 00:00
    To : Alex Vader
    Subj : Re: возможности PERL
    ===============================================================================
    From: Artem Chuprina <ran+news@ran.pp.ru>

    Alex Vader @ Mon, 8 Dec 2003 21:45:22 +0000 (UTC):

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

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

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

    AV> Что на нем удобно и легко делать? Что на нем делать нельзя или неудобно?

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

    --
    Artem Chuprina
    RFC2822: <ran@ran.pp.ru>, FIDO: 2:5020/122.256, ICQ: 13038757
    --- ifmail v.2.15dev5.1
    * Origin: Leninsky 45 home network (2:5020/400)