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

такие вещи вроде бы отлично смотрелись в ядре

имхо, смарт слишком уродлив. Где-то может удобен, однако вносит слишком много путаницы, в отношения между типами и их позициями в сравнении. Плюсов маловато, в основном смарт дублирует ==, eq, grep, и т.д. Буду рад услышать от тебя доводы за. Прояснить некоторые достоинства.

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

за что мне нравится perl - так это еще и за use PerlVersion. Доступна история языка. Используй v5.10.0, или v5.10.1, если разбираешься в сортах смарта ;) И без доп.модулей c CPAN'a.

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

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

Если не сложно, уточните чего именно не хватает, интересно

Просто множеств и стандартных операций с ними. Это избавило бы меня от нецелесообразного(имхо) использования smart-match, регэкспов, grep, и всяких модулей для их эмуляции, которые скачиваю с CPAN. Вот хочу посчитать ранги чисел, качаю модуль, подключаю List::MoreUtils, делаю uniq, либо perlhack используя хэши + grep. А множества лишь объединил бы. Это в контексте чисел, но и в контексте других видов данных это облегчило бы незамысловатые, частые операции.

за что мне нравится perl - так это еще и за use PerlVersion. Доступна история языка. Используй v5.10.0, или v5.10.1, если разбираешься в сортах смарта ;) И без доп.модулей c CPAN'a.

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

имхо, смарт слишком уродлив. Где-то может удобен, однако вносит слишком много путаницы, в отношения между типами и их позициями в сравнении. Плюсов маловато, в основном смарт дублирует ==, eq, grep, и т.д. Буду рад услышать от тебя доводы за. Прояснить некоторые достоинства.

в том то и дело что smartmatch введен именно с целью комплексного анализа данных, и именно для этого его и нужно использовать. По логике, в идеале, smartmatch должен втянуть в себя все множество операции над всеми примитивами perl, и позволять использовать все это на декларативном уровне. Конечно, всегда можно и eq, grep, ==, map {} или просто завернуть в sub, но это все императивно.

пример: пусть у вас определен конечный автомат с заданными схемами обработки данных. Тогда smartmatch поможет сделать такое:

(do{given(shift @ARGV){
	exit(-1) when undef;

	sub{say join '', @_} when /^say/;

	when([qw/1 2 3/]){
	    sub{warn @_}
	}

	default{
	    die;
	}
}})->(@ARGV);

Вроде бы получилась отличная структура исполнения с отчетливо определенными правилами. Да, это можно было сделать «императивно», но представьте что у вас в этом месте идет определение какого-нибудь роутера на 200 состоянии с последующим форвардом на обработчики. smartmatch поможет этот роутер записать примерно так же как вы записываете разбор строки через regexp'ы. То есть smartmatch позволяет создать структуру обработки которую раньше приходилось «размазывать» на множество участков кода. Когда вменяемый народ сообразит что к чему с этим smartmatch-оператором, то, думаю, и в других ЯП тоже появятся smartmatch-операторы, хотя от уродливых === они избавиться все равно не смогут.

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

Просто множеств и стандартных операций с ними. Это избавило бы меня от нецелесообразного(имхо) использования smart-match, регэкспов, grep, и всяких модулей для их эмуляции, которые скачиваю с CPAN. Вот хочу посчитать ранги чисел, качаю модуль, подключаю List::MoreUtils, делаю uniq, либо perlhack используя хэши + grep. А множества лишь объединил бы. Это в контексте чисел, но и в контексте других видов данных это облегчило бы незамысловатые, частые операции.

Похоже вы немного не понимаете perl. Массив - это вовсе не эмуляция, а СПОСОБ ХРАНЕНИЯ ЭЛЕМЕНТОВ. Группу элементов вы можете рассматривать как множество, обрабатывать как множество и называть как множество! Но так или иначе, хранить элементы множества вам все равно где-то придется: либо в массиве, либо использовать кучу переменных (можно еще сразу отобразить во flat-память, но тогда вы теряете явную детерминированность элемента). Perl - создает среду управления базовыми примитивами, а вы хотите в perl увидеть то что реализуется этими примитивами.

Все что вам нужно - это написать (или найти) один раз объект множество с, вероятно, перегруженными операциями над ними. (я бы на вашем месте сделал бы это один раз и забыл бы давно об этом). Так или иначе, строить этот объект perl будет все равно через свои примитивы (хотя конечно можно переиграть через XS и не использовать примитивы perl). Если функции оперирующие примитивами perl еще логично включать в базовую поставку самого perl (вроде Scalar::Util, List::Util, ...), то включать то что строится на примитивах (и уж тем более то что определяется семантикой) - это будет выглядеть крайне нелогично.

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

Вообще, у перла есть CPAN, т.е. для определенного круга задач (чаще рутинных, мелких и т.п.) можно быстро писать скрипты для их решения, заимствуя готовые модули. Хотя в ряде вопросов даже CPAN не спасет.

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

И последняя причина, наверное, это совокупность всех плюшек Perl. Такого набора нет ни у одного яп.

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

smartmatch позволяет создать структуру обработки которую раньше приходилось «размазывать»

Однажды приходилось отказаться от «given/when» в похожем случае.
Реализация на «sub/map..» получилась не так красива, но вполне компактна.
На вашем примере:

(do {(map sub {
    exit -1 unless defined;
    return sub { say join '', @_ } if /^say/;
    return sub { warn @_ } if do { my $c = $_; grep $c eq $_, 1..3 };
    die;
}->(), shift@ARGV)[0]})->(@ARGV);

..можно и убрать внешний "(do { ... })" тогда

(map sub {
    exit -1 unless defined;
    return sub { say join '', @_ } if /^say/;
    return sub { warn @_ } if do { my $c = $_; grep $c eq $_, 1..3 };
    die;
}->(), shift@ARGV)[0](@ARGV);

после того как smart переведен в experimentals использовать его - это будет выглядеть «дурно»

выглядеть - возможно, но если тебе это необходимо - то похер :)

smartmatch поможет этот роутер записать примерно так же как вы записываете разбор строки через regexp'ы.

покажи пример, плиз.

Массив - это вовсе не эмуляция, а СПОСОБ ХРАНЕНИЯ ЭЛЕМЕНТОВ. Группу элементов вы можете рассматривать как множество, обрабатывать как множество и называть как множество!

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

выглядеть - возможно, но если тебе это необходимо - то похер :)

использование smartmatch при известном предупреждении

The smartmatch family of features are now experimental

...

Relying on its current behavior is not recommended.

и существовании «безрискового» пути решения задаи выглядит крайне непроффесионально

smartmatch поможет этот роутер записать примерно так же как вы записываете разбор строки через regexp'ы.

покажи пример, плиз.

я же показал выше: в теле given идет определение поведения (тело when) на объявленное условие (то что под when). В регулярных выражениях мы действуем примерно так же: определяем выполнение действия на определенные условия.

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

Вот «атомы» языка:

Builtin types include:

SCALAR

ARRAY

HASH

CODE

REF

GLOB

LVALUE

FORMAT

IO

VSTRING

Regexp

В массиве хранится группа элементов. Все необходимое для обработки групп скаляров уже определенно: работает операция присваивания массовов, есть splice - средство выбора/вставки подгруппы, есть split, join, grep, sort, и т.д.

Вопросы семантического представления группы элементов хранимых в массиве - это из области интерпретации программистом этой группы скаляров. Вполне логично что perl оставляет это право выбора программисту. Так что и вполне логично то что в ядро не введены операции над списками (идут отдельными модулями в List::Util и List::MoreUtils), т.к. интепретация и обработка группы скаляров хранимых в массиве как списка - это тоже из области семантического представления. Вам нужно обработать группу элементов хранимых в массиве как список или вектор - просто подключите соотстветсвующий модуль. Ядро не должно делать предпочтение в вопросе интерпретации группы элементов программистом.

Однажды приходилось отказаться от «given/when» в похожем случае.
Реализация на «sub/map..» получилась не так красива, но вполне компактна.

Да, вполне рабочая структура. Я тоже после перевода smartmatch в категорию «experimentals» вернулся к использованию map'ов. Но, как и говорил, декларативность пропадает..

Поддерживает https://metacpan.org/changes/distribution/libwww-perl#L5

2014-07-24 Release 6.08 То есть до LTS дистрибутивов доедет не раньше 2016 года. Пока по факту в продакшене только через костыли.

А в каком году хотябы у 10% российских провайдеров появится поддержка IPv6?