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

Родной вернитесь! Ваш код работает очень хорошо, но я нифига не понял.

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

Я убогий кодер на C/C++, но нежно люблю perl.

Рекомендую почитать книгу «Программирование на Perl» за авторами Ларри Уолла, Тома Кристиансена и Джона Орванта (есть и на русском). Perl действительно хорош и, в отличии от других ЯП, он действительно стоит того чтобы разобраться в нем. По крайней мере, сих пор еще мне не известны объективные критерии (субъективные не берем в рассчет) по которым можно было бы основательно утверждать что знаковая система perl5 уступает какому-то существующему ЯП.

Кстати, есть кто-нибудь кто использует или использовал модуль AI::Prolog? Нужен эксперт.

А теперь сделайте бенчмарк и сравните насколько быстро работает ваш tie vs обычное присвоение/обращение к значению по индексу массива. Да, так можно решить вопрос потребления памяти, только теперь возникла проблема чрезмерного вызова функций-оберток.

Будете дальше спорить о том почему некие дяди (для вас неосиляторы перла//осиляторы си+xs) придумали Bit::Vector? Да, именно такие дяди и знают мощь перла, а не теоретики вроде вас.

Кстати, есть кто-нибудь кто использует или использовал модуль AI::Prolog? Нужен эксперт.

Ммм. Сначала всех тут обозвал неосиляторами, а как чуть что — тут все эксперты. Хам вы, сударь.

если одновременно гнаться за эффективными хранением и скоростью доступа к отдельным элементам, то встроенный vec будет быстрее Bit::Vector (чтение ~ 5x)

p.s. Perl тем и хорош, что TIMTOWTDI/BSCINABTE :)

Будете дальше спорить о том почему некие дяди (для вас неосиляторы перла//осиляторы си+xs) придумали Bit::Vector? Да, именно такие дяди и знают мощь перла, а не теоретики вроде вас.

Bit::Vector перегружен и использовать его не совсем оптимально для хранения, особенно если вы используете integer/Math::BigInt или Math::GMP. А если стоит вопрос пиковой производительности и минимального потребления памяти, то Bit::Vector тоже не лучший вариант.

А теперь сделайте бенчмарк и сравните насколько быстро работает ваш tie vs обычное присвоение/обращение к значению по индексу массива. Да, так можно решить вопрос потребления памяти, только теперь возникла проблема чрезмерного вызова функций-оберток.

Я и не ставил целью приближаться к Си по потреблению памяти и скорости исполнения одновременно. Я лишь вам показал что в рамках базовых свойств языка решается проблема ~3x потребления памяти на ваши заявления про «128 Гб против десятка мегабайт на 100млн чисел». Я хотел показать что вы не умеете использовать perl и показал это, но тут вы резко переключились на вопрос исполнения кода. Этот вопрос тоже решаемые, но тратить время на вас я больше не намерен.

Ммм. Сначала всех тут обозвал неосиляторами, а как чуть что — тут все эксперты. Хам вы, сударь.

Вы тоже очень неаккуратный в беседе. Во-первых, я не говорю что тут все «неосиляторы», но вас много. Во-вторых, я не говорил что тут все эксперты. Я же пишу: «Нужен эксперт». Я допускаю что среди читающих тред есть эксперт по использованию AI::Prolog. Разберитесь с тем что у вас происходит в голове.

От фраз: все яп говно, а perl - самый лучший даже куры в курятнике смеются. Perl не популярен отнюдь не потому, что он сложный или чрезмерно гибкий или у него сложный синтаксис. Видимо причина таки в другом. И видимо без perl решают те задачи, где якобы без perl их невозможно решить(или крайне дорого если хотите). Видимо так «невозможно» или «так дорого».

Конечно же на выборке нужно выбирать лишь $sz байтов. Код писал между делом, недоглядел. Прошу прощения.

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

всегда кричат о смерти/нечитабельности/ущербности/нелогичности перла

не зря говорят что «нет дыма без огня», если кричат - значит, к сожалению, есть повод кричать

есть и он работает

о да, «пока рак на горе не свистнет, мужик не перекрестится»

дополнение. если нужно что-то сложное, надо нанимать хорошего программиста, а не админа-индуса-на-все-руки-мастера

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

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

Ничего объективного. А все что вы понаписали - это ерунда которая решается простым побором более вменяемого песонала. Реалии таковы что у одних при слове perl сразу начинается мандраж на синтаксис, тогда как другие вполне нормально используют этот инструмент так что даже создали CPAN для обмена кодом. Вы, похоже, до сих не поняли что проблема вовсе не в perl, и ваш случай известен как «проблема танцора».

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

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

вот еще. я понимаю что это не авторитет, но все же, весело

Я и не ставил целью приближаться к Си по потреблению памяти и скорости исполнения одновременно.

А я ставил цель показать вам, что перл не божественный яп, который «под силу удержать не каждому». Все, что вы показали для меня было очевидно, так что не стоит себя восхвалять в очередной раз «какой я д'Артаньян, а кругом *******».

тратить время на вас я больше не намерен

Взаимно.

Видимо причина таки в другом.

По мне у перла куча проблем. Я тут товарищу уже продемонстрировал суть перла: закрываем одну проблему — открываем другую. И так устроен весь CPAN и Perl, конечно. Стандартный Perl (без CPAN) мал и слаб, ключевых разработчиков мало.

Глобальные проблемы не решаются десятилетиями: кроме Марка Леммана (модуль Coro) никто так и не сподобился написать патч для многопоточности. Как было тупое клонирование данных между процессами, так и осталось. В связи с чем появилась мода писать перл приложения на форках. Для сравнения: если посмотреть на предложения о данном вопросе 10-15 летней давности, то все предлагали использовать use threads и ничего, радовались :)

Идеальная система сборки модулей так и не создана. Module::Build: решение создано чисто для себя, принят сообществом как дефолт, не допилен и местами кривоват. ExtUtils::MakeMaker: хорошая альтернатива предыдущему, но видите ли сложен (что в нем сложного?) для остальных, полностью не принят сообществом. Ладно идеальная, это шибко, но никто не вливает денег в ее доработку (как бы перл-гранты льются рекой).

Графические тулкиты. Я не зря задал вопрос о них, но как ни крути все они не допилены, текут и бажны. Нет, писать приложения на них все же можно, умалчивая о внутренних проблемах. Ну течет память и что? Вон, иксы тоже текут и ничего, живем :) Вопрос в том это ли тот уровень, который нужен интерпрайсу? Нет, т.к. у той же ява (со всеми ее плюсами и минусами) писать интерпрайс GUI-приложения можно и приятней, чем на том же перле.

CPAN — оплот спасения. Да, там много хороших наработок, но всех их рано или поздно придется запиливать под себя. А это значит, что придется читать чужой код: не всегда форматированный, не всегда хорошо документированный и не всегда хорошо понятный. Именно последний пункт является причиной легендарных фраз про нечитабельность кода на перл. С опытом, конечно, начнешь все читать и понимать налету. Но кто захочет тратить время и деньги (работадатель) на то, чего тупо нет в других яп? Да, в ненавистных некими личностями яве, си/си++, tcl/tk нет таких проблем: не надо сидеть и ковырять чужой код, чтобы у тебя заработало как надо то, что описано в документации к модулю :) Просто пишешь код, за который тебе платят и он работает как надо. Нет, бывают конечно исключения, но по сравнению с перл в других яп таких проблем на порядок меньше.

Ну, вот тут товарищъ продемонстрировал, что перл «не каждому осилить» и типа на PP (Pure Perl) пишется супер-пупер хороший код: который тормозит или жрет кучу памяти. Это другая причина, почему перл не популярен: потому что он не всегда эффективен, не смотря на свою многранность, мульти-парадигму и т.п. Да, школоло-поделия на перле писать можно. Да, при знание XS решается 95% вопросов. Но зачем изучать гигантский XS (он гигант не потому что в нем всего много, а потому что там 100500 тонкостей), когда можно сразу писать на си/си++ или даже перейти с этими знаниями в тот же python, ruby, tcl/tk? А может вообще уйти на Java и забыть весь этот «кошмар с указателями»? :)

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

P.S. Ох и простыня вышла.

Я тут товарищу уже продемонстрировал суть перла: закрываем одну проблему — открываем другую. И так устроен весь CPAN и Perl, конечно

демагогичненько :)

Стандартный Perl (без CPAN) мал и слаб

мал, но не слаб. Доказательство этому CPAN и PCRE.

Идеальная система сборки модулей так и не создана

жжёшь :-D

Графические тулкиты.

gmusicbrowser у меня работает отлично. при этом самый настраиваемый музыкальный менеджер из тех что я видел. Больше можно найти на страничках этих тулкитов, в разделах Projects Using *this-toolkit*. Если не указывают, то в гугле.

придется читать чужой код: не всегда форматированный, не всегда хорошо документированный и не всегда хорошо понятный.

если попадается такая крайность, то Deparse + Tidy спасут зрение и моск. Однако, я с таким практически не встречался. Редкие исключения, которые думаю есть в любом языке, где автор либо индус, либо намеренно.

тебе лично чего не хватает в perl?

Все кричат, что питон тормозной и убогий.

Все кричат, что руби жрёт память и не умеет в обратную совместимость.

Все кричат, что луа кривой и недоделанный.

И так далее. Если слушать то, что кричат, писать не на чем будет.

Ну, разумеется, только истинные супер-мега-программисты имеют право писать программы. И только их программы являются правильными. Все остальные не имеют права использовать языки программирования.

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

Поэтому я физически не мог делать патчи к apt-mirror, дополнять плагинами и функционалом munin, исправлять ошибки в album, переписывать куски sarg'а и так далее.

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

И да, если ты пишешь так, что код похож на брейнфак, ты так пишешь на любом языке. Никакие формальности синтаксиса не спасают от идиотов. Я до сих пор не могу понять, какие наркоманы писали ntop, а судя по тому, что замену ему так до сих пор и не написали, ни один я задаюсь этим вопросом. А ведь это простой и понятный python, а не запутанный perl.

Вот и я о том же.

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

ну если действительно даже на питоне так написали, то это «полная деквалификация». если поддерживать будет трудно, может быть проект загнется?

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

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

Другое дело, что немалая часть работы админа - это как раз работа со строками: из шаблона, имея некоторые данные, собрать типовой конфиг; обработать лог, выбросить предупреждение, если там что-то нашёл; посмотреть в /proc/, выдать форматированные данные; соединиться по сети, обработать сигналы, выполнить ряд команд; получить по snmp данные, обработать, отформатировать, выполнить что-то и так далее. И почему бы тут не использовать perl?

И это не ограничивается небольшими скриптами. Я приводил выше примеры. Тот же apt-mirror. Отличный инструмент. Очень полезный, аналоги слабоваты. Уверен, этот инструмент вырос из парочки админских скриптов. Или тот же munin. Да, он не сравнится с каким-нибудь zabbix'ом, или упаси Патрик nagios'ом. Но во многих случаях это вполне достаточная, удобно расширяемая система мониторинга. И всё на perl'е. И живёт и здравствует, несмотря на постоянные крики о том, что perl мёртв.

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

Вот тут я согласен с тобой. Мне тоже не нравятся подобные вещи и я за то, чтобы программы писали программисты. Но это всё светлое будущее и прочий коммунизм.

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

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

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

не зря говорят что «нет дыма без огня», если кричат - значит, к сожалению, есть повод кричать

о да, «пока рак на горе не свистнет, мужик не перекрестится»

Очень интересное сообщение. На первый взгляд вроде бы даже претендует на объективность, но это не так, если разберемся. Вы же видите что люди пишут о том что нападают на perl люди «не способные удержать мощный инструмент в руках». А я пишу о том что нашел класс проблем которые могут возникнуть в ряде языков которые не могут возникнуть в perl5. В этих случаях ведь тоже «нет дыма без огня», верно?

о да, «пока рак на горе не свистнет, мужик не перекрестится»

Я раньше активно писал на C++ (чуть менее активно на Java) и был сильным сторонником C++. Но когда я столкнулся с проблемами возникающими из-за несовершенства языка я занялся поиском более совершенного. Вы верно пишете что «пока рак на горе не свистнет, мужик не перекрестится», но в моем случае рак уже свистнул.

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

Perl дает программисту много свободы, а это большая ответственность. Судя по тому что люди все винят в проблемах именно perl, то perl однозначно не для них: забавно видеть как они обвиняют в бедах именно perl, то есть списывают ответственность с программиста, хотя если вдуматься - программу ведь пишет не perl, а программист. Мораль: perl дает слишком много свободы, но не всем она идет на пользу.

Вот теперь прочтите что я написал и обдумайте мной сказанной в контексте вашего заявления:

не зря говорят что «нет дыма без огня», если кричат - значит, к сожалению, есть повод кричать

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

а кстати, с какими классами проблем я точно не столкнусь в перле по сравнению, например, с условными питоном или руби?

Судя по тому что люди все винят в проблемах именно perl

(для тупых) никто его ни в чем уже давно не обвиняет. его просто не используют. какое из слов «не целесообразно» тебе не понятно?

ну так я ведь говорю о том, что он неидеален, раз критика есть, и неважно от кого она, от новичка или от гуру.

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

есть ли смысл изучать перл, если нет гарантий что я смогу его удержать?

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

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

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

а кстати, с какими классами проблем я точно не столкнусь в перле по сравнению, например, с условными питоном или руби?

было бы очень глупо с моей стороны разбалтывать информацию информацию обладающую коммерческим потенциалом

(для тупых)

если что-то желаете рассказать «для тупых», то, я полагаю, вам следует адресовать вашу речь в первую очередь в зеркало

никто его ни в чем уже давно не обвиняет

так вы не читали тему, перечитайте

его просто не используют

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

какое из слов «не целесообразно»

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

тебе не понятно?

не тебе, а вам

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

anonymous (12.01.2015 3:33:34) и anonymous (12.01.2015 4:16:12) это разные анонимусы. писать так «круто» как второй - я не умею

насчет класса проблем, можно хотя бы в общих словах? типа «проблема с метаклассами», «проблема с наследованием», «проблема с синтаксисом», «скорость работы», «нет какой-то библиотеки»,«проблема с multiprocessing/gil» и т.д.?

а может быть такая ситуация: если перл учтет пожелания новичков и изменится, то необходимость его «удерживать» пропадет, он станет удобнее, прекраснее и его популярность увеличится? это же хорошо, или нет?

Я так и не услышал, по какой причине нужно изучить перл, вместо другого интерпретируемого ЯП. Все эти высказывания в духе: «этого жеребца под силу обкатать не каждому» и тому подобные сопли, которые имеют стоимость, которая стремится к нулю. Изучить perl ради деплоя ? Да в любом ИЯП есть фреймворк, который этим занимается. Собирать стату с чего-то ? Да куча инструментов в других ИЯП. Может быть webdev ? Да есть и RoR и flask. Для себя я лично не увидел причин, по которому мне надо бросить своя ИЯП и начать изучать perl.

PS: ко всему тому, что толком никто так и не объяснил в чем приемущество perl'a, кроме какой-то там свободы, которой якобы нет в других ИЯП, так все эти фразы типа «perl крут, а всё остально просто унылое говнище», кроме улыбки больше ничего и не вызывают. В последнее время и улыбку даже не вызывают. Безраличие и только.

PPSS: всё, что было хорошего в perl'е уже давно перекочевало в другие ИЯП. И в perl'e остался один только синтаксис и его сахар. Кому он нравится - используют его. Кому не нравится - другой ИЯП

.. Безраличие и только.

Что же ты здесь надрываешся? )

..что было хорошего в perl'е уже давно перекочевало в другие ИЯП. И в perl'e остался один только синтаксис..

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

насчет класса проблем, можно хотя бы в общих словах? типа «проблема с метаклассами», «проблема с наследованием», «проблема с синтаксисом», «скорость работы», «нет какой-то библиотеки»,«проблема с multiprocessing/gil» и т.д.?

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

Но это все не то что я имел ввиду когда говорил что программируя на perl5 у вас не может возникнуть определенный класс проблем, хотя и с наследованием в perl5 довольно «интересно».

«проблема с синтаксисом»

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

«скорость работы»

в perl5 этот вопрос решаем (через консенсус(ы) или «влоб» - на уровне Си)

«нет какой-то библиотеки», «проблема с multiprocessing/gil»

тоже не то, это уровень реализации: «сегодня нет - а завтра есть»

а может быть такая ситуация: если перл учтет пожелания новичков и изменится, то необходимость его «удерживать» пропадет, он станет удобнее, прекраснее и его популярность увеличится? это же хорошо, или нет?

Не уверен. Лично я за то чтобы perl5 усложнялся и дальше - чтобы вводились средства расширяющие возможности программиста. А мы, в свою очередь, подтянем свой уровень программирования - и это будет развитием. Так что не похоже что следует обращать внимание на это если стоит цель в наращивании мощности иструмента. Да и сами посудите, если не может человек приложить достаточно усилии чтобы подтянутся на требуемый уровень - нужно ли чтобы он пользовался сложным инструментом? (рассуждая в аналогии со сложными инструментами требующими бОльший уровень квалификации и ответственности) А если он «нанесет себе травмы» из-за нехватки квалификации, то кто вы будете отвечать за его ошибки?

Лично я за то чтобы perl5 усложнялся и дальше

скриптовый с++? нафиг-нафиг.

чтобы вводились средства расширяющие возможности программиста

на CPAN'e есть почти всё)) А каких тебе не хватает?

скриптовый с++? нафиг-нафиг.

Нет-нет, боже упаси. perl5 нужно дальше развиваться именно в рамках TIMTOWTDI. К примеру, отличная идея - это smart-оператор, но вот на уровне реализации где-то поторопились и теперь ее судьба под вопросом.

на CPAN'e есть почти всё)) А каких тебе не хватает?

вот например мне smart-оператора очень не хватает в ядре, ну среди модулей если чего мне не хватает я просто пишу сам :)

Что же ты здесь надрываешся? )

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

Да, теперь ясна ваша безупречная логика:

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

Когда слышу позицию «все ЯП говно, а язык программирования <x> лучший», то задаю вполне конкретные вопросы, а именно: Расскажите приемущества этого ЯП перед другими ЯП. На что обычно следует залп из соплей и три куба воды

А потом вы кидаете сорс с демонстрацией того, почему крут перл. Вы словами скажите что вы там намутили, потому как при незнании этого perl'a вообще ничего не ясно. Если словами скажете, то может пипл и опровергнет то, что «на другом ЯП сделать это чрезвычайно дорого и\или невозможно»

А потом вы кидаете сорс с демонстрацией того, почему крут перл. Вы словами скажите что вы там намутили, потому как при незнании этого perl'a вообще ничего не ясно. Если словами скажете, то может пипл и опровергнет то, что «на другом ЯП сделать это чрезвычайно дорого и\или невозможно»

Не думаю что этот аноним вам ответит, так как вы не к тому анониму обратились. Это я заявляю что знаковая система perl лучше и мой последний ответ был про smart-оператор пользователю chinarulezz: 23-й выпуск журнала Pragmatic Perl (комментарий)

А после моего сообщения идут ответы, похоже, 2-х разных анонимов. Так что нас, анонимов тут уже МИНИМУМ ТРОЕ.

Мне безразлично, но схожу-ка я и сегодня в васин подъезд

а по-вашему, если подъезд не мой, то мне нужно молча пройти мимо, когда я вижу, что кто-то там гадит?

теперь ее судьба под вопросом.

Smart::Match есть на CPAN, так что с судьбой в целом всё в порядке.

вот например мне smart-оператора очень не хватает в ядре

почему именно в ядре? use experimental не достаточно?

P.S. Мне smart не совсем по душе. А вот множества и операции над ними в perl не помешали б.

что кто-то там гадит?

теперь так любовь называется?)

а по-вашему, если подъезд не мой, то мне нужно молча пройти мимо, когда я вижу, что кто-то там гадит?

да - это лучше, чем зайти и нагадить еще больше )

Smart::Match есть на CPAN, так что с судьбой в целом всё в порядке.

пока совсем не ясно как быть, со CPAN или experimental, да и брать оператор со CPAN не хотелось бы, такие вещи вроде бы отлично смотрелись в ядре

(вцелом здесь нужно писать слитно),

почему именно в ядре? use experimental не достаточно?

отличный оператор над примитивами perl, да он логичен в ядре

а use experimental пока нельзя, вот из man perl5180delta

The smartmatch family of features are now experimental

Smart match, added in v5.10.0 and significantly revised in v5.10.1, has been a regular point of complaint. Although there are a number of ways in which it is useful, it has also proven problematic and confusing for both users and implementors of Perl. There have been a number of proposals on how to best address the problem. It is clear that smartmatch is almost certainly either going to change or go away in the future. Relying on its current behavior is not recommended.

Мне smart не совсем по душе. А вот множества и операции над ними в perl не помешали б.

множества в perl реализуются через массивы (обычный или ассоциативный), неужели List::Util и List::MoreUtils вам не хватает? Если не сложно, уточните чего именно не хватает, интересно