LINUX.ORG.RU

Perl 5.18

 ,


0

4

Сегодня 05.18 состоялся релиз Perl 5.18. Разработка заняла год с момента выпуска предыдущей стабильной версии, при участии 113 авторов.
Из видимых изменений можно отметить следующие:

  • Новый механизм для экспериментальных возможностей (features)
    Начиная с этого выпуска при использовании какой-либо экспериментальной возможности будет выдаваться предупреждение, избавиться от которого можно с помощью стандартного механизма «no warnings» (для чего была добавлена категория experimental)
    no warnings "experimental::feature_name";
    Также стоит отметить, что некоторые из уже привычных возможностей были перенесены в категорию экспериментальных, например оператор smartmatch. Полный список экспериментальных возможностей можно посмотреть в perlexperiment
  • Более строгая рандомизация хешей
    Отдельное внимание было уделено проблеме. известной как Hash Collision Complexity Attack. Несмотря на то, что возможность данной атаки была сведена к нулю начиная с perl 5.8.1 (25-е сентября 2003-го), разработчики пошли дальше (возможно, в связи с недавними событиями вокруг некоторых известных языков, применяемых в веб-разработке) и усовершенствовали механизм рандомизации хешей. Теперь порядок вывода одного и того же хеша отличается от запуска к запуску. Помимо этого каждый хеш имеет свой собственный порядок итерирования, поэтому порядок вывода двух хешей с одинаковыми значениями может отличаться. Также был добавлен ряд новых хеширующих функций, а выбрать конкретную можно на этапе компиляции интерпретатора perl.
  • Бинарные операции над символьными классами в регулярных выражениях
    Это экспериментальная возможность, позволяющая применять к символьным классам бинарные операторы, такие как: & (пересечение), + или | (объединение), - (вычитание), ^ (симметрическая разность). Так, например, можно получить все цифры Тайского или Лаосского написания:
    /(?[ ( \p{Thai} + \p{Lao} ) & \p{Digit} ])/
    
  • Подпрограммы с лексической областью видимости
    Появилась экспериментальная возможность создавать подпрограммы с лексической областью видимости (my sub foo {} или state sub foo {}) и алиасы с лексической областью видимости на подпрограммы текущего пакета (our sub foo {}).

>>> Подробности

Ответ на: комментарий от amix

Что будет, если в функцию передать не один, а ноль или два и более аргументов? Никакой проверки нет.

Да, вы, сударь, Перл не осилили:

sub echo($) { ...

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

anonymous ()
Ответ на: комментарий от amix

Правильнее будет: «качество кода зависит НЕ ТОЛЬКО от языка, НО И от программиста».

Сразу стало ясно с кем общаюсь. Дальше не читал.

anonymous ()
Ответ на: комментарий от anonymous

Perl требует гибкий, быстрый и свободный от политики ум.

И силу воли, чтобы столько лет долбить окоченевший труп верблюда.

anonymous ()
Ответ на: комментарий от outtaspace

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

anonymous ()
Ответ на: комментарий от anonymous

Стоит воспринимать это решение не как костыли, а как «вариация на тему» - есть встроенный механизм, есть альтернативы.

Аналогично с ООП: есть базовые возможности, есть множество альтернатив.

outtaspace ★★★ ()
Ответ на: комментарий от outtaspace

Стоит воспринимать это решение не как костыли, а как «вариация на тему» - есть встроенный механизм, есть альтернативы.

Аналогично с ООП: есть базовые возможности, есть множество альтернатив.

Им бесполезно рассказывать. Эти люди не уживаются с TIMTOWTDI и свободой выбора. Им нужно чтобы кто-то или что-то устанавливало для них правила. Без правил они теряются и пишут код от которого сами не в восторге обвияя при этому ЯП. Клиника.

anonymous ()
Ответ на: комментарий от anonymous

Без правил получается Common Lisp. Разобщённое сообщество, где каждый по сути маргинал, потому что нет единых установленных правил. Вива анархия!

anonymous ()
Ответ на: комментарий от amix

Да, Perl умеет быть лаконичным, но, увы, обычно в ущерб ясности и предсказуемости.

Для ясности - пиши на паскаль, для предсказуемости - на асме. Перл НЕ ДЕЛАЛСЯ для школоло, это язык для профи. После «погружения» в язык все эти $#@ покажутся предельно ясными.

Перл не любит «выскочек», понабежавших с сипипей и думающих, что теперь могут всё в ИТ пинать ногами. Такие дурни и остаются с мнением «в перле всё запутанно», ибо не осилили правил и культуры языка.

Дебажить это — кошмар.

Отнюдь, не сложнее АСП или Пестона - print - наше всё. :) В Перле нет вычурностей, каждую вещь можно тыкнуть и сказать что это.

Потом, надо знать, что shift — это не переменная, а функция

см. выше про сипиписников.

... но, спрашивается, на хрена эти витиеватости

Потому что Перл - это вам не Васик, который вы освоили по методичке, ещё раз - это язык ПРОФИ. Соотв. и возможности должны быть профессиональные. Тот же @_ внутри функции не просто ТУПО принимает аргументы, но может этими аргументами наполняться прямо внутри функции! Динамика Перла - это и есть ради чего вообще имеет смысл связываться с миром «не статики»:

bzbz();
bzbz('get off!');

sub bzbz($)
{
    unshift(@_, 'def param') unless scalar(@_);
    
    print "You said: ". shift ."\n";
}
Вывод:
You said: def param
You said: get off!

Сам язык должен способствовать чистоте и ясности текста.

Есть объективная сложность языка, которую синтаксисом не замаскировать. Если язык для вас очень сложный, возьмите «ЛОГО» - в нём всё просто и очевидно. :) В Перл нельзя придти после недельных курсов программирования, до него тоже надо дорасти (как до кватернионов в математике).

ООП в perl5 — просто боль.

:))) Вот тут вы вообще не правы. Если угодно, модель Перла чуть ли не повторяет СМОЛЛТОК! А последний - это вообще бог, отец и классика ООП. Да, несколько вычурнее того, к чему привыкли жабоклепатели, но зато на порядок мощнее. Одна только смена предка чего стоит!

Реальная бизнес-логика тонет в этой каше.

Не надо этой кулинарии! Каша - она ТОЛЬКО В ГОЛОВАХ. Ни один язык не спасёт, если ты накидал в кучу классов, не понимая архитектурных принципов.

При том, что я сторонник очень осторожного использования ООП только при явной необходимости, совсем-то без него тоже нельзя.

Вот за это вам сразу минус 2 балла. ООП не бывает «чуть-чуть», либо ты проектируешь полноценную ООП систему, либо пиши на «плоских» языках. Не удивительно, если «чуть-чуть ООПшная» программа на Перл получится перловой кашей! :)

matumba ★★★★★ ()
Ответ на: комментарий от matumba

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

Для ясности - пиши на паскаль, для предсказуемости - на асме.

А можно просто взять Python, Ruby, CoffeeScript/LiveScript или $that_slick_modern_language_of_your_choice, совмещающие оба параметра.

Перл НЕ ДЕЛАЛСЯ для школоло, это язык для профи. После «погружения» в язык все эти $#@ покажутся предельно ясными.

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

Перл не любит «выскочек», понабежавших с сипипей и думающих, что теперь могут всё в ИТ пинать ногами. Такие дурни и остаются с мнением «в перле всё запутанно», ибо не осилили правил и культуры языка.

Это к чему здесь?

> Дебажить это — кошмар.
Отнюдь, не сложнее АСП или Пестона - print - наше всё. :) В Перле нет вычурностей, каждую вещь можно тыкнуть и сказать что это.

Речь шла о том, что слишком много нештатных ситуаций обрабатывается интерпретатором в режиме «черт знает, что он имел в виду, попробуем так». Как известно, failing early — очень важная стратегия, позволяющая избегать неприятных сюрпризов где-нибудь на продакшене. Так вот, если Питон при любом удобном случае кидает исключение (чем дико бесит поначалу, но приучает яснее формулировать мысли), то добрый Перл всё-всё прощает и в результате по умолчанию тащит ошибку дальше и дальше, что может привести к тихому накоплению ошибок в данных и выходу проблемы уже на принципиально иной уровень. Соответственно, опытный программист будет всеми возможными способами проверять входные данные (и не принтом, а хотя бы через assertions). Увы, на Перле это означает чрезмерное раздувание тела программы.

> ... но, спрашивается, на хрена эти витиеватости
Потому что Перл - это вам не Васик, который вы освоили по методичке, ещё раз - это язык ПРОФИ. Соотв. и возможности должны быть профессиональные. Тот же @_ внутри функции не просто ТУПО принимает аргументы, но может этими аргументами наполняться прямо внутри функции! [...]

Отлично. Внимание, вопрос: ЗАЧЕМ?

Приведенный многострочный пример транслируется в Питон так:

def bzbz(msg='def param'):
    print 'You said: ' + msg

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

> Сам язык должен способствовать чистоте и ясности текста.
Есть объективная сложность языка, которую синтаксисом не замаскировать. Если язык для вас очень сложный, возьмите «ЛОГО» - в нём всё просто и очевидно. :) В Перл нельзя придти после недельных курсов программирования, до него тоже надо дорасти (как до кватернионов в математике).

Я начинал именно с перла и защищал его от нападок всеми силами, пока не убедился в том, что тем самым загоняю себя в клетку. Язык действительно интересный — как язык. Но как инструмент создания информационных систем он сильно уступает ряду других ЯП по множеству параметров.

> ООП в perl5 — просто боль.
:))) Вот тут вы вообще не правы. Если угодно, модель Перла чуть ли не повторяет СМОЛЛТОК! А последний - это вообще бог, отец и классика ООП. Да, несколько вычурнее того, к чему привыкли жабоклепатели, но зато на порядок мощнее. Одна только смена предка чего стоит!

И чего она стоит? И, самое главное, какая разница, кто там бог и отец, когда есть задача и надо ее решить как можно проще и изящнее?

> Реальная бизнес-логика тонет в этой каше.
Не надо этой кулинарии! Каша - она ТОЛЬКО В ГОЛОВАХ. Ни один язык не спасёт, если ты накидал в кучу классов, не понимая архитектурных принципов.

Чистый и грязный синтаксис — одно. Понимание архитектуры — другое. Смешение этих понятий = каша в голове. Поздравляю.

> [...] очень осторожного использования ООП только при явной необходимости [...]
ООП не бывает «чуть-чуть», либо ты проектируешь полноценную ООП систему, либо пиши на «плоских» языках. Не удивительно, если «чуть-чуть ООПшная» программа на Перл получится перловой кашей! :)

То есть, на одном языке надо использовать только ООП, а на другом ООП использовать нельзя никогда? Некоторые части системы прекрасно живут в виде функций, сгруппированных в модули. Другие части явно требуют создания классов. В первом случае лишняя сложность появляется от ООП, во втором — от его отсутствия.

amix ★★★ ()
Ответ на: комментарий от Olegymous

sub echo($) {say $_[0]}

Похоже, `say` появился в 5.10, так что я его уже не застал.

`($)` не помню; действительно, это решает проблему контроля кол-ва аргументов. Тем не менее, остается проблема читаемости: без документации такая сигнатура дает слишком мало информации о функции (если она не уровня echo и hello world), поскольку у аргумента нет ни имени, ни значения по умолчанию. Нужно смотреть в код. А в коде, соответственно, нужно вместо `$_[1]` писать `my $foo, $bar = @_; do_smth($foo); say $bar` и т.д., чтобы через пару недель понять, что там происходит. В итоге, опять же, много boilerplate на ровном месте.

amix ★★★ ()
Ответ на: комментарий от amix
sub bar {
   my $foo = shift // 'default';
   # the rest 
}

что тут сложного? но полный контроль над аргументами ф-ии

как на python сделать такое?

sub bar {
   my $foo = shift || int rand 10;
   # the rest 
}
или такое
sub bar { 
   state $i;
   my $foo = $i = shift || ++$i;
   # the rest 
}
только не говорите, что это нечитаемый код

vividsnow ()
Ответ на: комментарий от amix

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

В этом вы сильно ошиблись. Если и писали на Perl для продакшена, то очень давно и культура разработки была далека от нынешних стандартов платформы.

Сейчас все вменяемые программисты используют семантику strict и warnings. Можно сказать интерпретатору, что программа умрет при любой странности в реализации (фактически любой варнинг).

outtaspace ★★★ ()
Ответ на: комментарий от anonymous

у большинства стереотипы суждения

Да, я на стороне большинства.

Вы так говорите, как будто «большинство» - это что-то плохое.

А меньшинства, это те, которые под радужным флагом ходят?

Bioreactor ★★★★★ ()
Последнее исправление: Bioreactor (всего исправлений: 1)
Ответ на: комментарий от amix

Все ваши нападки в сторону перла - полный треш, имхо. Строгой типизации в функциях видите ли нету (ее, кстати, по слухам, пилят), ООП не такой (если вы не поняли в perl5 его вообще нету как такого), путаетесь в @_... Это все специфика языка и не более. В других ЯП есть тоже своя специфика и там тоже есть свои япофобы. Могли бы кратко написать: перл приколен, но питон мне ближе. Разожгли только флейм.

Что будет, если в функцию передать не один, а ноль или два и более аргументов?

До просветления (читать днем и ночью, как мантру:) http://perlmonks.org/?node_id=663393

ООП в perl5 — просто боль.

use Moo;

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

Реальная бизнес-логика тонет в этой каше. При том, что я сторонник очень осторожного использования ООП только при явной необходимости, совсем-то без него тоже нельзя.

Если есть способ работать без ООП - пишите без ООП. Я не знаю правда какую вы «бизнес-логику» пишите, но при 2к+ строках (без комментов) каша будет почти в любом языке: а перл тут рулит и педалит за счет модульной модели (почти такой же как в паскале - а уж на нем написано просто тонны реальных бизнес-приложений).

Кстати, say теперь не только в шестёрке?

C 5.10 (2007 год если что) http://perldoc.perl.org/feature.html#The-'say'-feature

gh0stwizard ★★★★★ ()
Ответ на: комментарий от outtaspace

Сейчас все вменяемые программисты используют семантику strict и warnings. Можно сказать интерпретатору, что программа умрет при любой странности в реализации (фактически любой варнинг).

Можно и так, ибо warnings тянут за собой много :)

#!/usr/bin/perl

use strict;

sub f_crit {
  my ($test) = @_;

  local $SIG{__WARN__} = sub {
    die "fatality: $_[0]";
  };

  if ($test =~ /\w+/) { # warn undefined value
    ...
  }
}

f_crit();
$ perl -w /tmp/p1.pl
fatality: Use of uninitialized value $test in pattern match (m//) at /tmp/p1.pl line 12.
$ perl test.pl
$
gh0stwizard ★★★★★ ()
Ответ на: комментарий от anonymous

Эти люди не уживаются с TIMTOWTDI и свободой выбора.

Не, не уживаются. Вы для себя пишете? Как говорят писатели «в стол»?

annonymous ★★ ()
Ответ на: комментарий от vividsnow

Хорошие примеры. Результаты вполне сравнимы.

Perl:

sub bar {
   my $foo = shift || int rand 10;
   # the rest 
}
Python:
def bar(foo=None):
    foo = foo or random.randint(0, 10)
    # the rest 

Тут Perl явно более DRY. Но в питоньей версии по сигнатуре сразу ясно, как ведет себя функция (т.е., принимает один необязательный аргумент), а в перловой — нет.

Perl:

sub bar {
   state $i;
   my $foo = $i = shift || ++$i;
   # the rest 
}
Python (вариант реализации):
i = 0
def bar(foo=None):
    global i
    foo = i = foo or i + 1
    # the rest 
Также можно извернуться с `nonlocal`.

amix ★★★ ()
die "Get me $beer!" unless defined $beer;
anonymous ()
Ответ на: комментарий от gh0stwizard

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

outtaspace ★★★ ()
Ответ на: комментарий от amix

amix, я не фанитак не Перла, ни Питона. Но Перл знаю лучше. Лучше Питона, я имею ввиду. ;-) На Перле функцию с одним необязательным аргументом лучше писать так:

sub bar(;$) {

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

Что меня порадовало в Перле (много лет назад), так это *отличная* документация и развитая инфраструктура. На мой взгляд, перловая документация до сих пор лучше питонной.

anonymous ()
Ответ на: комментарий от d_Artagnan

И это тот код который в публичном доуступе. А точ творится на внутренних проектах?

Для особо упоротых - перл весь в публичном доступе. И свои высеры про читаемость и прочее оставь при себе, не смущай людей.

golodranez ★★★★ ()
Ответ на: комментарий от d_Artagnan

Не видеть очевидного - очевидный признак слива дискуссии. С чем вас и поздравляю!

Так слился то ты)

golodranez ★★★★ ()
Ответ на: комментарий от annonymous

Из дистрибутивов выпилить обязательно!

Выпилить тебя из людей)))) Чушь говоришь, ты ещё bash выпилить предложи) Без перла никуда!

golodranez ★★★★ ()
Ответ на: комментарий от Bioreactor

у большинства стереотипы суждения

Да, я на стороне большинства.

Вы так говорите, как будто «большинство» - это что-то плохое.

Кому-как.

А меньшинства, это те, которые под радужным флагом ходят?

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

Вам ведь тут сильно страшно свое мнение опубликовать, верно?

anonymous ()
Ответ на: комментарий от annonymous

Не, не уживаются. Вы для себя пишете? Как говорят писатели «в стол»?

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

???

anonymous ()
Ответ на: прототипы perl не для проверки параметров от pru-mike

Re: прототипы perl не для проверки параметров

Использовать прототипы для проверки параметров - ошибка.

Да что вы говорите? А мужики-то не знают...

Мне это напоминает сказки что «Паскаль предназначен для обучения программированию» (и, следовательно, непригоден для всего остального).

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

&echo();

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

anonymous ()
Ответ на: комментарий от Bioreactor

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

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.