Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 98
Интересный фреймворк!
Скажите, есть примеры production использования?
К сожалению в последний раз вживую программиста perl я видел только несколько лет назад, боюсь при всех возможных плюсах может быть малый спрос.
Скажите, есть примеры production использования?
К сожалению в последний раз вживую программиста perl я видел только несколько лет назад, боюсь при всех возможных плюсах может быть малый спрос.
Конкретных примеров я лично привести не могу, но можно поискать. Разработчиков на perl сотни тысяч. У нас есть журнал на русском языке, откуда перепечатана эта статья — pragmaticperl.com и другие ресурсы.
Малый спрос на что? Скорее малый спрос на программистов на perl, потому что считается, что язык is dead, но это совершенно не так. Он развивается, следует современным требованиям, коммьюнити очень большое. В 2013-м у нас в Киеве проводилась конференция YAPC, приезжал Larry Wall. Столько программистов на perl в одном здании я не видел никогда. ;)
Новички не учат perl, только потому, что он не в моде. А сам по себе язык очень мощный и классный.
Я собираюсь запустить plack в продакшен уже этой весной для своих нескольких проектах, в том числе, PearlPBX. И тогда смогу показать какие-то результаты.
А вообще о perl я могу рассказывать часами, в одном комментарии не поместится. ;)
Малый спрос на что? Скорее малый спрос на программистов на perl, потому что считается, что язык is dead, но это совершенно не так. Он развивается, следует современным требованиям, коммьюнити очень большое. В 2013-м у нас в Киеве проводилась конференция YAPC, приезжал Larry Wall. Столько программистов на perl в одном здании я не видел никогда. ;)
Новички не учат perl, только потому, что он не в моде. А сам по себе язык очень мощный и классный.
Я собираюсь запустить plack в продакшен уже этой весной для своих нескольких проектах, в том числе, PearlPBX. И тогда смогу показать какие-то результаты.
А вообще о perl я могу рассказывать часами, в одном комментарии не поместится. ;)
Это, конечно, личное дело каждого, на чем писать. Но я вот не вижу никакого развития. И соответствия современным требованиям. Коммьюнити того же питона больше на порядок.
ООП в перл? Смешно.
Функциональщина? Ее нет.
Метапрограмминг? И не начинался.
Версия 5 началась 10 лет назад и тянется до сих пор.
«Write once, read never».
Во всех бенчмарках перл плетется где-то позади. Мой любимый тредринг не может выполнить вообще.
benchmarksgame.alioth.debian.org/u32/benchmark.php?test=threadring&lang=all
Не удивительно, что с такими ввобными приток новых людей в коммюнити стремится к нулю.
ООП в перл? Смешно.
Функциональщина? Ее нет.
Метапрограмминг? И не начинался.
Версия 5 началась 10 лет назад и тянется до сих пор.
«Write once, read never».
Во всех бенчмарках перл плетется где-то позади. Мой любимый тредринг не может выполнить вообще.
benchmarksgame.alioth.debian.org/u32/benchmark.php?test=threadring&lang=all
Не удивительно, что с такими ввобными приток новых людей в коммюнити стремится к нулю.
Уважаемый tgz,
Я не умею и не хочу спорить с оппонентом, который слепо верит в то, что пишет. На тему Вашего комментария у нас в Skype-конференции уже разгорелась жаркая дискуссия. Публиковать цитаты оттуда я не имею желания, потому что меня забанят моментально.
Я уверен в двух моментах:
Я не умею и не хочу спорить с оппонентом, который слепо верит в то, что пишет. На тему Вашего комментария у нас в Skype-конференции уже разгорелась жаркая дискуссия. Публиковать цитаты оттуда я не имею желания, потому что меня забанят моментально.
Я уверен в двух моментах:
- Вы не правы, Google Вам в помощь и прочитайте наш журнал pragmaticperl.com
- Я 17 лет пишу на Perl, в том числе веб-приложения. И за последнее время только Erlang смог завоевать мое уважение и область моей памяти. PSGI/Plack — это отличный метод для разработки быстрых веб-приложений на perl.
Эта статья никоим образом не имеет своей целью разгорание holywar на тему perl vs something else.
Вас никто спорить не заставляет. И почему Вы решили что Вас забанят?
Вот тут habrahabr.ru/post/31074/ никто никого не забанил, все живы, здоровы.
Если Вы пишете, не перл, то на здоровье, я не собираюсь Вас переубеждать. Но надо же понимать почему это так. По ссылке выше есть несколько описанных недостатков перла. Какие их них разрабочики перла решили за последние 10 лет? Вы же утверждаете что перл развивается. Расскажите куда и как.
Вот тут habrahabr.ru/post/31074/ никто никого не забанил, все живы, здоровы.
Если Вы пишете, не перл, то на здоровье, я не собираюсь Вас переубеждать. Но надо же понимать почему это так. По ссылке выше есть несколько описанных недостатков перла. Какие их них разрабочики перла решили за последние 10 лет? Вы же утверждаете что перл развивается. Расскажите куда и как.
По ссылке выше предоставлено не совсем корректное сравнение, IMHO. Детали позвольте опустить.
А пишу я на perl, потому что он мне охрененно нравится. Своей гибкостью, универсальностью и скоростью разработки. Что веб-приложение, что системный демон, что «фиг-знает-что-на-коленке» — пишется быстро.
Если бы я знал все тонкости, читал бы ChangeLog и умел писать качественный материал, то тогда бы я наверное и смог бы рассказать как развивается perl. Но увы, боюсь, что не смогу и только испорчу впечатление. Поэтому я взял статью у коллеги и перепечатал ее здесь. Намерен продолжить, если будет положительный отзыв.
А пишу я на perl, потому что он мне охрененно нравится. Своей гибкостью, универсальностью и скоростью разработки. Что веб-приложение, что системный демон, что «фиг-знает-что-на-коленке» — пишется быстро.
Если бы я знал все тонкости, читал бы ChangeLog и умел писать качественный материал, то тогда бы я наверное и смог бы рассказать как развивается perl. Но увы, боюсь, что не смогу и только испорчу впечатление. Поэтому я взял статью у коллеги и перепечатал ее здесь. Намерен продолжить, если будет положительный отзыв.
Так устроен мир, что у всего есть как достоинства, так и недостатки. В том числе, недостатки есть и у ваших любимых языков программирования. И их тоже устраняют не быстро, если вообще устраняют.
А вы хоть читали, что перл пишет про «ваш любимый треддинг»?
Я вот прогнал на своем ноуте (Intel, core2duo,1200Mhz, ubuntu 12.04.5, perl 5.14.2), получил 18 секунд на 500000. Для сравнения, python3 то же самое — за 10.
Посмотрел на это и решил взглянуть в код — так питоновский код, передавая «токен» из нити в нить, работает с глобальной переменной, а перловый — создает отдельную кучу pipe-ов и через них пишет.
Отличный бенчмарк для сравнения мелкого с мягким, нечего сказать.
PROGRAM OUTPUT:
This Perl not built to support threads
Compilation failed in require at threadring.perl-3.perl line 26.
BEGIN failed--compilation aborted at threadring.perl-3.perl line 26.
Я вот прогнал на своем ноуте (Intel, core2duo,1200Mhz, ubuntu 12.04.5, perl 5.14.2), получил 18 секунд на 500000. Для сравнения, python3 то же самое — за 10.
Посмотрел на это и решил взглянуть в код — так питоновский код, передавая «токен» из нити в нить, работает с глобальной переменной, а перловый — создает отдельную кучу pipe-ов и через них пишет.
Отличный бенчмарк для сравнения мелкого с мягким, нечего сказать.
Какое именно развитие нужно, какие именно современные требования в перле недоступны? Какое развитие получили другие за это время? Питон3?
В перле отличные реализации ООП (Moose / Moo). Чего вам не хватает? Не пользовались?
Метапрограммирование — в чем проблема генерировать код?
Write once, read never — да уж, слезы на глазах, когда такое читаю.
Бенчмарки — не отражают, особенно, если их создает человек, который, например, занет питон хорошо, а перл плохо.
Так-же я могу рассуждать о чем-то, в чем специалистом не являюсь.
И не надо оскорблять чувства верующих, а то всякое бывает.
В перле отличные реализации ООП (Moose / Moo). Чего вам не хватает? Не пользовались?
Метапрограммирование — в чем проблема генерировать код?
Write once, read never — да уж, слезы на глазах, когда такое читаю.
Бенчмарки — не отражают, особенно, если их создает человек, который, например, занет питон хорошо, а перл плохо.
Так-же я могу рассуждать о чем-то, в чем специалистом не являюсь.
И не надо оскорблять чувства верующих, а то всякое бывает.
Лень писать про все.
Остановимся на метапрограмминге, какие есть средства для генерации кода? Питон от версии 1.5 до версии 3 сильно что поимел. А что поимел перл?
Остановимся на метапрограмминге, какие есть средства для генерации кода? Питон от версии 1.5 до версии 3 сильно что поимел. А что поимел перл?
Кодогенерация в перле используется очень широко. Полно С и pure perl расширений, которые это делают.
Ладно, что тут говорить.
Ладно, что тут говорить.
Мы не про то как она используется, а про то, какие средства предоставляет язык.
И говорить тут действительно не о чем.
И говорить тут действительно не о чем.
Надо понимать, что такое перл и какие концепции в нем используются.
TIMTOWTDI — подразумевает, что для кодогенерации вы можете выбрать любой фреймворк из существующих. То-же касается ООП и всего остального.
TIMTOWTDI — подразумевает, что для кодогенерации вы можете выбрать любой фреймворк из существующих. То-же касается ООП и всего остального.
Фреймворк — часть языка?
Какой фреймворк мне позволит модифицировать ast?
Какой фреймворк мне позволит модифицировать ast?
Любой, который может это делать. Ядро перл не ограничивает.
Не часть, в этом и особенность. Какие-то проблемы — выбрать и использовать библиотеку по вкусу?
Не часть, в этом и особенность. Какие-то проблемы — выбрать и использовать библиотеку по вкусу?
То есть в самом языке ничего нет. Что и требовалось доказать.
Дайте ссылку хоть на один фреймворк, который модифицирует ast.
Дайте ссылку хоть на один фреймворк, который модифицирует ast.
А что тут доказывать надо было. Я это и так знаю.
Доступ к псевдокоду вообще не проблема, поищите сами.
Если бы вы решали проблему кодогенерации на перл — вы бы это давно сделали и не разводили тут полемику.
Если вы не умеете это делать на перл или не знаете как — причем тут я?
Доступ к псевдокоду вообще не проблема, поищите сами.
Если бы вы решали проблему кодогенерации на перл — вы бы это давно сделали и не разводили тут полемику.
Если вы не умеете это делать на перл или не знаете как — причем тут я?
Вам самим от этого перлфильтер не смешно?
Регулярные выражения — это да. Вот за это перлу спасибо. Но это когда было?
Регулярные выражения — это да. Вот за это перлу спасибо. Но это когда было?
Нет, мне не смешно. Простите, но мне смешно от вашей статьи с нишей питона в «прототипировании».
А по вашему, имеют значения только открытия недавние?
Спасибо Ритчи за си?
А по вашему, имеют значения только открытия недавние?
Спасибо Ритчи за си?
Ну где модификация ast, в третия раз спрашиваю, раз вам не смешно? Где?
И спасибо Ритчи за Си.
А смеяться над тем, что человек взял удачный для задачи инструмент и успешно ее решил — глупо.
И спасибо Ритчи за Си.
А смеяться над тем, что человек взял удачный для задачи инструмент и успешно ее решил — глупо.
Нет, глупо это ставить в пример то, что не подходит в качестве аргумента.
Что вы прицепились с этим ast. Нам про ваши задачи и инструменты ничего не известно.
Вообще, похоже, вы все это пишите как раз для того, чтобы над вами посмеялись. Грубо обхохотали.
Вообще, похоже, вы все это пишите как раз для того, чтобы над вами посмеялись. Грубо обхохотали.
Вас в гугле забанили? metacpan.org/pod/Compiler::Parser
Нет, не забанили. Требовал точную ссылку, что бы потом не началось виляние жопой, что я не то скачал и там смотрел.
Итого, debian stable, модуль не собирается. Вы сами им пользуетесь? На какой системе?
Лог тут, если что.
dpaste.com/3W9FNR2
Итого, debian stable, модуль не собирается. Вы сами им пользуетесь? На какой системе?
Лог тут, если что.
dpaste.com/3W9FNR2
Что вы доказать-то хотите, уважаемый?
Какова ваша цель?
Какова ваша цель?
Ничего доказывать не хочу. Цель я тут раз 2 уже написал.
А для каких целей вам нужна модификация ast?
Макросы, например.
Макросы реализуются через source filters, ссылку вам дали раньше.
А еще я могу дергать sed скрипт. Ага. Ну перестаньте уже.
Что тут смешного?
Препроцессор так и работает.
Препроцессор так и работает.
Тогда расскажите об этом автору «Modern Perl», который очень переживает что в перле нет аст. Хотя может он лошара и не знает как надо.
Перелистал книгу «Modern Perl» 2010 года в PDF. Не нашел где он об этом жалеет. Дай ссылку, плиз, на конкретную главу, страницу, абзац.
Вам показали реализацию макросов, она не годится, судя по всему, потому, что она написана не на питоне?
Чего еще не хватает?
Вот еще можно такие вещи сделать, например.
Чего еще не хватает?
Вот еще можно такие вещи сделать, например.
Мне показали примитив. Уровня sed 's/a/b/'.
Напишите подобное
github.com/lihaoyi/macropy#tail-call-optimization
раз уж вам все питон покая не дает.
Напишите подобное
github.com/lihaoyi/macropy#tail-call-optimization
раз уж вам все питон покая не дает.
К чему эта агония?
Есть же другие, хорошие, инструменты.
Perl вам не подходит.
Есть же другие, хорошие, инструменты.
Perl вам не подходит.
Люблю читать про
«В Perl нет %featurename%»
«Perl умер»
«Perl никому не нужен»
«Perl не развивается»
К чему я это? Ах, да.
Композиция функций на perl:
«В Perl нет %featurename%»
«Perl умер»
«Perl никому не нужен»
«Perl не развивается»
К чему я это? Ах, да.
Композиция функций на perl:
#!/usr/bin/env perl
use strict;
use warnings;
my $sub = sub {
my $x = shift;
$x++;
return $x;
};
bless $sub, 'HarlemShakeSub';
my $sub2 = sub {
my $x = shift;
$x = $x * 3;
return $x;
};
bless $sub2, 'HarlemShakeSub';
my $sub3 = $sub + $sub2;
print $sub3->(2), "\n";
# 9
package HarlemShakeSub;
use strict;
use warnings;
use overload
'+' => \&harlem_plus
;
sub harlem_plus {
my ($self, $other, $swap) = @_;
return sub {
my $temp = $self->(@_);
$temp = $other->($temp);
}
}
Сравните то же на хаскел.
Причем тут хаскел.
Напишите драйвер на питоне или 3d сцену на пхп.
Перл — язык общего назначения, все, что надо, в нем есть.
Кому-то его тяжело читать — это основной аргумент.
На мой взгяд — это отсутствие профессионализма и неумение пользоваться инструментом.
Напишите драйвер на питоне или 3d сцену на пхп.
Перл — язык общего назначения, все, что надо, в нем есть.
Кому-то его тяжело читать — это основной аргумент.
На мой взгяд — это отсутствие профессионализма и неумение пользоваться инструментом.
При том что хаскел тоже язык общего назначения.
При чем тут драйвера на питоне я не понимаю. Постановка идиотской задачи на другом языке делает перл лучше?
Там выше про наличие метапрограмминга. Хоть что-то похожее на macropy есть?
При чем тут драйвера на питоне я не понимаю. Постановка идиотской задачи на другом языке делает перл лучше?
Там выше про наличие метапрограмминга. Хоть что-то похожее на macropy есть?
Вы приводите примеры, которые выгодно выглядят на хаскеле. Это, по-вашему, делает все остальное хуже в общем.
Попробуйте то на хаскеле, се — на эрланге, это на еще на чем-то, перл по этому гавно (потому, что не хаскел и не эрланг). Правильно?
Не знаю, есть или нет. Если нет — вы можете создать и опубликовать. Тогда и будет.
Попробуйте то на хаскеле, се — на эрланге, это на еще на чем-то, перл по этому гавно (потому, что не хаскел и не эрланг). Правильно?
Не знаю, есть или нет. Если нет — вы можете создать и опубликовать. Тогда и будет.
Так вы уже определитесь, можно ли на Perl делать генерацию, или нет. И очень хотелось бы увидеть нишу Python, правда.
Это пусть последователи перла определятся и расскажут все таки.
Одна из ниш питона
amjith.blogspot.se/2011/09/rapid-prototyping-in-python.html
Одна из ниш питона
amjith.blogspot.se/2011/09/rapid-prototyping-in-python.html
Пройдя по этой ссылке я понял, что питон годится для прототипирования. И что? Что мешает сделать то же самое, например, на perl, lua, или ruby?
Вы точно программист?
Я не только программист, я еще, и, ВНЕЗАПНО, автор этой статьи.
По ссылке автор указан как Amjith Ramanujam. Мы точно про одну и ту же статью говорим?
Автор статьи по Perl, которую мы тут обсуждаем, конечно же.
Ну это, конечно, весомый аргумент.
Если вы программист, то должны понимать, что делать это же вам никто не мешает хоть на си. Только на питоне получается быстро и просто. Эффективнее, если хотите.
Когда же человек не выбирает инструмент под задачу, а пытается решить задачу тем инструментом, который он знает лучше всего, то как правило получается не очень хорошо.
Глупо отрицать что перл безнадежно отстал от жизни. Перл6 наверно самое суровое этому доказательство. В нем задумано много нужных и полезных вещей, которые несоменно пошли бы на пользу. Но где сейчас перл6?
Если вы программист, то должны понимать, что делать это же вам никто не мешает хоть на си. Только на питоне получается быстро и просто. Эффективнее, если хотите.
Когда же человек не выбирает инструмент под задачу, а пытается решить задачу тем инструментом, который он знает лучше всего, то как правило получается не очень хорошо.
Глупо отрицать что перл безнадежно отстал от жизни. Перл6 наверно самое суровое этому доказательство. В нем задумано много нужных и полезных вещей, которые несоменно пошли бы на пользу. Но где сейчас перл6?
А вот тут недавно была еще статья про функции в perl, которая как раз таки и была написана для того, чтобы показать, что Perl 5 таки не устарел и, в принципе, умеет все модные тенденции программирования. Сейчас язык очень даже неплохо развивается.
Естественно, что для каждой задачи нужен свой инструмент, я же ничего не имею против, однако, статья, приведенная вами в пример, не позволяет оценить по достоинству преимущества питона, ибо то, что там написано можно, так или иначе, с аналогичными трудозатратами реализовать на любом другом скриптовом языке программирования.
Таким образом ваши аргументы сводятся к тому, что питон более мягкий, чем перл теплый.
Естественно, что для каждой задачи нужен свой инструмент, я же ничего не имею против, однако, статья, приведенная вами в пример, не позволяет оценить по достоинству преимущества питона, ибо то, что там написано можно, так или иначе, с аналогичными трудозатратами реализовать на любом другом скриптовом языке программирования.
Таким образом ваши аргументы сводятся к тому, что питон более мягкий, чем перл теплый.
Статья и не предполагала что-то доказывать. Просто пример суксесс стори с питоном примененым по месту. Что бы грамотно аргументировать надо писать гораздо больше, чего всем лень. Но примеров такого использования питона много, в интернетах я их вижу регулярно.
Ну а уж веб фреймворков на питоне написано просто запредельное количество. ORM, шаблоны — всего полно, на выбор. Перл же этого дела я последний раз пробовал в 2007 году. Был такой каталист. Потом сменилось место работы и там делали все тоже самое, но на питоне. Разница была видна невооруженным взглядом. Кода получалось больше, качество лучше, начальство довольнее. И сейчас в 2015 я смотрю на перл и понимаю, что он ничем не может заманить меня обратно. Эрланг может. Хаскель может. Даже луа может.
И вот еще что. По долгу службы много общаюсь с разными людьми. Людей ушедших с перла куда то я знаю много. А вот с чего-то ушедших на перл ни одного.
Ну а уж веб фреймворков на питоне написано просто запредельное количество. ORM, шаблоны — всего полно, на выбор. Перл же этого дела я последний раз пробовал в 2007 году. Был такой каталист. Потом сменилось место работы и там делали все тоже самое, но на питоне. Разница была видна невооруженным взглядом. Кода получалось больше, качество лучше, начальство довольнее. И сейчас в 2015 я смотрю на перл и понимаю, что он ничем не может заманить меня обратно. Эрланг может. Хаскель может. Даже луа может.
И вот еще что. По долгу службы много общаюсь с разными людьми. Людей ушедших с перла куда то я знаю много. А вот с чего-то ушедших на перл ни одного.
Вы хоть сами читали эту статью? Перечислены три фичи, которые есть практически у любого скриптового языка. Вау, это, конечно, ниша еще та.
Давайте нормальные примеры, а то не ясно, где-же место питона в современном мире.
Давайте нормальные примеры, а то не ясно, где-же место питона в современном мире.
Нет функциональщины?
Это как? Нет рекурсии?
Или питон содержит очень много «функциональщины» с лямбдами из одного выражения?
И что вообще эта самая «функциональщина» такое?
Это как? Нет рекурсии?
Или питон содержит очень много «функциональщины» с лямбдами из одного выражения?
И что вообще эта самая «функциональщина» такое?
Вспомнил два ярких примера применения perl on the web, правда без plack ( пока ): booking.com, ticketmaster.com
Энтузиасты могут продолжить этот список.
Энтузиасты могут продолжить этот список.
Мне нравится сочетание plack + template toolkit.
Я лично не придерживаюсь строго MVC. А в остальном: данные у меня зачастую в PostgreSQL, шаблоны написаны руками, входящие параметры разбираются «руками», а роутит Plack::Builder.
Посмотрите в сторону Mojolicious, один из разработчиков Каталист сделал очень годную штуку.
Модели, правда, отданы на откуп программисту — я туда, особо не раздумывая (после нескольких лет опыта с MS C# MVC) воткнул слой запросов через DBI.
За неделю, без знаний Perl, Mojo, PostgreSQL написал вполне годный блого-движок с бутстрапом на фронтенде, без статических страниц как в вордпрессе, получилось совсем немного кода.
Если использовать его как json/xml/etc API на стороне сервера, то фронт можно вообще писать на каком-то JS-Фреймворке, без всяких проблем.
Модели, правда, отданы на откуп программисту — я туда, особо не раздумывая (после нескольких лет опыта с MS C# MVC) воткнул слой запросов через DBI.
За неделю, без знаний Perl, Mojo, PostgreSQL написал вполне годный блого-движок с бутстрапом на фронтенде, без статических страниц как в вордпрессе, получилось совсем немного кода.
Если использовать его как json/xml/etc API на стороне сервера, то фронт можно вообще писать на каком-то JS-Фреймворке, без всяких проблем.
Коля, твой любимый Mojolicious, равно как и просто Mojo — это здоровенный overhead для меня. Plack для меня более чем достаточен.
Ответ? PSGI уже был когда о ноде и слыхом не слыхивали, мне кажется.
Это не ответ ноде.
А потом я находил бенчмарки Plack и WSGI. Там выходило что perl web app на Plack работает медленнее чем на WSGI реализации. Но это из-за того что Plack/Starman писаны на Perl'е, а в Python'е эти задачи уже оптимизированы и на писаны частично на C. Хотя на perl'е уже тоже есть XS сервера, так что совсем новых тестов я не видел.
PSGI and Plack are inspired by Python's WSGI and Ruby's Rack
А потом я находил бенчмарки Plack и WSGI. Там выходило что perl web app на Plack работает медленнее чем на WSGI реализации. Но это из-за того что Plack/Starman писаны на Perl'е, а в Python'е эти задачи уже оптимизированы и на писаны частично на C. Хотя на perl'е уже тоже есть XS сервера, так что совсем новых тестов я не видел.
Всё-таки нет ответа на старый вопрос: какие новые возможности предоставляет psgi по сравнению с fastcgi?
В FastCGI взаимодействие с сервером происходит через TCP/IP или Unix Domain Socket. Теперь у нас есть PSGI.
И что, psgi работает напрямую через мозг? Цепочка nginxPSGI не по tcpip и больше не нужна?
Что содержит psgi сервер (Plack::Builder к примеру), чего не умеет Mojolicious, при том что Mojo — полноценный фреймворк? А чего не содержит Plack::Builder
И наконец… где он реально используется? И почему там не использовали Mojolicious?
В FastCGI взаимодействие с сервером происходит через TCP/IP или Unix Domain Socket. Теперь у нас есть PSGI.
И что, psgi работает напрямую через мозг? Цепочка nginxPSGI не по tcpip и больше не нужна?
Что содержит psgi сервер (Plack::Builder к примеру), чего не умеет Mojolicious, при том что Mojo — полноценный фреймворк? А чего не содержит Plack::Builder
И наконец… где он реально используется? И почему там не использовали Mojolicious?
Понтий видимо не читает материал? ;-)
Именно, что напрямую, через мозг. Никаких nginx не надо.
А для меня лично mojo* слишком монстроидален, в отличие от простого plack.
Именно, что напрямую, через мозг. Никаких nginx не надо.
А для меня лично mojo* слишком монстроидален, в отличие от простого plack.
Сколько запросов в секунду выдаст PSGI без Nginx, если каждый запрос порождает 10 килобайт и генерируется в течении 0.001 секунды, скорость соединения с каждым клиентом 10 килобайт в секунду, памяти на сервере 1 гигабайт, выходная линия беспредельной пропускной способности?
Понятия не имею :-) если когда-нибудь потребуется узнать, то узнаю. А пока просто не интересно.
Тогда как можно всерьёз обсуждать PSGI? Хоть какие-то характеристики должны быть представлены, кроме меньшей монстроидальности. Кстати, насчёт монстроидальности — Plack от Mojolicious отличается в меньшую сторону всего на 20 процентов, его функциональность размазана на 20 сторонних модулей. То есть и монстроидальности никакой нет.
А я и не обсуждаю его всерьез. Я вообще не парюсь. Мне понравилось это сочетание. Я захотел об этом написать. Но поскольку писать статьи я толком не умею, то перепечатал статью другого, с его разрешения.
Намерен продолжать. Хотя бы ради популяризации perl.
PS. Plack мне больше понравился, чем все остальное. Поэтому я его выбрал. Это единственная причина. Все остальное не существенно.
Намерен продолжать. Хотя бы ради популяризации perl.
PS. Plack мне больше понравился, чем все остальное. Поэтому я его выбрал. Это единственная причина. Все остальное не существенно.
PSGI и Plack — это не вебсервера. Это стандарт бекэнда. Он описывает откуда читать заголовки и тело запроса, куда писать ответ и т.д. Разные сервера предоставляют это окружение по-своему, PSGI все приводит к одному виду.
Прочтите на CPAN 3 абзаца и все будет ясно.
Plack — это один из вариантов реализации PSGI интерфейса для приложений.
Прочтите на CPAN 3 абзаца и все будет ясно.
Plack — это один из вариантов реализации PSGI интерфейса для приложений.
Интерфейс CGI является стандартом, при том единственным стандартом. Чтобы воспользоваться PSGI, сначала надо сделать и обработать CGI запрос, потом преобразовать его в PSGI форму, выполнить, потом PSGI ответ преобразовать в стандартный для CGI/HTTP формат, отдать браузеру. Откуда взялась необходимость в PSGI, какие он даёт удобства? Я от очередной статьи про ЗЫПШ ждал ответы на вопросы, а не декларации.
В современном мире вряд ли кому-то придет в голову выполнять традиционные CGI-приложения, если мы не вспоминаем про разные странные штуки типа веб-морды роутера. Сделать и обработать CGI-запрос? Но зачем? Вы выше упоминали FCGI, он ведь не требует выполнения CGI-запроса, правда? Вот и PSGI этого не требует. Так же как и HTTP-протокол в обоих случаях несколько «сбоку» находится. Оверхед по сравнению с чистым FCGI (или чем-то другим), безусловно, у Plack есть, это правда. Но и FastCGI станет оверхедом по сравнению с веб-сервером, который будет выполнять Ваш perl внутри себя и сразу отдавать ответ юзеру, а не разговаривать с аппликейшном по сокету. Все относительно
PSGI — это всего лишь протокол (стандарт) взаимодействия веб сервера с самим приложением, не важно FCGI это, CGI или, допустим, mod_perl.
Если ваше приложение использует интерфейс PSGI (не важно, какой реализации, Plack или свое или какой-то фреймворк, Mojo, Dancer, Catalyst) — значит его можно будет без проблем (без доп. интеграции) запустить под управлением любого сервера, использующего PSGI со своей стороны.
Т.е. написав web приложение вам не надо сосредотачиваться на особенностях FCGI интерфейса или mod_perl и т.д… Интерфейс получения запроса от сервера и отдачи данных один — PSGI.
Вот и все.
Если ваше приложение использует интерфейс PSGI (не важно, какой реализации, Plack или свое или какой-то фреймворк, Mojo, Dancer, Catalyst) — значит его можно будет без проблем (без доп. интеграции) запустить под управлением любого сервера, использующего PSGI со своей стороны.
Т.е. написав web приложение вам не надо сосредотачиваться на особенностях FCGI интерфейса или mod_perl и т.д… Интерфейс получения запроса от сервера и отдачи данных один — PSGI.
Вот и все.
Т.е. написав web приложение вам не надо сосредотачиваться на особенностях FCGI интерфейса или mod_perl и т.д… Интерфейс получения запроса от сервера и отдачи данных один — PSGI.
mod_perl мёртв, о нём думать давно не нужно. А остальное не имеет вообще никаких особенностей. Интерфейс один — CGI. Запускаемый под любым сервером и так далее по Вашему тексту.
mod_perl мёртв, о нём думать давно не нужно. А остальное не имеет вообще никаких особенностей. Интерфейс один — CGI. Запускаемый под любым сервером и так далее по Вашему тексту.
Не все так просто на деле.
Есть стриминг, например.
Разные хендлы для чтения / записи.
Разные подходы к наименованию HTTP хедеров.
Много всяких ньюансов.
PSGI все приводит к одному знаменателю. В общем — удобно, не вижу смысла не использовать, одни плюсы.
Есть стриминг, например.
Разные хендлы для чтения / записи.
Разные подходы к наименованию HTTP хедеров.
Много всяких ньюансов.
PSGI все приводит к одному знаменателю. В общем — удобно, не вижу смысла не использовать, одни плюсы.
Я прошу привести хотя бы один плюс, а в итоге:
Есть стриминг, например.
Что это такое?
Разные хендлы для чтения / записи.
Они везде разные, что тут необычного?
Разные подходы к наименованию HTTP хедеров.
А это что такое? Зачем их именовать по разному?
Есть стриминг, например.
Что это такое?
Разные хендлы для чтения / записи.
Они везде разные, что тут необычного?
Разные подходы к наименованию HTTP хедеров.
А это что такое? Зачем их именовать по разному?
Да ладно, на самом деле метод работы веб-приложения — это выбор программиста. У меня в некоторых проектах до сих пор CGI.pm через обычный CGI вызывается. И что? Да, тормозит по современным меркам, но в данном случае это не критично.
FastCGI мне как-то по душе не пришелся. Особенно после использования Erlang/cowboy/n2o.
А вот PSGI в сочетании с Plack пришелся по душе. Я еще планирую написать свой упрощенный аналог n2o для PSGI. Идея классная.
FastCGI мне как-то по душе не пришелся. Особенно после использования Erlang/cowboy/n2o.
А вот PSGI в сочетании с Plack пришелся по душе. Я еще планирую написать свой упрощенный аналог n2o для PSGI. Идея классная.
Плюс — не нужно заморачиваться о реализации сервера. PSGI-сервер это контейнер, что удобно. Можно, совершенно без проблем, взять любой psgi сервер и запустить на нем свое приложение. Могут понадобиться ОЧЕНЬ незначительные доработки.
Еще плюс — механизм Middleware, что предлагает удобный механизм пре-процессинга и пост-процессинга.
Например, механизм редиректа тепло и прельстиво сделать именно в мидлварине.
Стриминг это механизм отложенного ответа, который необходим для того, чтобы можно было использовать callback-style при написании кода, что облегчает написание всякой асинхронщины, AnyEvent, например, становится как влитой.
Еще плюс — механизм Middleware, что предлагает удобный механизм пре-процессинга и пост-процессинга.
Например, механизм редиректа тепло и прельстиво сделать именно в мидлварине.
Стриминг это механизм отложенного ответа, который необходим для того, чтобы можно было использовать callback-style при написании кода, что облегчает написание всякой асинхронщины, AnyEvent, например, становится как влитой.
> Т.е. написав web приложение вам не надо сосредотачиваться на особенностях FCGI интерфейса или mod_perl и т.д… Интерфейс получения запроса от сервера и отдачи данных один — PSGI.
Именно. У нас есть REST API и прошлым летом мы поняли что mod_perl совсем достал. Стали думать на что переписывать… А потом просто переписали под Plack и получили возможность запускать наш код и на FCGI и на Starman и на mod_perl и на всех остальных серверах. Причем переключение делается элементарно.
Именно. У нас есть REST API и прошлым летом мы поняли что mod_perl совсем достал. Стали думать на что переписывать… А потом просто переписали под Plack и получили возможность запускать наш код и на FCGI и на Starman и на mod_perl и на всех остальных серверах. Причем переключение делается элементарно.
Некорректно сравнивать FCGI с PSGI, PSGI работает поверх FCGI.
Так-же некорректно сравнивать PSGI и Mojo. Mojo, как и любой другой фреймворк, может реализовывать PSGI или нет.
По сути PSGI говорит — ваше приложение это функция, которая на вход получает запрос и должна вернуть ссылку на массив [код ответа, [headers], [body]], остальное не ваша забота.
Сейчас надо разрабатывать только под PSGI интерфейс, его все поддерживают, снимает ненужный гемор.
Так-же некорректно сравнивать PSGI и Mojo. Mojo, как и любой другой фреймворк, может реализовывать PSGI или нет.
По сути PSGI говорит — ваше приложение это функция, которая на вход получает запрос и должна вернуть ссылку на массив [код ответа, [headers], [body]], остальное не ваша забота.
Сейчас надо разрабатывать только под PSGI интерфейс, его все поддерживают, снимает ненужный гемор.
PSGI это всего лишь интерфейс, по которому вы строите свое приложение. Вы не знаете и не думаете о том, каким образом результаты работы этого приложения доходят до пользователя — может быть, эти результаты сразу же каким-нибудь starman'ом переводятся в форму HTTP-протокола, а может быть они отдаются по FastCGI или uWSGI в нжинкс, а в HTTP их переводит уже он. Вы просто не думаете об этом, вы пишите функцию, которая имеет аргументы и возвращаемое значение. Это очень просто, и это очень важно. Все плюсы PSGI и Plack основываются именно на этом факте. Итак, плюс номер один — вы не думаете о том, какой вебсервер будет крутить ваши приложения.
Plack — это модули, реализующие PSGI на perl. Кроме собственно поддержки вышепомянутой функции-приложения Plack включает в себя ряд достаточно интересных интерфейсов, которые позволяют упростить написание этих самых приложений. Вообще то, что вы имеете дело с функцией, позволяет вам делать разные забавные штуки, такие как заворачивание вашeй функции-приложения в декораторы, которые в Plack называются Middleware. Сделать, чтобы раздел сайта открывался только зарегистрированным пользователям? Легко, пишем класс Middleware из десятка строчек, и заворачиваем в него ваш раздел сайта. Каждое из ваших приложений в результате своей работы выплевывает шаблон? Окей, давайте возвращать из приложения имя шаблона и набор шаблонных переменных, и пусть его приводит к стандарту PSGI еще один простенький декоратор. Вот вы уже отошли от интерфейса PSGI и сделали свой собственный интерфейс для своих собственных приложений — с другим возвращаемым значением. Далее. Plack вводит интерфейс Plack::Component, который легким движением руки приводится к форме PSGI-приложения, но дает вам возможность использовать наследование при написании приложений. Все это вместе (назовем это «удобным инструментарием разработки») — плюс номер два, имхо на практике он гораздо интереснее первого.
Я сейчас не говорю, что вы можете здесь сделать что-то, что не умеет Mojo или CGI. Вы можете сделать все что угодно и там, и там, была бы голова. По старым вашим комментариям к околоперловым темам я помню, что она у Вас есть, а значит все это не проблема :) Я точно знаю, как сделать раздел сайта на CGI-скриптах открытым только для залогиненных юзеров, но реализация эта тошненькая по нынешним временам. А под Plack это чуть ли не лучшая иллюстрация возможностей. И Plack в отличие от Mojo — узконаправленный инструмент, не берущий на себя слишком много. Лично мне под Mojo неуютно жить, а под Plack — в самый раз. Вам, возможно, наоборот, это нормально, нет смысла ломать тут копья.
И по поводу размера. В составе Plack значительное количество модулей — реализации всяких Middleware & Applications, типа отдачи статики с диска, поддержки «старообрядческих» каталогов с CGI, автоподгрузка измененных на диске перломодулей, поддержка Basic Auth и прочей чепухи, как правило, совершенно бесполезной на продакшне (но весьма помогающий разобраться в авторском подходе к работе с Plack). Плюс поддержка различных нужных и ненужных бэкенд-серверов (CGI/FastCGI/mod_perl итд). Плюс поддержка функциональных тестов. Если весь этот треш выбросить (а можно не выбрасывать, лишнее не загрузится), Plack очень и очень сильно похудеет. Признаться, я не понимаю, почему автор сложил сразу все в одну кучу, но автор — он, пусть делает как считает нужным.
Plack — это модули, реализующие PSGI на perl. Кроме собственно поддержки вышепомянутой функции-приложения Plack включает в себя ряд достаточно интересных интерфейсов, которые позволяют упростить написание этих самых приложений. Вообще то, что вы имеете дело с функцией, позволяет вам делать разные забавные штуки, такие как заворачивание вашeй функции-приложения в декораторы, которые в Plack называются Middleware. Сделать, чтобы раздел сайта открывался только зарегистрированным пользователям? Легко, пишем класс Middleware из десятка строчек, и заворачиваем в него ваш раздел сайта. Каждое из ваших приложений в результате своей работы выплевывает шаблон? Окей, давайте возвращать из приложения имя шаблона и набор шаблонных переменных, и пусть его приводит к стандарту PSGI еще один простенький декоратор. Вот вы уже отошли от интерфейса PSGI и сделали свой собственный интерфейс для своих собственных приложений — с другим возвращаемым значением. Далее. Plack вводит интерфейс Plack::Component, который легким движением руки приводится к форме PSGI-приложения, но дает вам возможность использовать наследование при написании приложений. Все это вместе (назовем это «удобным инструментарием разработки») — плюс номер два, имхо на практике он гораздо интереснее первого.
Я сейчас не говорю, что вы можете здесь сделать что-то, что не умеет Mojo или CGI. Вы можете сделать все что угодно и там, и там, была бы голова. По старым вашим комментариям к околоперловым темам я помню, что она у Вас есть, а значит все это не проблема :) Я точно знаю, как сделать раздел сайта на CGI-скриптах открытым только для залогиненных юзеров, но реализация эта тошненькая по нынешним временам. А под Plack это чуть ли не лучшая иллюстрация возможностей. И Plack в отличие от Mojo — узконаправленный инструмент, не берущий на себя слишком много. Лично мне под Mojo неуютно жить, а под Plack — в самый раз. Вам, возможно, наоборот, это нормально, нет смысла ломать тут копья.
И по поводу размера. В составе Plack значительное количество модулей — реализации всяких Middleware & Applications, типа отдачи статики с диска, поддержки «старообрядческих» каталогов с CGI, автоподгрузка измененных на диске перломодулей, поддержка Basic Auth и прочей чепухи, как правило, совершенно бесполезной на продакшне (но весьма помогающий разобраться в авторском подходе к работе с Plack). Плюс поддержка различных нужных и ненужных бэкенд-серверов (CGI/FastCGI/mod_perl итд). Плюс поддержка функциональных тестов. Если весь этот треш выбросить (а можно не выбрасывать, лишнее не загрузится), Plack очень и очень сильно похудеет. Признаться, я не понимаю, почему автор сложил сразу все в одну кучу, но автор — он, пусть делает как считает нужным.
Круто… раньше хабр раз в пол года почитывал на предмет новых статей по perl и вгонялся в состояния уныния. Пол года назад переключились на Plack, но даже мысли не было написать статьи на русском об этом ибо было полное ощущение Perl is dead и это тупо никому не нужно будет )
> mount "/reverse" => builder { $reverse_app };
> mount "/" => builder { $app; };
Для разных путей (/, /reverse и т.п.) назначаются заранее приготовленные процедуры.
Для некоторых простых задач это может быть удобно.
А если у меня урлы на сайте формируются динамически так, что на этапе написания программы мне все эти урлы будут неизвестны, то такой подход (назначение определённым урлам заранее приготовленных процедур) кажется уже не таким уж удобным способом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в разработку web-приложений на PSGI/Plack