24-й выпуск журнала Pragmatic Perl

Оффтопик-лист, №4: Новости о новых выпусках журналов. По просьбам пользователей.

Оффтопик-лист, №4: Новости о новых выпусках журналов. По просьбам пользователей.

Воистину.

Это не просто новость о выпуске журнала, всё-таки дана информация о содержание выпуска. Кроме того статья о том, что Ларри Уолл объявил, что стабильный релиз Perl 6 выйдет на рождество 2015 - переломный момент в истории Perl и это стоит обсудить.

стабильный релиз Perl 6 выйдет на рождество 2015 - переломный момент в истории Perl

Ну дык напиши об этом подробную новость. А так - оффтоп.

Раньше был ярым задротоп перла, настоящим бичем во плоти... но потом я нашел питон, и жизнь стала в радость! А спустя месяц нашлась и жена. :)

А так - оффтоп.

Шома не согласен. Пруф: 22-й выпуск журнала Pragmatic Perl

Есть и еще одна аналогичная подтвержденная новость — 23-й выпуск журнала Pragmatic Perl

Оффтопик-лист, №4: Новости о новых выпусках журналов. По просьбам пользователей.

Реквестирую анонсы новых выпусков Pragmatic Perl

Мининовость - вполне.

Вот! Предлагаю и остальным перловщикам одуматься и встать на путь исправления.

я почти десять лет назад перешел с перла на питон. мысль о возвращении казалась кошмаром. но недавно включился в проект на перле (некоторые куски кода отмечают 15-летний юбилей, а иные и вовсе конца 90-х). и это… если честно, пофиг. все новое — только на питоне, конечно. хобби — только на питоне + экзотика ради интереса. но в старой перловке рыться не так страшно, как казалось. яп как яп. на восстановление навыков уходит недели две, дальше читаешь/пишешь, не замечая. не хватает исключений, интроспекция сильно затруднена, много неявной хреноты, которую великодушно прощает интерпретатор и которая потом вылезает боком (думаю, в шестерке учли это). но в целом нет смысла переписывать на питоне то, что уже работает. вполне сносный язык и вполне живая экосистема, еще лет пять-десять умирать будет спокойно.

не хватает исключений

Чем тебе die не исключение?

Пусть возьмут еще раз интервью у хозяев CPAN и спросят, что творится в модулях. Пихают всякие cpanmeta, distzilla.ini и прочий шлак. Это к тому, что CPAN превращается в помойку, где любой хранит свои модули для себя, а не для людей. Не можете настроить Distzilla генерировать 100% валидные модули без шлака — не делайте никаких модулей, вообще забудьте про перл. Такими темпами скоро даже сам модуль без distzilla не соберешь. Как пример, Class::Load, Class::Load::XS.

Сама же distzilla это набор из 100+ модулей, причем не самых лучших и не везде собирающихся.

Чем тебе die не исключение?

В питоне есть (расширяемая, ессно) система типизированных исключений: https://docs.python.org/2/library/exceptions.html#exception-hierarchy Её очень удобно использовать для передачи информации. Скажем, функция возвращает True/False, а если что — выкидывает исключение (с текстовым описанием), которое можно поймать и тут же обработать, а можно явно или неявно прокинуть выше по стеку. В результате (при желании) резко упрощаются return values и control flow в принципе. В некоторых веб-фреймворках редиректы, например, реализованы выкидыванием исключения. Пользу сложно объяснить, проще ощутить при ознакомлении. В перле приходится всё-всё таскать туда-сюда в структурах данных (retval из 1/0 превращается, например, в хэшреф с указанием типа ошибки и ее описанием). это усложняет логику, валидацию, создает больше вариантов для ошибок.

А что ТЫ сделал для CPAN-а в свои годы?

Немного. Я конечно понимаю твое раздражение, мол чел ругает якобы не поделу. А попробуй остановить гнев и задуматься, зачем нужны файлы типа dist.ini в архиве CPAN? Dist:Zilla уже входит в стандартную поставку Perl?

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

Можешь заигнорить меня. Рано или поздно вопрос «чистоты» всплывет, только от более авторитетных для тебя дядей и ты их слова примешь на веру. Я же предлагаю подумать над этим самому (если хочешь).

P.S. Разговор на личностях мне не интересен. Хотелось бы услышать критику по делу.

В обоих упомянутых тобой модулях есть Makefile.PL. Или тебя физическое присутствие dist.ini выводит из себя?

тебя физическое присутствие dist.ini выводит из себя?

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

Мой вопрос, насколько сложно написать в MANIFEST.SKIP то, что не относится к делу? Получается, что модуль на CPAN это рабочая версия для системы сборки, а не модуль для Perl.

Кроме того, поскольку это рабочая версия системы сборки, бывает, что необходимые поля в Build.PL, Makefile.PL просто не появляются (забыли перегенерировать файлы)! Зато они есть в cpanmeta, dist.ini и прочих сопуствующих файлах.

--

Update

Мне походу надо писать баг-репорты в Dist::Zilla, т.к. ребята забыли, что после создания модуля, надо делать make manifest && make tardist. И получившийся архив выкладывать на CPAN, а не то, что там нужно системе сборки.

В общем-то я пошутил.
Судя по списку, ты уже основательно «пропитонился».
И умирать перлу необязательно, шестерку наконец выпустят, фичи из нее бэкпортируют в пятую ветку.

не смешно

Действительно не смешно, ведь die и есть полноценные исключения, учитывая то, что в качестве параметра можно передавать объект.

eval {
 if (rand > 0.1) {
   die MyException::Foo->new
 }
 else {
   die MyException::Bar->new
 }
};
if (my $e = $@) {
  warn "foo" if $e->isa("MyException::Foo");
  warn "bar" if $e->isa("MyException::Bar");
}

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

Пусть возьмут еще раз интервью у хозяев CPAN и спросят, что творится в модулях.

Аминь. Некоторые важные модули вообще не собираются. ImageMagick, к примеру.

но это не то же самое, что встроенные в язык исключения.

странная формулировка. eval встроен в perl, die тоже, объекты тоже.

Что, кстати, произойдет при делении на ноль,

на основе предыдущего примера try/catch:

try { 1/0 } catch { /division by zero/ and print "Ahha!" };

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

странная формулировка. eval встроен в perl, die тоже, объекты тоже.

я думаю, главная проблема в том, что «there's always more than one way...» — и на, давай, делай, вперёд. всегда можно сказать, что _теоретически_ в перле реализуема фича X. но на деле обычно есть N реализаций: одна не поддерживается, другая медленная, третья экспериментальная, четвертой не хватает документации, поэтому в половине случаев свои кривые велосипеды, а в половине от греха подальше вообще без этой фичи.

/phooey/ and print «unphooey\n»;

как тут реализовать наследование исключений и матчить по родительскому классу? как цеплять доп. инфо? как обеспечить совместимость со сторонним кодом? а если сообщение изменилось — мы перестаем ловить ошибку? в питоне ответы на все эти вопросы ясны из документации к языку. в перле — _теоретически_ можно бла бла бла.

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

та же ситуация и с ООП, кстати. причем в этом плане пятый еще 10 лет назад был архаичным.

шестерка вряд ли взлетит уже — опять же, лет 10 назад на ура пошла бы. я ее ждал, ждал... не дождался. щас она уже устарела, в мейнстриме есть более ясные языки и на преемственности не сыграть — перл маргинализовался.

интересно, что Гвидо во многом повторил ошибку Ларри, но, вроде, с меньшими последствиями.

(если чо, пишу на обоих языках и обычно не жалуюсь.)

на основе предыдущего примера

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

много неявной хреноты, которую великодушно прощает интерпретатор и которая потом вылезает боком

крайне интересно было бы узнать эти случаи

(почему интересно — у меня есть предположение, что можно спроектировать язык так, что неявная хренота будет делать код более кратким и при этом все же боком вылезать не будет)

я думаю, главная проблема в том, что «there's always more than one way...»

кому баг, кому фича.

как тут реализовать наследование исключений и матчить по родительскому классу? как цеплять доп. инфо? как обеспечить совместимость со сторонним кодом? а если сообщение изменилось — мы перестаем ловить ошибку? в питоне ответы на все эти вопросы ясны из документации к языку. в перле — _теоретически_ можно бла бла бла.

хз что это всё за проблемы, умвр =)

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

а когда единое, да к тому же хреновое - еще хуже :D

шестерка вряд ли взлетит уже — опять же, лет 10 назад на ура пошла бы. я ее ждал, ждал... не дождался. щас она уже устарела, в мейнстриме есть более ясные языки и на преемственности не сыграть — перл маргинализовался.

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

а если нет, и код не помещен в try?

помести его в eval :-D

крайне интересно было бы узнать эти случаи

часть хреноты вынуждает начинать любую программу с «use strict; use warnings». еще часть — всякая аутовивификация, уплощение списков и прочая. я сходу не вспомню.