После года разработки представлена (http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/ms...) новая стабильная ветка языка программирования Perl - 5.22 (https://metacpan.org/pod/release/RJBS/perl-5.22.0/). При подготовке нового выпуска было изменено около 590 тыс. строк кода, изменения затронули 2400 файлов, в разработке приняли участие 94 разработчика.Ветка 5.22 выпущена в соответствии с утверждённым четыре года назад фиксированным графиком разработки, подразумевающим выпуск новых стабильных веток раз в год и корректирующих релизов - раз в три месяца. Примерно через месяц планируется выпустить первый корректирующий релиз Perl 5.22.1, в котором будут исправлены наиболее значительные ошибки, выявленные в процессе внедрения Perl 5.22.0. Одновременно с выходом Perl 5.22 прекращена поддержка ветки 5.18, для которой в будущем могут быть выпущены обновления только в случае выявления критических проблем с безопасностью. Также начался процесс разработки экспериментальной ветки 5.23, на базе которой в мае 2016 года будет сформирован стабильный релиз Perl 5.24.
Ключевые (http://perltricks.com/article/165/2015/4/10/A-preview-of-Per...) улучшения (https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perlde...), добавленные в Perl 5.22:
- Модули CGI и Module::Build исключены из стандартной поставки и более не поставляются вместе с интерпретатором perl в базовой стандартной сборке. Они могут быть установлены из CPAN в случае необходимости.- Новый двойной ромбовидный оператор: "<<>>", работает как "<>" с той лишь разницей, что использует трёхаргументный вызов функции open() для открытия файлов из массива @ARGV, т.е. не обрабатывает спецсимволы в именах файлов. Новый оператор позволят блокировать возможные атаки, связанные с обработкой спецсимволов в именах файлах, например, указание "|foo" не приведёт к открытию неименованного потока и запуску программы "foo";
- Новая экспериментальная возможность задания алиасов для переменных и подпрограмм через указатели указателей: \$c = \$d и \&x = \&y. В том числе можно сразу создать алиас в цикле foreach, например, после указания "foreach \%hash (@array_of_hash_refs){" хэши можно перебирать через "foreach my $key ( keys %hash )". Варианты использования и детали в perlref, секция "Assigning to References (https://metacpan.org/pod/perlref#Assigning-to-References)".
- Новый модификатор регулярного выражения "/n" отключает переопределение и заполнение позиционных скаляров $1, $2 и т.п., но при этом сохраняет возможность отрицания на групповой оператор, и сохраняется именованное заполнение. Например, указание "/(hi|hello)/n" не приведёт к заполнению $1. Детали о модификаторе "/n" в perlre (https://metacpan.org/pod/perlre#n).- Введен обсуждаемый ранее новый атрибут ":const", который может быть применен к анонимным функциям, что приведёт к немедленному выполнению подпрограммы в месте её определения с последующей подстановкой сохранённого результата в моменты обращений к ней в коде. Атрибут имеет экспериментальный статус. Детали perlsub, секция "Constant Functions (https://metacpan.org/pod/perlsub#Constant-Functions)".
- Схема с оператором повторения "x" ("(...) x ...") может быть использована в присвоениях к списку. Например, конструкция "(undef,undef,$foo) = that_function()" теперь может быть задана в форме "((undef)x2, $foo) = that_function()". Особенно полезно использование данной возможности при заполнении переменныз оператором split, например, вместо серии undef можно написать "my(undef, $card_num, (undef)x3, $count) = split /:/;"- Новые экспериментальные битовые операторы для работы со строками по аналогии работы с числами: "&." "|." "^." "~." "&=" "|=" "^=" "&.=" "|.=" "^.=". Детали доступны в документации perlop секции "Bitwise String Operators (https://metacpan.org/pod/perlop#Bitwise-String-Operators)";
- Новые операторы "\b" регулярных выражений: "qr/\b{gcb}/" , "qr/\b{wb}/" , "qr/\b{sb}/", определяющие границу между последовательностями символов (которые выглядят как один символ), словами (например, содержащими апостроф) и предложениями. Детали доступны в описании регулярных масок "\b{}", "\b", "\B{}", "\B" в perlrebackslash (https://metacpan.org/pod/perlrebackslash#b-b-B-B).
- Новая директива "use re 'strict' (https://metacpan.org/pod/re#strict-mode)", которая применяет более строгие правила для компиляции регулярного выражения в текущей области видимости.- Поддержка Unicode 7.0.- Директиве "use locale" теперь можно передать параметр для выборочного задания категорий локализации, на которые будут отражаться свойства локали. Детали в perllocale (https://metacpan.org/pod/perllocale#The-use-locale-pragma).
- В возвращаемых значениях вызова POSIX::localeconv() появились новые поля int_p_cs_precedes, int_p_sep_by_space, int_n_cs_precedes, int_n_sep_by_space, int_p_sign_posn, int_n_sign_posn, реализованные в соответствии с POSIX.1-2008;
- Улучшен эвристический анализатор для обнаружения UTF-8 в текущей локали. Эвристика работает на платформах, которые не реализуют ни один из стандартов (С99 и/или POSIX 2001).
- Закрыта проблема, связанная с вызовом prototype() без параметра. Теперь используется скалаяр $_;- Вызов fileno() теперь работает с дескрипторами директорий. Поведение filen на дескрипторе директории зависит от операционной системы. Детали доступны в описании вызова по perldoc -f fileno.
- Для платформы Win32 завершена реализация формы организации неименованного канала через вызовы open my $fh, "-|", "program", @arguments'.- Дробные числа теперь могут хранить специальные значения неопределенностей: бесконечность, отрицательную бесконечность и значение "не число" NaN. Детали в perldata.- Доработаны вывод и разбор дробных чисел. Добавлена поддержка hex-форм в виде "0x1.23p-4" и введен формат "%a" для printf. Подробности в perldata, секция "Scalar value constructors (https://metacpan.org/pod/perldata#Scalar-value-constructors)".- Упаковка беконечностей (Inf) и "не чисел" (NaN) в символ (вызовами pack, "chr" и printf "%c") теперь завершается ошибкой.- Появилась новая опция сборки usecbacktrace (./Configure -Dusecbacktrace) которая позволяет из perl-кода выполнить трассировку стека и получить си-фреймы из perl-кода, путем использования API уровня Си-кода. Работает на платформах Linux и OS X, возможна работа на *BSD. Детали в perlhacktips, секция "C backtrace (https://metacpan.org/pod/perlhacktips#C-backtrace)".- Безопасность:
- Perl по умолчанию собирается с -fstack-protector-strong если это возможно.- Модуль Safe обновлен до версии 2.38, которая закрывает критическую уязвимость, позволяющую заменить внешнее пространство имен.- Perl по умолчанию собирается с -D_FORTIFY_SOURCE=2 если это возможно.
- Несовместимые изменения:- Изменен позиционный порядок введенной в v5.20 экспериментальной возможности определения сигнатуры подпрограммы. Теперь сигнатура может быть задана до атрибутов (в v5.20 сигнатуры можно определить лишь после атрибутов).- Прототипы "&" и "\&" теперь принимают только анонимные функции (sub {...}).- По уровню действия директива "use encoding" теперь является лексической.- Срез списка теперь может вернуть пустой список только в случае если исходный список был пустым;- Ранее объявленная устаревшей (в v5.18) форма записи "\N{}" с последовательностью из множества пробелов теперь приводит к ошибке: "\N{TOO MANY SPACES}" or "\N{TRAILING SPACE}.- Ранее объявленная устаревшей (в v5.12) возможность импорта функции через use UNIVERSAL '...' теперь приводит к ошибке. Форма поведения "use UNIVERSAL" без аргументов осталась неизменной.- Символы "X" в двойных кавычках в форме "\cX" теперь должны быть печатными ASCII-символами (printable ASCII character). Ранее допускались непечатаемые символы, но с выводом предупреждения.- Ранее объявленная устаревшей (в v5.18) возможность разделения управляющих конструкции "(?" и "(*" регулярного выраж...
URL: http://perlnews.org/2015/06/perl-5-22-0-released/
Новость: http://www.opennet.me/opennews/art.shtml?num=42349
Респект за такое подробное описание.
> Респект за такое подробное описание.Не за что, мне и самому было очень интересно узнать о perl 5.22. Разбирая не знакомые мне ранее конструкции я узнал немало интересного и нового.
> Не за что, мне и самому было очень интересно узнать о perl 5.22. Разбирая не знакомые мне ранее конструкции я узнал немало интересного и нового.Кроме того, я должен выразить благодарность тому и тем кто подкорректировал и немного дополнил мое первоначальное сообщение тем как опубликовать новость здесь. Редактура отработала на высоте, а я принал ко вниманию.
Спасибо.
вчера весь вечер разбирал ужасный перл код какого-то то ли индуса, то ли китайцаматерился адски: ничего не понятно
потом выяснилось, что код написан мной, месяц назад
> потом выяснилось, что код написан мной, месяц назадИ не на Perl ?
да и не код вовсе, а ридми
причём на суахили.
Вот-вот, накодят задницей, а потом им perl виноват.
> вчера весь вечер разбирал ужасный перл код какого-то то ли индуса, то ли китайца
> матерился адски: ничего не понятно
> потом выяснилось, что код написан мной, месяц назадЯ думаю вам не стоило "рекламировать" свой уровень навыков. По ситуации определенно можно сказать что вы не умеете писать качественный и понятный код (на perl или вообще?).
Вот, я к примеру, недавно дорабатывал несколько своих проектов написанных в 2009 - 2012 годах и буквально неделю назад занимался разбором кода Mojolicious и еще нескольких сопряженных с ним модулей (в том числе и XS-код). Я не помню чтобы у меня возникали проблемы как у вас, да и в целом, что-то я не помню чтобы у меня возникали проблемы с пониманием perl-кода (я встречал малограмотный и низкокачественный код, но проблем с пониманием все же не было).
> потом выяснилось, что код написан мной, месяц назадhttp://lurkmore.to/%D0%92%D1%8B%D1&...
«Perl: Вы стреляете себе в ногу, и никто не может понять, как вы сделали это. Через шесть месяцев не можете и вы.»
>вчера весь вечер разбирал ужасный перл код какого-то то ли индуса, то ли китайца
>
>матерился адски: ничего не понятно
>
>потом выяснилось, что код написан мной, месяц назадЯ так и не понял. Ты индус или китаец?
Он перловщик. Тех хотя бы можно простить ...
> Он перловщик. Тех хотя бы можно простить ...Нет, он - кретин. Вы похоже никогда сталкивались с настоящими perl-программистами.
Лично я давно ожидал:
- оператор "<<>>" в perl, очень удобно для всяких однострочников и для написания фильтров обработки потоковых данных когда нужно на входе забирать список файлов
- алиасы через указатели
- работу с константами другого пакета через его полное имяЕще очень интересно развитие возможности задания сигнатуру функции и атрибута ':const'.
Новый релиз Perl(a) всё равно, что новость о успешной реализации криогенной заморозки человека.
Очередное достижение в науке и технике? Да, что похожее есть.
Надо бы его, наконец, выучить...
Не учить его нужно, а понять его. Если вы разберетесь в нем то поймете что он на самом деле он очень прост, логичен и лаконичен. Попытка выучить perl влоб без желания понять (это как выучить физику, а не понять ее) обычно заканчивается очень плачевно..
> Надо бы его, наконец, выучить..."Завещать детям выучить язык." [Пусть мучаются.]
Чтение 2х man'ов perlfunc/perldata - и забудешь написание башевых портянок как страшный сон. Ещё до кучи: https://metacpan.org/pod/Shell
> Ещё до кучи: https://metacpan.org/pod/ShellПро shell не знал, но знаком с этим: https://metacpan.org/pod/PerlPowerTools
Истинная правда. Для писания самопальных скриптов он великолепен, и осваивается быстро. А больше от скриптового языка, в общем, и не требуется.
И тем не менее, для написания сложных программ всё в perl/cpan имеется. Например, есть ли в каком скриптовом языке профайлер уровня NYTProf, или доступ к компилятору кода, или синтаксическому дереву?
Да я, в общем-то, на перле писал несколько лет full time, так что в курсе и с плюсами/минусами знаком хорошо. Именно поэтому что-то большое на нём делать не рвусь. Кстати, B почти весь выкинули по причине устаревания, насколько я помню. И поверьте - в большом проекте очень нежелательно извращаться с генерацией кода на ходу или модификацией ST - это ж потом ещё и поддерживать надо будет.В общем, не то чтобы для больших проектов перл подходил хуже, чем, скажем, JS или питон, но всё же для этого есть более подходящие языки - хотя бы плюсы те же, или Си на худой конец (на котором я пишу сейчас, если что - так что насчёт "худого конца" - из личного опыта). В перле либо надо брать какой-нибудь Moose, тормозной до неприличия, либо самому что-то колхозить и потом очень жестко следить за стилем, обвешиваться тестами как новогодняя ёлка - игрушками... В общем, много совсем лишней мороки, от которой компилируемый (и статически типизированный) язык избавляет.
А вот чтобы быстро наваять пришедшее в голову извращение - CPAN - идеален, наверняка все кубики найдутся и можно будет их сравнительно просто слепить в кучу. Для продакшна же разговор совсем другой - качество кода очень варьирует, смотреть надо. В половине там такое легаси... чуть ли не из четвертой версии, вешаться можно.
> В перле либо надо брать какой-нибудь Mooseзачем?
> либо самому что-то колхозить
зачем?
> потом очень жестко следить за стилем
> обвешиваться тестамиЭто хорошая идея безотносительно языка.
> В общем, много совсем лишней мороки, от которой компилируемый (и статически типизированный) язык избавляет.
и что же это за идеальный язык со сравнимой скоростью разработки? Имя, сестра! (вобщем-то я за статическую типизацию, но это не серебряная пуля)
Затем, что сам по себе перл допускает очень много свободы и соблазнов. Для скрипта или для гения-одиночки - это хорошо. Для команды, в которой люди время от времени меняются и должны понимать и поддерживать код предшественников - плохо. Поэтому берётся некий стандарт, чтобы не гадать, каким из восьмидесяти путей сделано что-то тривальное вроде наследования - изобретательность лучше использовать там, где она нужна.Насчёт тестов - это хорошая идея, но тесты по сравнению с проверками компилятора дороги. И когда тестами надо проверять то, проверку чего можно захардкодить (типы те же) - это бесполезная трата времени разработчика.
Идеальных языков как-то не встречал. А вот более пригодных для продакшна - валом. Сравнимую скорость разработки можно хоть на джаве (гадость-то какая) получить, хоть на плюсах (которые я и предпочитаю), это если о мейнстриме говорить. C# тот же хорош как язык, если отвлечься от того, что он MS-овская поделка. Что в скорости изначальной писанины потеряете - то на отладке и поддержке десятикратно вернёте. Ну или модный Go или менее модный D - там уже и изначально пишется быстро.
Ну вот и что у вас в результате получается, если переформулировать - Perl плохо пойдет там, где (кратко):
- большая текучка низкоквалифицированных кадров
- при этом отсутствует и менеджмент, способный энфорсить внутренние стандарты, в том числе и кодирования
- отсутствует культура тестирования
- на всём будут писать как на Фортране (только так можно обеспечить сравнимые скорости разработки на Java, C++ и Perl)
- с QA всё плохоКартина удручающая, мягко говоря. Тем не менее искать проблему предлагается именно в ЯП.
В таких условиях обычно на Java получается ровно то же самое - разница может быть лишь в том что экскременты будут просто переложены в другие места. Вместо функции из 15 строк, в которой надо разбираться полчаса, будет иерархия фабрик их фабрик из 150 классов, в которой нужно разбираться неделю.
Вот честно - вы сами на нём писали что-то большое?Текучка есть всегда, если у вас проект не на пол-года. И никто в здравом уме не будте набирать команду из гениев, как из идиотов. Всегда есть некий стандарт "обычного разработчика". И любому новичку надо потратить время и силы, чтобы "въехать". Чем меньше экзотики в проекте - тем быстрее это произойдёт и тем лучше он будет понимать логику тех, кто был до него. разница в квалификации даст разницу в скорости освоения - но и только.
Вы понимаете, что каждое "энфорсить" - это чьё-то время и чьи-то деньги? А когда это делается в языке - это даром. Энгфорсить приходится везде - но лучше, чтобы не приходилось докатываться до деталей вроде "в каждой функции первое, что делаем - это разворачиваем @_ в список именованных параметров".
Насчёт тестов - тем более. Каждый тест - это время на написание, время на поддержку и время на прогоны. И деньги, соответственно. И когда сам язык избавляет от необходимости проверки того, что в целочисленную переменную запихнули объект - это избавляет от совершенно бестолковой писанины.
QA от повышенных затрат здесь не спасёт - проблему-то найдут, только этот поиск стоит денег, и исправление - тоже.
Джава с фабриками фабрик фабрик - это, кстати, вообще о другом. Это о попытках перетаскивания энтерпрайзных джавовских фреймворков, биббиотек и прочего - вместе с практиками - с больших и сверхбольших проектов (там лучше безобразно, но единообразно, потому что иначе в голову не поместится) на средние, где получается уже избыток архитектуры/бюрократии.
> И когда сам язык избавляет от необходимости проверки того, что в целочисленную переменную запихнули объект - это избавляет от совершенно бестолковой писанины.Очень плохой пример.
1. Ошибку в ДНК программиста не должен компенсировать ЯП
2. Тесты все равно делать нужно на алгоритм работы модуля, функции или всего проекта, даже если вы надеетесь на ЯП. Ну подобные ошибки вы поймаете еще задолго до выполнения теста.PS: Я вообще балдею от таких примеров. Неужели люди действительно организуют выполнение кода так что могут запихать объект в целочисленную переменную. Это ж какой ветер в голове нужен. Ни разу не сталкивался с подобным.
Ошибаются все. Отвлёкся, задумался о чём-то - и готова тупая ошибка.Тесты на функционал - да. Но, как ни странно, они подобное не всегда ловят, обычно приходится дополнительно писать - например, проверку на то, что пришел хэш, имеющий все поля, которые должен иметь. А была бы сишная структура - не надо было бы это проверять. А потом эти лишние тесты надо поддерживать и гонять, что тоже время занимает.
А насчёт примеров....
Думаете, сильно сложно написать
$counter = $myArray->[0];
вместо
$counter = $myArray->[0][0];
и получить в $counter ссылку на массив(возможно, blessed, то есть объект)?
> Ошибаются все. Отвлёкся, задумался о чём-то - и готова тупая ошибка.Ошибки бывают разгоного плана, но то к чему вы тут пишете оправдания - это просто кошмар от которого нужно избавляться в школе и университете. Кроме того, свои ошибки нужно их осознавать, да так осознавать чтобы более не совершать их. Практика показывает (по себе знаю) что чем больше труда вы вкладываете в поиск и исправление - тем больше вероятность что вы излечитесь от подобного раз и навсегда.
> Тесты на функционал - да. Но, как ни странно, они подобное не всегда ловят, обычно приходится дополнительно писать - например, проверку на то, что пришел хэш, имеющий все поля, которые должен иметь.
Когда вы принимаете данные, то вы должны либо убедиться в их наличии и корректности либо полностью довериться на вызывающему коду. И это обстоятельсто не зависит языка программирования вообще.
> А была бы сишная структура - не надо было бы это проверять.
И привет обращение по нулевому указателю, ну или привет очередной heartbleed или CVE CVE-2011-2013 ? Нет, вам все равно нужно будет проверять так как вы все равно можете получить невалидные данные, нравится это вам или нет.
> А потом эти лишние тесты надо поддерживать и гонять, что тоже время занимает.
Вообще говоря с тестами как с деньгами - они лишними не бывают. Насчет поддерживать и гонять я не очень пойму ваш метод разработки. Я, к примеру, разрабатываю модульно, и тесты пишу под юниты. Соответственно, "поддерживать и гонять" тесты по этот юнит мне нужно только тогда когда юнит модифицируется так что изменения влияют на функционал. Кстати, эта техника разработки очень хорошо зарекомендовала себя и я не знаю лучше языка чем perl под эту технику разработки. Кроме того, программируя на си я тоже использую вышеупомянутую технику модульной разработки с верификацией через тесты на perl.
> А насчёт примеров....
> Думаете, сильно сложно написать
> $counter = $myArray->[0];
> вместо
> $counter = $myArray->[0][0];
> и получить в $counter ссылку на массив(возможно, blessed, то есть объект)?Пример на самом деле плохой:
1) подобную ошибку можно сделать и на других языках программирования, так что претензии все равно к программисту или к себе
2) пример синтетичный и тут даже может быть простая проблема плохой организации структуры хранения данных, а может и не быть
> Вот честно - вы сами на нём писали что-то большое?Ну что вы, тут ведь все чисто потрещать вышли, а писали только маленькое, на dBase III, и не затягиваясь.
> Текучка есть всегда, если у вас проект не на пол-года.
Нет, не всегда. Кстати, кроме черного и белого есть множество оттенков. С текучкой то же самое.
> И никто в здравом уме не будте набирать команду из гениев, как из идиотов.
С гениями и идиотами тоже.
> Всегда есть некий стандарт "обычного разработчика".
За пределами Luxoft, Infosys и Tata Consultancy Services - нету. Внутри них, впрочем, тоже нету, но это типа коммерческий секрет.
> И любому новичку надо потратить время и силы, чтобы "въехать".
Разумеется.
> Чем меньше экзотики в проекте - тем быстрее это произойдёт и тем лучше он будет понимать логику тех, кто был до него. разница в квалификации даст разницу в скорости освоения - но и только.
Ну вот, теперь мы пришли к "экзотике". И экзотика, крайне осложняющая въезжание новичка в проект - это, конечно и исключительно то что именно принято блессить в перловом коде в этой конкретной лавке. И это совершенно невозможно понять, освоить за разумное время и объяснить кому бы то ни было. Совсем другое дело, если мы используем Spring, WebsphereMQ и еще с десяток декларативных IoC-фреймворков, которые каждый индус знает наизусть уже в четвертом классе </sarcasm>
А у вас открывающий тег потерялся ;)
> Ну вот и что у вас в результате получается, если переформулировать -
> Perl плохо пойдет там, где (кратко):
> Картина удручающая, мягко говоря. Тем не менее искать проблему предлагается именно в
> ЯП.знаете, есть языки где люди спокойно могут ковырять код в продакшен без серьёзного риска всё сломать. let it crash, все дела.
> Да я, в общем-то, на перле писал несколько лет full time, так
> что в курсе и с плюсами/минусами знаком хорошо.А что такое скриптовый язык? И чем он отличается от нескриптового?
Вот Java и C# - скриптовые? Нет? А почему? Компилируются в байткод, выполняются JVM и .NET, ничем в этом смысле от Perl не отличаются, кроме названия VM.> проекте очень нежелательно извращаться с генерацией кода на ходу или модификацией
> ST - это ж потом ещё и поддерживать надо будет.Да, средства метапрограммирования через кодогенерацию в Perl традиционно неразвиты, а те что есть - лучше без _крайней_ необходимости не трогать. Но и необходимости в них особой нет.
> В общем, не то чтобы для больших проектов перл подходил хуже, чем,
> скажем, JS или питон, но всё же для этого есть более
> подходящие языки - хотя бы плюсы те же, или Си на
> худой конец (на котором я пишу сейчас, если что - так
> что насчёт "худого конца" - из личного опыта).И чем они более подходящие?
> В перле либо
> надо брать какой-нибудь Moose,Или Mouse. Или Moo. Или не брать вообще.
> тормозной до неприличия, либо самому что-то колхозить
> и потом очень жестко следить за стилем, обвешиваться тестами как новогодняя
> ёлка - игрушками...А в Си этого делать не надо?
> В общем, много совсем лишней мороки, от которой
> компилируемый (и статически типизированный) язык избавляет.И Си, конечно, отличный пример такого языка. С развитой системой type inference.
> А вот чтобы быстро наваять пришедшее в голову извращение - CPAN -
> идеален, наверняка все кубики найдутся и можно будет их сравнительно просто
> слепить в кучу.И это, вероятно, чем-то плохо. Тем, видимо, что в кучу они будут слеплены, видимо, криво. А вот если сишные библиотеки неделю по сети искать, и в кучу собирать, то выйдет, видимо, не криво. Магические свойства Си, видимо, тому причиной.
> Для продакшна же разговор совсем другой - качество
> кода очень варьирует, смотреть надо. В половине там такое легаси... чуть
> ли не из четвертой версии, вешаться можно.В других-то языках всё не так, очевидно. Там ведь есть общепринятые средства проверки покрытия кода тестами, всегда можно посмотреть на каких платформах и компиляторах тесты прошли. И только Perl не повезло.
В общем случае - скриптовые языки - это те, которые создавались в расчёте на быстрое написание скриптов - небольших программ, не рассчитанных на долговременную поддежку. Соответственно, в них мало или нет фич, рассчитанных на формализацию и поддержание структуры кода, но замедляющих написание - статической типизации, явного преобразования типов, модулей, интерфейсов и так далее.>Да, средства метапрограммирования через кодогенерацию в Perl традиционно неразвиты, а те что есть - лучше без _крайней_ необходимости не трогать. Но и необходимости в них особой нет.
Ну вот и я о том. К таким штукам надо вообще относиться с осторожностью.
>И чем они более подходящие?
Тем, что меньше шансов нарваться на мину в большом проекте, разумеется. Ну просто в силу внутренней структуры, когда, к примеру, в строковую переменную ты не сунешь float (или - ещё круче - наоборот). Тем, что есть структуры, которым компилятор не даст присвоить частично. И так далее, и тому подобное.
>Или Mouse. Или Moo. Или не брать вообще.
Moose и Moo оба давят производительность примерно на порядок по сравнению с чистым перлом, который по нынешним временам и так не быстр. Почему нельзя не брать ничего - я выше отписал. Слишком много шансов потом нарваться в проекте на десяток вариантов самопального ООП разной степени кривости.
>А в Си этого делать не надо?
>И Си, конечно, отличный пример такого языка. С развитой системой type inference.В си своих граблей хватает, и больше чем хотелось бы - но нет, в нём нельзя присвоить указателю на массив указатель на инт, к примеру. По сравнению с перлом в плане типизации он великолепен. А что лучше те же плюсы - я ж сказал. Или Java/C#. Или Go/Rust/D.
>И это, вероятно, чем-то плохо. Тем, видимо, что в кучу они будут слеплены, видимо, криво. А вот если сишные библиотеки неделю по сети искать, и в кучу собирать, то выйдет, видимо, не криво. Магические свойства Си, видимо, тому причиной.
Ты эти CPAN'овские модули внутри не ковырял, видать. Как ни смешно - но рандомная сишная библиотека в среднем куда лучше качеством, чем рандомный перловый модуль. Особенно если говорить об обработке ошибок, мемори ликах и подобном - что почти не играет роли вскриптах, а в продакшне - очень даже. Я не помню случая, чтобы я что-то незнакомое с CPAN взял и не пришлось разбираться, что там внутре за неонка, в каких случаях она гаснет и почему.
>В других-то языках всё не так, очевидно. Там ведь есть общепринятые средства проверки покрытия кода тестами, всегда можно посмотреть на каких платформах и компиляторах тесты прошли. И только Perl не повезло.
А в других языках обычно имеется какой-то набор билиотек с репутацией, как boost или Qt в плюсах, плюс обычно есть возможность глянуть, что использутеся в мастодонтах вроде какого-нибудь libreoffice или apache. На перле готовых больших ропетов меньше - меньше мест, где можно глянуть. заодно такие проекты, как правило, имеют приличную документацию.
Вообще - чем не устраивате идея, что для промышленных задач надо брать соответствующие инструменты? Одну ямку для саженца можно и ножжом выкопать, для пары сотен - лучше всё же лопата и некоторое планирование, а если многими тысячами - нужна сельхозтехника, договоры на обслуживание, бизнес-планы и т.д.
> Для продакшна же разговор совсем другой - качество кода очень варьирует, смотреть надо.Вот это вы верно подметили, но не назвали причину вариации качества кода. Я вам сообщаю что качество кода зависит от программиста и perl тут имеет сильно опосредственное отношение.
Язык имеет значение. На перле очень легко написать что-то, что будет кое-как работать, из-за этого он многим казался лёгким, и они именно кое-как и писали. И отправляли в CPAN. А чтобы на нём хорошо писать надо знать довольно много, а иногда - ещё и следить за развитием, как было, скажем, с реализацией уникода.
> Язык имеет значение. На перле очень легко написать что-то, что будет кое-как работать, из-за этого он многим казался лёгким, и они именно кое-как и писали.Это безответственный подход к делу низкоквалифицированных программистов. Кто вам сказал что эти программисты будут качественно писать на С++ или Java ? Я видел уже код таких программистов.
> И отправляли в CPAN. А чтобы на нём хорошо писать надо знать довольно много, а иногда - ещё и следить за развитием, как было, скажем, с реализацией уникода.
Надо следить с любым ЯП или средой которая развивается и может меняться. Не хотите следить - пишите все на С89 используя лишь стандартные библиотеки.
Вцелом же, чтобы быть грамотным и высококвалифицированным надо владеть хорошо своим инструментом с которым работаешь. Perl или Java - тут вопрос другой. Но да, perl дает гораздо больше свободы, а свобода подразумевает ответственность. Не все могут в руках удержать perl, не всем это дано.
>Это безответственный подход к делу низкоквалифицированных программистов. Кто вам сказал что эти программисты будут качественно писать на С++ или Java ? Я видел уже код таких программистов.А кто спорит? Я говорил о том, откуда в CPAN взялась гора кривого кода. Его часто вообще не-программисты писали. Или писали, не рассчитывая, что оно будет использоваться в каких-то отличающихся условиях.
А на плсюах такая ситуация встречается реже - там нет той иллюзии лёгкости, которая есть в перле, там понятно, что язык надо знать. Насчёт джавы - не знаю.
> А кто спорит? Я говорил о том, откуда в CPAN взялась гора кривого кода. Его часто вообще не-программисты писали. Или писали, не рассчитывая, что оно будет использоваться в каких-то отличающихся условиях.Сложно сказать. Я не думаю что мне добавит чести выступать в роли судьи в случае когда человек пишет код для своих задач и публикует его безвозмездно. Думаю что лучше хоть что-то иметь чем вообще ничего, и в таком случае если модуль станет востребованным, то возможно найдется тот кто его поддержит (пример: http://habrahabr.ru/post/258549/).
> А на плсюах такая ситуация встречается реже - там нет той иллюзии лёгкости, которая есть в перле, там понятно, что язык надо знать. Насчёт джавы - не знаю.
Легкость в perl позволяет не фокусировать внимание на том как написать код и позволяет больше времени уделить прикладной сути задачи и структуре проекта. В "бюрократичных" языках вроде С++ кроме того что нужно заниматься прикладной сутью и структурой проекта, нужно удовлетворить всем требования бюрократ^\W компилятора чтобы код наконец-то скомпилировался. В Java, С++ (хотя в С++ можно при большом желании) и других "бюрократичных" языках нельзя просто взять и решить задачу, надо возиться, возиться и еще раз возиться. А если вдруг изменится у вас тип или схема организации с нарушением наследования - так это уже настоящий ад на пустом месте. Не знаю как вы, но меня сильно раздражает тратить свое время на возню с типами (вроде ошибок компиляции из-за того что в 100-м уровне наследования в boost где-то сломалось приведение типов), и классами когда надо решать прикладную задачу. Хоть я и пишу на Java и С++, мне все равно сильно больше нравятся perl и си.
> И тем не менее, для написания сложных программ всё в perl/cpan имеется.
> Например, есть ли в каком скриптовом языке профайлер уровня NYTProf, или
> доступ к компилятору кода, или синтаксическому дереву?python. а вот давайте вы покажете как в perl в рантайме можно добавлять новые синтаксические конструкции в язык. например, goto.
>> И тем не менее, для написания сложных программ всё в perl/cpan имеется.
>> Например, есть ли в каком скриптовом языке профайлер уровня NYTProf, или
>> доступ к компилятору кода, или синтаксическому дереву?
> python.профайлер назови, хотя б :)
> а вот давайте вы покажете как в perl в рантайме можно добавлять новые синтаксические конструкции в язык. например, goto.
в perl, в отличие от того же python, goto уже есть :D Так что покажи как это можно сделать в питоне, раз уж взялся безапелляционно отвечать.
>профайлер назови, хотя б :)Тысячи их! (с)
cProfile, line_profiler, plop.
на linux еще пробы для systemtap, а в pypy - только появившийся vmprof.> Так что покажи как это можно сделать в питоне, раз уж взялся безапелляционно отвечать.
>Тысячи их! (с)и все они - гавно)
> cProfile, line_profiler, plop.
plop так вообще не для питона, а все остальные - таки мелочи.
>http://habrahabr.ru/post/140356/
Оттуда:
>Так как питон имеет ряд ограничений по синтаксису, то команды вида
>a:
>goto a
> сделать не удастся.fail, бессмысленный и беспощадный)
В perl можно не залезая в байткод легко и просто добавлять новые инструкции: http://sprunge.us/RMLC?pl
Простите, а можно не добавлять в рантайме новых синтаксических конструкций в язык, если этот язык не Lisp?
Спасибо.
> Простите, а можно не добавлять в рантайме новых синтаксических конструкций в язык,
> если этот язык не Lisp?
> Спасибо.можно. патчить байткод или ковырять AST.
Перл мертв.
> Перл мертв.Не люблю гуманитариев, больше уважаю тех кто занимается точной умственной деятельностью. Читаем внимательнее:
> После года разработки представлена новая стабильная ветка языка программирования Perl - 5.22. При подготовке нового выпуска было изменено около 590 тыс. строк кода, изменения затронули 2400 файлов, в разработке приняли участие 94 разработчика.
Точной умственной деятельностью?vs
https://github.com/rust-lang/rust
https://golang.org/CONTRIBUTORS
Ты что-то хотел сказать?
> Ты что-то хотел сказать?То что пёрл - мёртвЪ! (С)
О да, это, конечно, очень показательно.
https://github.com/python/cpython ваще мертвее даже perl'а получается?
Угу. Правда, живого работающего кода на перле роаз в тысячу больше, чем на этих двух вместе взятых, но это мелочи, конечно. Главное - количество коммитов, что же ещё.
...тем более на гитхабе, который младше *пятой* ветки в 2 раза.
> Угу. Правда, живого работающего кода на перле роаз в тысячу больше,Где? Из мира во FreeBSD - выкинули, в Линуксах тоже - везде питон.
Посмотрел на версии перла (я олдскул - у меня он на всех юниках всегда есть!):
В продакшене и под нагрузкой: от 5.10.1 до 5.14.2 (и даже v5.8.4 built for i86pc-solaris-64int :)
В продакшене second line, присматриваюсь: 5.16.3(Centos) и v5.20.2(FreeBSD 10)
И только в джесси к которой тоже присматриваюсь - тоже v5.20.2>Главное - количество коммитов, что же ещё.
Скорее - количество новых проектов начатых с использованием языка. Но тогда - перл мёртв. :(
Насчёт BSD не знаю и знать не хочу. В дебиане и генте перл в дефолтной поставке. Хотя суть не в дефолтах, а в количестве софта, который на нём написани работает. Наерное, одного SpamAssassin больше копий крутится, чем копий всего софта на Go и Rust.Кстати, в дебиане куча служебки на нём - начиная с кусков dpkg и debconf и заканчивая tasksel. В генте тоже служебных скриптов хватает.
А новые... я всякими поветриями не особо интересуюсь. Вон, пару лет назад все на Ruby кинулись - и где тот Ruby?
> Насчёт BSD не знаю и знать не хочу. В дебиане и генте
> перл в дефолтной поставке. Хотя суть не в дефолтах, а в
> количестве софта, который на нём написани работает. Наерное, одного SpamAssassin
> больше копий крутится, чем копий всего софта на Go и Rust.Зачем этот тормоз и поглотитель ресурсов, если есть rspamd?
Ну и если вы упомянули Go: сколько времени у вас займет написание простенького http-сервиса, который умеет раскладываться по ядрам и может держать сотни тысяч запросов в секунду?
> Где? Из мира во FreeBSD - выкинулиЕго выкинули потому что он там нафиг не сдался: в базовой системе ничего не перле не было, и стоял он там, по сути, для галочки. При этом его надо было поддерживать, и он по мере устаревания поддерживаемых релизов FreeBSD сильно отставал от актуальной версии в портах. При этом огромное количество софта из портов просто ставило себе свежий перл из портов же. Собственно с тех пор софта на перле в портах стало только больше.
>> Угу. Правда, живого работающего кода на перле роаз в тысячу больше,
> Где? Из мира во FreeBSD - выкинули, в Линуксах тоже - везде
> питон.Расскажите пожалуйста подробнее про питон в base FreeBSD :)
А если машина хотя бы чуть серьёзнее роутера, Perl по любому будет установлен из портов. Вот поизучайте, какой софт от перла зависит: http://www.freshports.org/lang/perl5.20/
git, vim, qemu, gcc5... да вы сами посмотрите, там интересно.
Когда уже будет Perl7?
Тебе циферки или работать?
> Когда уже будет Perl7?ln -s /usr/bin/perl /usr/bin/perl7
Проблемы у людей бывают очень разные, некоторые решить очень легко :)
а пегл6 когда уже родят?;)
> а пегл6 когда уже родят?;)Нудк, новость-то кто за тебя читать будет??! (6.00-5.22) / ( 0.01 / 3 месяца ) = ...
Думаю, большинство перл программистов знают и С, Java много чего другое. Из тех кого я встречал - это обычно это скромные и самодостаточные программисты или админы (так сказать старой закалки ребята!). Большинство их ненавидят за их любовь к перл, но уважают их, это однозначно. Сам я, скорее любитель перл, не профессионал, но пару раз он здорово выручал когда надо было быстро и качественно сделать сервисы по сборке, разборке, фильтрации и рапределению почты и данных с базы. Наверное это можно было бы сделать и на питоне, но это лично мой опыт, отсюда и лично мое мнение о перл. В случае перл, как языка программирования, конечно он не для новичков, что бы ее изучить нужно, как минимум, терпение, а любовь к нему, в моем случае, пришла с годами! ;-)