На проходящей сегодня виртуальной конференции разработчиков языка Perl анонсирован проект Perl 7, который плавно продолжит развитие ветки Perl 5 без внесения радикальных изменений. Perl 7 будет аналогичен выпуску Perl 5.32.0, за исключением иных настроек по умолчанию, лучше соответствующих современной практике разработки. В остальном Perl 7 останется тем же Perl 5 и сохранит совместимость с ранее разработанными приложениями...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=53226
Видать раку не взлетело
Я думаю с самого начала было понятно что он не станет прямым продолжением перла
Взлетает, только не в ту сторону.
лебедь, щука и ракперл7, перл5 и раку
Забавно, с PHP та же история была. PHP 6 не взлетел, про него решили забыть и после 5 сразу перешли на 7.
ну причины там совершенно другие. кроме совпадения цифр, ничего общего.
Что такое PHP 6?
счастливый ты человек...
Попытка перевести php на unicode. А так же добавить не мало новых фишек, которые частично были утащены в пятую ветку, вроде пространства имён, а частично перекочевали в седьмую.
К сожалению перелопатить весь код без отвала кучи модулей расширений не получилось. Однако к этому моменту уже вышли несколько альф php 6, было издано несколько книг и им пришлось перескакивать сразу на php 7, чтобы не вводить людей в заблуждение.
с вендой то же самое, после 8 сразу на 10 - так же быстрее версии растут.
Там был аргумент, что многие стврые программы проверяют наличие девятки в версии, чтобы определять 95 и 98 версии Windows. Они типа не хотели ломать совместимость с этими программами и поэтому после 8 выпустили сразу 10.
После PHP 7.4 будет PHP 8
И побарабану что не 7.5
там будет JIT, это мажорное изменение, все правильно делают
С тем же примерно успехом: выбросили некоторые функции, не дав прямой замены.
В итоге старый код приходится катать под 5.x. Т.к. бюджет на "переписать то же самое, но под 7.x" почему-то не выделяют. (А на php, внезапно, не только сайты писали.)
это что они там такое выкинули, что заменить нельзя?
> это что они там такое выкинули, что заменить нельзя?Всё можно. Но денег сто́ит. Навскидку:
ereg_replace() >> preg_replace()
Но есть нюанс: первый использовал posix-синтаксис, а второй изображает PCRE.
Чтобы перевести одно в другое, надо знать *оба*.
Функции ereg_* были объявлены deprecated в версии 5.3, т.е. 11 лет назад.
И preg_* не изображает pcre, а использует эту либу.Я знаю тех, кто до сих пор сидит на 5.2 только потому, что лень, не охота им свою CMS перевести с php_templates (хотя либа есть для 5.3 хотя бы) на что-то другое, нет желания убирать magic_quotes и register_globals и ещё кучу всего, что за 10+ лет можно сделать без проблем и совершенно не напрягаясь.
А все их разговоры про деньги и прочее -- отмазка, желание за счет клиента решить свои проблемы.
2024: Perl 7 решено переименовать в Lana
Lama
Она? http://winamp.com
Кстати, если кому интересно:
DirectSound плагин вывода с поддержкой ресемплинга https://audiophilesoft.ru/articles/winamp/out_ds_ssrc.7z
Поддержка Opus https://mega.nz/file/CNgSiS4a#sp1FMovuIgJo0b5_po3enbrYCXm8Za... скопировать с заменой в корневую директорию проигрывателя.
Зря минусуете. Плеер избавляется от несвободных компонентов (из-за этого исчезла поддержка AAC на XP, так как там нет декодера от MS). Не удивлюсь, если станет opensource, а может кто-то портирует и под Linux. Ведь уже существовала давно нативная сборка.
да просто XP-проблемы тут никому не интересны, начиная с висты (а это было 13 лет назад, карл) появился божественный WASAPI, который сам отлично умеет в ресемплинг, например.
Я на Win7 тоже включал плееровский ресемплер, как-то не понравился мне системный. Но это чистая субъективщина, тесты я не делал.
У вас эти файлы играют как чистый тон без похрюкивания?
https://forum.audacityteam.org/download/file.php?id=18385
https://forum.audacityteam.org/download/file.php?id=18386А виста была неплохой системой. Жаль, что сейчас смысла в ней нет.
> виста была неплохой системойКрасивой, в смысле. Когда XP совсем загнется, буду изучать ее.
Еще мне нравились первые сборки восьмерки.
да, никакого похрюкивания нет. а во что их ресемплить надо, один 16/44, второй 16/44?
у меня одна звуковуха работает в 24/48, другая в 24/192, десяточка.что характерно -- от bit perfect я отказался т.к. системный апсемплинг 16/44 в 24/192 мне даже нравится больше, чем bit perfect (гораздо больше чистоты по верхам).
тьфу, т.е. второй 16/48
«Winamp, it really whips the llama’s ass»
No llama will be abused.
"¿Cómo te llamas?" :)
Есть куча языков, которые спокойно себе развиваются десятилетиями. Awk, tcl/tk... но только perl колбасит и колбасит. Все какие-то громкие заявления, великие планы, непреодолимо привлекательные (нет) фичи...
Наверное потому что ими никто не пользуется? ¯\_(ツ)_/¯
Ими пользуются 100% линуксоидов и бсдишников, просто не все они об этом знают.
Угу, то-то с 2.х питона все никак не слезут. Какие там слухи по RedHat/CentOS 8, отключать будут? Или через пять лет в RedHat 9? =)
На самом деле, еще как слазят.
У второго питона EXPIRATION DATE: 2020-12-31, и на данный момент пакетов жестко завязанных на него можно буквально по пальцам посчитать.
Это во FreeBSD у него EXPIRATION DATE, а официально он уже сдох 1 января. В портах зависящей от него тухлятине просто так и быть дали ещё повонять до августа.
> Это во FreeBSD у него EXPIRATION DATE, а официально он уже сдох
> 1 января. В портах зависящей от него тухлятине просто так и
> быть дали ещё повонять до августа.Ну, я когда последний раз пытался обновить мир без него (на домашней генте) пара пакетов с заявкой на второй питон таки выползло. Если память не изменяет - gtk2, setuptools и что-то там еще. Так что вонять еще воняет. Но видимо не долго осталось.
Setuptools уже можно без второго. А gtk2 уже никто заниматься не будет, поэтому уйдёт вместе с второпитоном.
> Все какие-то громкие заявления, великие планы, непреодолимо привлекательные (нет) фичи...Так они же лингвисты, а не разработчики.
А какие заявления вы услышали про perl 7? В новости же явно написано что 7 это спокойное развитие 5. Вы перепутали с perl 6.
Я использую Linux более 10 лет. Лет 8 назад собрал свою первую gentoo, сейчас в основном на Arch. Виду активную разработку нескольких проектов на разных ЯП. Ни разу я не использовал и даже не видел awk и tk. Никогда не сталкивался и небыло необходимости их использовать.
Только несколько дней назад радовался о том, что Perl5 не лезет в гонку версий и наращивания ненужных фич, и понемногу оттачивает уже сформировшийся язык, не ломая совместимость. Видимо сглазил.От Perl 7 двоякое впечатление. С одной стороны хорошо, что ломать как в Python 3 ничего глобально не собираются, наломали уже в Perl 6. С другой стороны, "open(FH, $file)" и "$cgi = new CGI" довольно часто встречаются и используются. Какой смысл нарушать совместимость по дефолту ради самого изменения? Те кому надо и сами все эти настройки ставят. Ну будет в скрипте на строку "use strict" меньше и что, зато сломают кучу старых скриптов. Толкут воду в ступе и пытаются на пустом месте видимость бурной деятельности создать. Новичков не привлекут, а оставшихся разработчиков растеряют.
Еще добавлю про "use warnings", после common::sense этот "use warnings" кажется одной большой ошибкой, которую никто не хочет исправлять.
> Какой смысл нарушать совместимость по дефолту ради самого изменения?Вот мне интересно. Ладно, вы новость не читали. Ладно, в языке ничего не понимаете. Но понимать-то что не читали и не понимаете на минимальном уровне вы должны, чтобы такой чуши не писать и не позориться?
Не только перловцы (и перловки) страдают сейчас имитацией бурной деятельности, этот вирус захватил почти всех. Вот кто сейчас НЕ страдает переименованием слов black/white? (привожу слова в словарном порядке, а не потому, что негры доминируют над белыми).
> привожу слова в словарном порядкеЭто ты сейчас намекнул, что неплохо бы провести ревизию алфавитов, я понял!
> Вот кто сейчас НЕ страдает переименованием слов black/white?https://github.com/Perl/perl5/search?q=blacklist+whitelist&u...
> black/white? (привожу слова в словарном порядке,
> а не потому, что негры доминируют над белыми).А вот в русском языке порядок этих слов - другой. Но у русов принято не доминировать над остальными, а принято брать всех под своё крыло и защищать (от неразумных хазаров и т.п.)
> "$cgi = new CGI" довольно часто встречаются и используютсяКстати да. Вот в С++ наоборот собираются unified syntax вводить, чтобы и object.function(arg) работало, и function(object, arg). A в Перле наоборот убирают :(
Лучше бы за оптимизацию производительности интерпретатора взялись, добавили JIT и компилятор написали.
Вот да.
Но это же работать надо! То ли дело запрещать используемые фичи!
Так raku же. Ешьте, не обляпайтесь.
Который, внезапно, медленнее.
Ради интереса, чем не угодили Perl::Strip, Perl::Stripper? И можно пример юзкейса, где важна именно производительность интерпретатора? Просто интересно. Потому, что вопросы производительности в 99% решаются сишкой, а не интерпретатором, JIT и прочей лабуденью, которая предназначена для очень специфичных случаев и в случае Java, ее JIT это скорее недостаток, чем преимущество.
>И можно пример юзкейса, где важна именно производительность интерпретатора? Просто интересно.spamassassin + busy email server
использовать больше 1 инсталляции Spamassassin не приходило в голову? 5-10 и перед ними пару Nginx с VIP в качестве proxy?
У spamd есть параметры командной строки --max-children и --min-children. Попробуйте догадаться о чём они. (Хинт: создатели SA не страдали контейнеризацией головного мозга, учитывайте это)
спасибо, но я в курсе про эти параметры. о контейнерах в данном случае не сказал ни слова. к чему твой пафосный перформанс - не пойму
> не поймуЭто ожидаемо.
ещё больше пафоса? диагноз вырисовывается - тщеславие уровня "черепаха"
> использовать больше 1 инсталляции Spamassassin не приходило в голову? 5-10 и перед
> ними пару Nginx с VIP в качестве proxy?Я думаю вы согласитесь, что это не ответ на заданый вопрос, на который я отвечал.
А так да, есть тоже варианты костылей решения первоначальной проблемы...
>> использовать больше 1 инсталляции Spamassassin не приходило в голову? 5-10 и перед
>> ними пару Nginx с VIP в качестве proxy?
> Я думаю вы согласитесь, что это не ответ на заданый вопрос, на
> который я отвечал.
> А так да, есть тоже варианты костылей решения первоначальной проблемы...по-твоему метод простой балансировки - костыли? то-есть всё остальное - инвалиды что-ли? ты из другой вселенной? отвести тебя к нашему лидеру?
> по-твоему метод простой балансировки - костыли? то-есть всё остальное - инвалиды что-ли?
> ты из другой вселенной? отвести тебя к нашему лидеру?Блин, бублички, что ж вы тут все такие агрессивные то ?!
Поймите, вы говорите о разных вещах, если бы spamassassin и amavis были бы написанны на компиляторах, то их производительность была бы выше !!!
Мы здесь о интерпритаторах, а не том как резолвить батлнеки...
Это как спорить что же быстрей - велосипед или мотоцикл...Или вы считаете что будь spamassassin написан на cях - это плохо для скорости ???
ты рассуждаешь на уровне "если у бабушки был бы ... - она была бы дедушкой". реалии таковы что Spamassassin написан на Perl и переписывать его никто не собирается. и рассуждать об этом мне видится совершенно бесполезным, взамен надо искать обходные пути, один из которых я описал выше. но я конечно не вправе мешать тебе мечтать о том чего нет и скорее всего никгда не будет
ОП: - "Где бы пригодилась скорость велосипеду?"
Я: - "Ну, например на скоростной трассе"
Бублики: -"Надо просто прикрутить турбину к велосипеду и нечего гнать на велосипед !"
Я: "Вопрос не как, а где !!!"
Бублики: -"Никто не будет ездить на скоростной трассе кроме как на велосипеде,
поэтому - только турбина, все остальное - от лукавого"
Я: - А человек читает вообще что написанно или это просто плохо работающий бот???На этом и закончим наверное...
Глянь https://rspamd.com/
Сам не пробовал, слышал о нем давно, раньше не было многих фич. Сейчас возможно все изменилось.
> Глянь https://rspamd.com/Да, работает значительно быстрей чем СА, надеюсь добавят скоро еще сканирование ПДФ
>spamassassin + busy email serverИ какой у вас трафик? Это риторический вопрос. У вас я понимаю компания в 3 тыс.+ человек (или не в мэйл.сру случаем работаете?) и вы всю почту держите на 1м сервере? Вы нормальный? Видимо нет, потому что я тоже крутил сервера с приличным потоком писем, по 20 тыс. в день, стабильно. И знаете что? Спамассасин работал идеально, когда все настроено как надо.
Кроме того, в самом SA есть масса багов, которые его могут застопорить на пустом месте. Да, вот просто приходит письмо с "особым" контентом, а SA на нем виснет. Потому что г-код, который нужно лично вам, как и лично мне, было разгребать. И дело там было не в интерпретаторе, как это для вас ни странно.
Ну, а с точки зрения программиста-сисадмина, могу смело сказать, что SA нужно менять на что-то более современное. Не обязательно на си или плюсах (это было бы в идеале). SA это легаси код, который без переписывания отлично решается путем распаралелливания трафика по нескольким серверам.
Если вы вдруг считаете, что перл отличный язык для этой задачи, то я не стану спорить. Только не надо ляля тополя про интерпретатор, когда основная нагрузка это парсинг данных, а не файла скрипта. Никто не запрещает держать один экземпляр кода в режиме сервера, в мультипотоках, просто в процессах, чтобы он читал данные. И как я и говорил, лучшие парсеры текста и бинарных данных все написаны на сишке или плюсах.
Не думаю, что вы что-то из этой информации вынесете полезного, т.к. претензия к перлу из-за SA, это извините... верх не.. профессионализма. Или я хз за что вам платять ЗП.
> Вы нормальный?A Вы? Я ответил на вопрос, где скорость языка была бы далеко не лишней... как пример, о котором спрашивали
Вы же начали мериться письками кто и сколько юзеров на емэйл серваках поимел... но в итоге все свели к тому, что хорошо бы все таки на сях, ибо скорость...
Вы видели где то мои "претензия к перлу из-за SA" ???
Я понимаю, что у всех бывают плохие дни, но вы все же еще раз прочитайте эту ветку перед тем как кидаться на людей
>>И можно пример юзкейса, где важна именно производительность интерпретатора? Просто интересно.
>spamassassin + busy email serverАх, ты шайтан! Моя вина, а точнее и ваша тоже, отвечать на вопрос, который задан был не вам. Или вам? Я вопрос задал анониму, ответили почему-то вы. При этом, как только пошел серьезный разговор, вы с него съехали и выставили еще меня виноватым. Ну, шайтан, ой шайтан.
Ладно, проехали, звиняюсь, но не искренн. Ждем, тому к кому я обращался.
> Ладно, проехали, звиняюсь, но не искренн. Ждем, тому к кому я обращался.Да, запутаться здесь иногда можно, так что по пивку, за миру - мир, войне-пиписька :)
> вопросы производительности в 99% решаются сишкойС этим зачастую сложности организационные.
Дааа, организационные. Найти XS-шника сложно =)Вы знаете, когда лично я рассказывал про XS при найме на работу на меня все смотрели глазами рублевыми монетами и не понимали моего восторга от XS. Как только слышали про Си, то сразу тема плыла в русло "а это же небезопасный код", "а это же сложно", "а вы понимаете мы ищем тру перловика/тру сишарпщика" и т.п. херь. Но чето никто из них не ругал сишный DBD::mysql, сишный DBD::Oracle, сишный LibXml2 и т.д.
Более того, спустя несколько лет я столкнулся с тем, что на сишарпе часть кода все еще приходится лично самому писать на winapi на сях. Потому что никто не писал этого кода ни для вас, ни для меня. И уж я могу гарантировать, что мало кто лез в исходники .Net Core и видел внутри что? Правильно чистую, кристальную как роса, сишку.
> Но чето никто из них не ругал сишный DBD::mysql, сишный DBD::Oracle, сишный LibXml2 и т.д.Шта?!
https://www.cvedetails.com/vulnerability-list/vendor_id-1962...
> то сразу тема плыла в русло
> Но чето никто из них не ругалИменно поэтому было бы неплохо гнать из профессии как можно больше скриптовиков без знания цэ и минимальных знаний архитектуры. "Жаль что пожить в эту пору прекрасную...".
> в 99% решаются сишкойПыхтачки почему-то не стали писать на си экзешники, а придумали пыхпых.
Тем не менее существуют всякие PHP Extensions
>> И можно пример юзкейса, где важна именно производительность интерпретатораинтерпретатор JavaScript в браузере - подойдёт такой пример? а NodeJS? Я так понимаю ничего "экстра большого" (NodeJS) или "экстра важного" (как в браузере) просто на Perl не делали и нокогда? так он и остался "удобно для однострочников" - им то скорость интерпретатора нее так важна.
>интерпретатор JavaScript в браузере - подойдёт такой пример?Нет. Когда перл будет встроен в браузер тогда "пойдет". Наезд был к интерпретатору перл, а не вообще вселенной интерпретаторов.
>Я так понимаю ничего "экстра большого" (NodeJS) или "экстра важного" (как в браузере) просто на Perl не делали и нокогда? так он и остался "удобно для однострочников" - им то скорость интерпретатора нее так важна.
Наоборот, очень много оптимизировал, но у меня решения были все на клиент-серверной архитектуре (нет, это не REST-сервисы и вообще далеки были от HTTP). Были случаи, где надо было много запускать через fork+exec. Решал с помощью staticperl от Марка Леманна. В нем как раз и есть то, о чем я говорил: вырезка комментов, пробелов и других символов из кода через Perl::Strip.
Кодген вливаемый в eval пытался избегать. Вы знаете примеры лучше? Как решали проблемы? Расскажите, а не просто кидайтесь какулями. Мне интересно, будем как на HN делиться опытом.
>> Расскажите, а не просто кидайтесь какулями.Ой, Извините! Это Я не верно выразился -
>> Я так понимаю ничего "экстра большого" (NodeJS)
>> или "экстра важного" (как в браузере) просто на Perl не делали и нокогда?- я имел в виду - что ВООБЩЕ на Perl нет крупных проектов - ВООБЩЕ НЕТ! - поэтому (одна из главных причин) Perl и ***не развивается*** - Perl так, пускалка однострочников и толкала внешних тулов, поэтому "зачем ему производительность интерпретатора".
Что такое крупные проекты? - Это MS Word, и это OpenOffice. Даже так - Крупные и Сложные! И таких много. А раз возникает "сложность" то возникает нужда её забороть. Как забороть? - А выработать "приёмы", может расширить язык для их ("приёмов")эффективной работы, оптимизировать что-то, улучшить и т.п. А на Perl просто не случилось этих огромных проектов которые бы подтолкнули к развитию язык\интерпретатор. Всё это моё IMHO конечно.
Интересно, множество пользователей раста пересекается с множеством перловиков? Новости очень похожи по стилю (и частоте) :)
Просто Максим пытается пожертвования отработать.
>Просто Максим пытается пожертвования отработать.Телом торгует, в общем. 🤑
С джесистами пересекается.
Ну чо, кто там из перловиков смеялся над потерей совместимости между питоном 2 и 3 и говорил что вот у них такого никогда не будет?
А где потеря совместимости то?Ну а то, что придётся переписать скрипты, которые 10 лет назад написаны... Нет, не придётся, так как все изменения, которые сейчас прибьют гвоздями, уже тогда считались хорошей практикой.
А если на "хорушую практику" забил при написании актуального кода, сделав всё так же, как во времена, когда этого вашего пихона ещё не было даже, то сам дурак.
Есть конечно же и легаси... но для неё 5.32.* будет ещё долго.
Парадокс написания кода в том, что «дурак» вроде бы программист, его написавший, а крайний и отхватывающий кучу проблем из-за говнокода - конечный пользователь.Это к слову о том, что даже если кто-то там и «дурак», то разгребать проблемы с неподдерживаемыми из-за более строгих требований пакетами и модулями придётся конечному Васе в ходе обновления, точнее, поломок в ходе или по итогу обновления.
Как вы не понимаете! Это другое!(Ц)
В перле ломка началась примерно с 5.18-5.20. Плавно и постепенно он меняется, а не ломается так, что полкода надо переписывать. Так что сравнение с питоном не уместно.
> предусмотрена возможность возвращения поведения Perl 5 через добавление в код строки "use compat::perl5"Ну чо, когда ты русский язык выучишь и новости читать научишься?
use strict; у перловиков уже совсем, совсем давно. без него даже минутный скрипт одноразового применения пишут далеко не все - уже на уровне рефлекса.
http://blogs.perl.org/users/leon_timmermans/2020/06/not-quit...
Ждём выхода "Perl 8"! И попутное объявление от том, что "Perl 5" и "Perl 6" устарели, что они больше поддерживатся не будут.
сразу Perl 9, а то ковид, карантин, перловцы пропустили время выпуска Perl 8
>без ощутимого нарушения обратной совместимостиТы понимаешь что тут написано?
>>без ощутимого нарушения обратной совместимости
>Ты понимаешь что тут написано?А оценку "ощутимости" нарушения будут проводить диктаторы по своему усмотрению, ну там, для начала:
"... Косвенная нотация вызова объектов ... - устаревший способ вызова ... вместо ... нужно будет всегда использовать ...
Голые файловые дескрипторы без объявления переменных ... - использование конструкций вида ... будет приводить к ошибке, нужно использовать ...
Фиктивные многомерные массивы и хэши в стиле Perl 4 ... будет приводить к ошибке, нужно использовать ...".
А у кучи васянов-админов в провинциальных телекомах/заводиках/конторках при переходе с 5-го на 7-й перл отвалятся всякие полуподвальные наколенные перловые биллинги/crm-ки/могучие админские скрипты-портянки, которые им по наследству достались от ушедших на пенсию седых бородачей в свитерах. И придется сидеть на протухшем пятом перле, который по-умолчанию перестанут со временем в дистрибутивы совать, ибо "7 перл - это мягкое продолжение 5-го без ощутимого нарушения обратной совместимости, а в пятый уже не поддерживается создателями". Ну или будет как с 6-м - со временем кол-во этих неощутимых нарушений поднакопится ("количество перейдет в качество") и придется перл 7 переименовывать в "shchuka". А пятый тогда логично переименовать в "lebed'" - ну чтобы "lebed', raku и shchuka" воз тянули.
> А у кучи васянов-админов в провинциальных телекомах/заводиках/конторках при переходе с 5-го на 7-й перл отвалятся всякие полуподвальные наколенные перловые биллинги/crm-ки/могучие админские скрипты-портянкиЗачем переходить на новый perl со старыми "биллинги/crm-ки/могучие админские скрипты-портянки"?
Имитация работы?
Зуд "у меня не распоследняя версия"?
> А оценку "ощутимости" нарушения будут проводить диктаторы по своему усмотрениюнет конечно устроят голосование с коэффициентами, типа SJW, извращенец - x10.
> А у кучи васянов-админов в провинциальных телекомах/заводиках/конторках при переходе с 5-го на 7-й перл
ничего не отвалится. там будут стоять необновляемые с 5 перлом сервантики (ну или докеры, если васян моднявый). всё как всегда.
Просто запустите 2to3, говорили они...
Perl 6 это другой язык, у тебя совсем в голове каша.
а вот лисп живет вне зависимости от левой пятки всяких обгвидков и ларрей. Никакого шестого перла и третьего питона с недотипизацией.
Я не поддерживаю влияние левых пяток, но пример Лиспа неудачен -- живёт он хоть и без пяток, но не очень-то хорошо.
Сможешь перечислить текущие реализации lisp и их совместимость друг с другом? Специалист по lisp из тебя так себе.
Это про какой из 1000 вариантов лиспа? Мамкин лисповец тут нашелся.
>а вот лисп живетНах так жить.
Даже Довлатова процитровать захотелось:
"Личные вещи партизана Боснюка. Пуля из его черепа, а также гвоздь, которым он ранил фашиста..." Широко жил партизан Боснюк!
> лисп живет вне зависимостиТы про который лисп? CL, Scheme, Closure? По сколько там реализаций каждого ныне здравствует независимо от угнетателей? И насколько они между собой совместимы?
Scheme и Closure - это не Common Lisp. Или у вас C, C++ и C# - это тоже несовместимые версии одного и того же языка?
Почитал мнение опытных перловиков на HN в связи с новостью. У перла всё намного хуже, чем я думал -- махровое легаси, которое непонятно, зачем живо. Опытные перловики делятся на совершенно поехавших неадекватов (осталось ощущение, что не слишком и опытные) и сваливших на питон и жс.
Продолжайте наблюдение.
Я был несколько удивлён и расстроен, поскольку у меня после опеннета сложилось мнение, будто перл быстрее питона и куда лучше подходит в качестве замены awk (если его не тащить туда, куда ты не потащил бы awk). По факту получается там скучное-скучное старье, отставшее от реальности лет на 20, не меньше. Один этот факт является весомым доводом против.
т.е. awk это rocket science намного опередивший сегодняшний день ?
Они принадлежат к одной группе "странных" устаревших десятилетия назад технологий. У перла достаточно приятный синтаксис и удобные возможности процессинга текста, хотя некоторые синтаксические решения выглядят _очень_ сомнительными. Awk же вообще тяжело назвать языком программирования (он им является).
Ещё ed|sed обязательно выкинуть. Они ппц как устарели.
Когда чего-то начнёт не хватать — внедрить powershell. (Главное, чтобы бюджет от такого не треснул.)
</sarcasm>
Они не пытаются брать на себя больше и решать неподходящие задачи. Неуместное сравнение.
Почитал тут — сложилось одно мнение, почитал там — сложилось другое… Так и будешь чужие мнения всю жизнь изучать?
> Почитал тут — сложилось одно мнение, почитал там — сложилось другое…
> Так и будешь чужие мнения всю жизнь изучать?Да не, просто тут аргументации ноль. Тут популярно хейтить питон и облизывать перл не вдаваясь в конкретику. В том обсуждении вполне прошлись по конкретике. В целом, я доволен, что не потратил слишком много времени на перл, но могу понять тех, кто в него всерьёз вложился.
Из нынешнего стека актуальных технологий я разве что не вложился особо в пхп, все остальные выбранные мной десятилетия назад сомнительные технологии (python, js, да даже java) на сегодня весьма актуальны на рынке. Кроме того, они разделяют общие принципы и совершенствуясь в одном, ты совершенствуешься во всех. Видимо, 20 лет назад уже можно было предугадать, что будет жизнеспособно.
> отставшее от реальности лет на 20вот в этом то и непонимание, перл силен как раз в той сфере где реальность не терпит радикальных изменений, 20 лет это как раз хороший срок что-бы его любить за это. По опыту, я например пишу порой скрипты на питоне, если требуется какую-то демонстрашку передать коллегам и забыть сразу. А если нужно для себя и чтобы работало без заморочек, пишу на перле, он из скриптовых языков для меня первый native tongue
> он из скриптовых языков для меня первый native tongueЭто только в твоей surrounding wednesday.
гражданин фрактал, залогиньтесь и вернитесь к старому субъекты для наездов.
> По факту получается там скучное-скучное старье, отставшее от реальности лет на 20, не меньше.Это как раз одно из его преимуществ. Второе - куча модулей в CPAN на все случаи жизни. Вместе эти две вещи позволяют писать код, который и через 20 лет будет работать без залезания в него и переделывания. Реально, у меня до сих пор скрипты, писаные на коленке 20 лет назад, работают. Кучу дистров поменял и проапгрейдил, максимум что приходилось делать - зависимости ставить через пакетный менеджер либо напрямую из CPAN.
Как раз недавно думал на что бы его заменить. Так и не нашёл - всё остальное бурно развивается, старые скрипты перестают работать на новых версиях интерпретаторов.
А заменить хочется, ибо синтаксис у перла уж очень особенный - если использовать его раз в 2-3 года (мне просто чаще не надо), то каждый раз приходится долго въезжать в этот долбаный синтаксис (тот же next вместо continue - вроде короче и удобней, но блин забывается про такие нюансы за годы).P.S.: лучше бы сделали "use language::perl7" вместо "use compat::perl5" чтоб старые скрипты не ломались ещё 20 лет...
Опытные перловики горой за перл. Дальше тред HN скатился "что быстрее, телега на двух колесах или телега на трех колесах". Вот, лично я за си. Ни в перл, ни в питоне, ни в руби никакой речи о скорости быть не может! Если кто-то этого не понимает, тот не видел на что способен код на си (которого может даже придется меньше писать, в зависимости от задачи).И спор перл против питона в тестах, где ни перл, ни питон особо не сильны, просто курам на смех. Сраный регепс в пять букв это уровень сишки, т.к. программитса да не в одну строку, но в 3-5 точно, однако, и производительность в 3-5 раз как минимум выше, если не все 20 раз. Для сравнения тут надо брать разницу между index из перла, и string.find() из питона. Эти функции как раз решают регепсы из 5 букв в два-три раза быстрее в большинстве случаев. В случае сишки, тот же index() получается еще быстрее.
И странно, что никто не сказал про актуальную проблему перла -- потоки. Марк Леманн отлично описал в чем ж***тень реализации потоков в перле (читайте доки к Coro, AnyEvent). Ни один икзперт на HN не сослался на него. Не рассказал и про потоки.
Идем дальше, если писать мультипоточный код, то он будет в разы быстрее опять же на сишке/плюсах. Просто потому что там высокая гибкость, а также такой код пишется под конкретную реализацию pthreads (в других ОС может называться по-другому, суть не в этом). Где эта гибкость в перле, питоне или пхп? Нигде, потому что это не их ниша. Не их ниша мерится в скорости.
Поэтому, дорогой Аноним, ты еще не познал настоящего разочарования. Изучай си/плюсы и будешь знать только один устаревший язык (или два), который проживет еще лет 20 точно. Сишке через 2 года будет 50 лет, плюсам через 3 года будет 40 лет.
Спасибо, я выбрал си, потому что плюсы слишком сложные и перегруженные. Так вот, если сравнивать мультипоточность (и мультпроцессность), а также регулярки и всё остальное (они в питоне тоже сишные и могут быть быстрее (и уж точно эффективнее) питоновой реализации при достаточной сложности), то из плюсов у си только скорость. Любая примитивнейшая задача, будь то регулярки или потоки, или скажем tls, требует сотен страниц бойлерплейта. Там где в питоне это 1 функция. В питоне достаточно удобно вызывать произвольный сишный код, поэтому можно легко и непринуждённо получить лучшее от обоих языков. Помнится, у перла это делать не так приятно.ПС. на практике побуквенно искать не варик, без регулярок в обработке текста жизни нет. Регулярки это основные фича и применение перла, потому и сравнивают.
ПС2. мультипоточный код на перле? Вот же извращенцы.
>на практике побуквенно искать не варик, без регулярок в обработке текста жизни нетАга, то-то в ядре postfix нет регулярок; все регулярки там выставлены наружу в виде хелперов (потому что альтернатива была бы в разы сложнее, а именно, писать свой DSL). Разбор домена из имейла побуквенно, разбор IPv4 от IPv6 побуквенно. Ладно, спорить не стану, видимо у всех разные задачи по разбору текста.
Просто я выбираю инструмент после предварительного анализа, а при необходимости и после тестов. Заявлять налево и направо, что регулярки панацея, имхо, удел людей, которые решали задачи абы-как.
Вы сами-то свои регулярки замеряли, оптимизировали, вот чтобы реально решить проблему производительности? Много изхещрялись? Ну вот, была одна большая регулярка, а вы разбили на две-три, но меньше или вообще замещали код на проверку ради одного-двух символов в начале и т.п.? Это так, риторические вопросы.
> Вот, лично я за си. Ни в перл, ни в питоне, ни в руби никакой речи о скорости быть не может
> Изучай си/плюсыhttps://twitter.com/joeerl/status/1115990630793207808
<trollmode>Verilog пусть изучают, если нужна скорость :Ь</trollmode>
Те кто ноет не желает учится новому. И даже страшнее нежелает работать.
попробуйте это сказать systemd-хейтерам
Это другое !
А как это связано?
действительно, это же ДРУГОЕ
> Те кто ноет желает учится новомуУчиться новому - не проблема. Под новый-то язык скриптов народ наваяет на гора! Но вот править тонны старых скриптов под новый язык, чтобы они в нём смогли продолжить работать и дальше... - это не нытьё, а гнев праведный.
шо, опять?
Сравнение с питоном не совсем корректное, особо радикальных изменений в сам язык вроде не предлагается.
Судя по анонсу, им будет довольно легко решить проблему совместимости на таком уровне, для /usr/bin/perl7 включать strict и все эти разумные опции, а для /usr/bin/perl выключать и вести себя как пятый.
Взяли Perl 5, не внесли никаких изменений, назвали Perl 7. Свежо, новаторски, да...
Список изменений перечислен в новости, эти изменения меняют поведение по умолчанию и выпускать их под старой версией было бы верхом непрофессионализма, поэтому очевидно новый номер.
меняют поведение?! переломать существующее - это заслуживает новой версии?
А перечисленное в новости точно было нужно? Так, чтоб вот жить без этого дальше никак. Точно-точно?
> Взяли Perl 5, не внесли никаких изменений,
> назвали Perl 7. Свежо, новаторски,
> да...Так если хотя бы не внесли, то тогда да...
А то не только ж внесли, но и поломали старые скрипты!
Уж лучше бы не внесли, а только номер сменили ну и всё остальное по мелочам типа БолгенОС.
переход на такую мажорную версию был бы хорош если бы *рутины бы запилили как в golang. Без нативной многопоточности в 21 веке делать нечего.
ага, вот только этого нам в однострочниках всегда не хватало
ну, если перловка позиционируется как язык однострочников то у меня нет вопросов.
https://www.nntp.perl.org/group/perl.perl6.language/2003/05/...
> если бы *рутины бы запилилиесть subs::parallel, Paraller::Subs, MCE. каждый со своими хохмами. не то?
ваш покорный слуга больше склонен ко второму варианту. для простых случаев.
Раку повезло меньше.
Рад, что Perl потихоньку развивается. Нормальный язык. Пишу на нем уже много лет. Есть определенные сложности, но они присутствуют везде. Узкие места решаются через XS включением когда на C. Всякие новомодные игрушки вида async/await тоже присутствуют (хотя подобное можно было реализовать еще лет 15 назад, но не из коробки в два клика). Нет такого обилия синтаксического сахара, как в современных языках. Переживем - сахар вреден в больших количествах.P.S.
Если вы будете судить рыбу по её способности взбираться на дерево, она проживёт всю жизнь, считая себя дурой.
Короткие скрипты на перле писать очень удобно. Но вот в таком я так и не разобрался
<code>map { print "\t $_" if (1 x $_) !~ /^1?$|^(11+?)\1+$/ } 1..10001</code>
> Короткие скрипты на перле писать очень удобно. Но вот в таком я
> так и не разобрался
> <code>map { print "\t $_" if (1 x $_) !~ /^1?$|^(11+?)\1+$/
> } 1..10001</code>Подозреваю, что самостоятельно в подобном вообще мало кто разобрался.
вот ведь колдунство! конвертирует число в строку из числа единиц, потом выводит только те в которых
- единица не одна
- и строку нельзя разбить на равоное число груп по две и больше единиц в каждой.
Простые числа выводит короче, доказывая попутно полноту pcre по тюрингу.Разобраться то можно, а вот кто такое придумал?
Действительно.А если не задавать жёстко диапазон, а оформить в виде скрипта, который будет запрашивать ввод у пользователя — получится полезная программа.
"Тому, кто это придумал, надо гвоздь в голову забить" (с) ДМБ
А вообще конечно такие конструкции нужно снабжать комментариями.
А ещё лучше если есть вероятность что это будет видеть хотя бы ещё один человек то не писать так вообще
у этого перла ценность скорее академическая
Никогда не понимал этой тяги отключать то, что работает или менять логику просто потому что кому-то кажется, что это правильный подход. Одного аргумента, что есть старый код, должно быть достаточно, чтобы даже думать в эту сторону не сметь, вообще не пытаться даже.
С другой стороны также не понятно, почему значительные улучшения нельзя делать в рамках одного проекта, тянув за собой весь багаж. Тот же perl6, по сути можно было просто сделать отдельным компилятором, но в тот же байткод, что у perl5 и чуть чуть добавить того, что не хватает. Грубо говоря получалось бы, что perl просто бы по расширению файла или по директиве внутри файла обрабатывал бы код как p5 или p6. При этом сохранялось бы полное взаимодействие кода на разных языках, вплоть до использования модулей одного в другом и наоборот.
Многие возможности вообще можно было в рамках одного компилятора сделать, почему это не понятно? Почему разработчики linux могут в рамках одного проекта фигачить самые разные части, которые вместе то работать не всегда могут, нужно либо одно использовать либо другое, но при этом это один проект, а другие проекты, более мелкие, обязательно скатываются в раскол? Что за детский сад то? Никого же не удивляет, что одни люди используют одну fs, другие другую, но при этом юзерспейсный api доступа к файлам в Linux неизменен уже десятки лет.
> Что за детский сад то?Потому что дети занимаются разработкой.
ну да, в перле только дети :)Вздумалось как-то лет десять назад поискать работу в эту сторону, оказалось что даже есть очень серьезные вакансии. Сходил на пару собеседований, оба случая довольно похожие: первая компания выполняла аккаунтинг для крупного инет- провайдера с 20 миллионов клиентов, второе был ИТ отдел одного подминистерства в сфере больничного страхования (западная европа). В обоих случаях этот весь такой глобальный супер энтерпрайз работал конечно на яве, как же еще, во второй конторе даже везде только AIX. И вот эти супер ява энтерпрайзные конторы имеют по штату по 2-3 очень таких бородатых ребят примерно как Кен Томпсон и Деннис Ритчи, которые на перле парсят логи и генерируют отчеты для начальства. Пополнение им нужно было, даже ведь хотели взять в обеих местах, пришлось вежливо отказываться.
вот ты и рассказал про детский сад.
> Одного аргумента, что есть старый код, должно быть достаточно, чтобы даже думать в эту сторону не сметь, вообще не пытаться даже.Обычно улучшайзингом, свистелками и перделками увлекаются те люди, которые сами не пользуются вещами, которые им чешутся руки улучшить.
Perl-5.10.1 32-bit нереально шустр под виндой на моём устаревшем железе.
Дальше всё богаче и всё тяжелее.Возможно в последствии perl-7 станет for 64-bit systems only,
как и многое в последнее время.
... Реальным наворотам нужно реально много памяти,
реальные юзеры хотят только реально неслабое железо
... другая реальность
Перл шустр? Омг!
Он всё такой же мееедленный???
Нынешняя школота в разработке может только портить.
>> И можно пример юзкейса, где важна именно производительность интерпретатораинтерпретатор JavaScript в браузере - подойдёт такой пример? а NodeJS? Я так понимаю ничего "экстра большого" (NodeJS) или "экстра важного" (как в браузере) просто на Perl не делали и нокогда? так он и остался "удобно для однострочников" - им то скорость интерпретатора нее так важна.
т.е. получается что те кто кричит "он медленный" просто пытаются "накидать" ("накидать"! - именно "накидать" по быстрому) что-то и от этого чего-то сразу же ждут производительности. Производительности же нет, потому что она была НЕ ТАК УЖ ВАЖНА ибо 1) проблема решалась другими способами либо 2) не было таких задач БОЛЬШИХ ЗАДАЧ\ПРОЕКТОВ из-за которых ускорили бы Perl (как было приведено - NodeJS и браузерный код).
> т.е. получается что те кто кричит "он медленный" просто пытаются "накидать" ("накидать"! - именно "накидать" по быстрому) что-то и от этого чего-то сразу же ждут производительностив общем да, именно так обычно и получается. Там вот выше был пример однострочника для получения списка простых чисел, даже не понятно к чему его отнести, такая крутая функциональщина поверх элементарной машины тьюринга. Конечно, скорость у этого алгоритма совсем никакая, но зато как красиво :)
А по поводу сравнений с NodeJS: сравнения не корректные потому что совсем другая парадигма, нода асинхронная и производительность там будет проседать на совсем других операциях чем в синхронном перле. И если уж сравнивать, то вот в начале 2000-х был популярным mod_perl под апач, и по произвидительности он рвал тогдашний php как тузик грелку. Зато имел порог вхождения недоступный для 90% тогдашних веб-разработчиков, не говоря уже о севременных. Короче, сравнения имеют смысл только в контексте применения, большой вопрос есть ли у ноды и перла сейчас где-то пересечения.
Спасиибо за ответ!>>> А по поводу сравнений с NodeJS: сравнения не корректные потому что совсем другая парадигма, нода асинхронная и
Вот может это оно и есть - в Perl не было "асинхронности" и NodePerl не состоялся?
нет, тут история другая, перл был на волне популярности года около 2000-го, и уже к 2005 резко ее растерял и остался в тех нишах где и сейчас. В то время про асинхронность никто еще не думал, максимум в сторону мультитрединга поглядывали, и то в интерпретируемых языках довольно робко. Крупные проекты на нем вполне были, просто они уже давно умерли, Хотя вот, толстая imperia cms даже еще жива курилка, а midgard был мощный фреймворк такой, в него тогда redhat крепко денег вбухал, а сейчас он на php переписан.На самом деле от JS тогда тоже никто ничего хорошего не ожидал, там вообще очень все уныло выглядело, потому что с одной стороны браузерные войны, а с другой тормозил он у всех тогда нещадно. До тех пор пока пара гугловцев не устроили революцию тем что посмотрели внимательно на чем он тормозит и узрели дикий треш с организацией памяти. Помню их докторский тезис года около 2007-2008, нам тогда это открытие тоже немного шаблон порвало, что так тоже можно было. Главное, им тогда удалось радикально изменить модель памяти не сломав сам язык, и родился V8, а потом конечно остальные движки эти идеи тоже переняли. Без V8 нода была бы бессмысленна, а jquery бесполезен, так что можно сказать весь современный ландшафт JavaScript возник благодаря этому. Тогда, около 2008, в jquery вложился деньгами M$, и все завертелось.
Применительно к перлу, возможно авторы по той же причине примерно в то же время стали разбираться со своими тормозами и родили свою parrot vm, вот только совместимость потеряли. В PHP тогда тоже этим занималсь, чуть позже правда, с 5.2 на 5.3 радикально поменяли модель памяти и все вдруг залетало. 2010 это вроде уже был, помнится я в то время в порядке изучения Cи тогда активно их корку дебажил.
> вот в начале 2000-х был популярным mod_perl под апач, и по
> произвидительности он рвал тогдашний php как тузик грелкуА CGI::Fast победил ли этого мод_перла?
врядли, он работает через зокет, это наверняка будет узким местом в сравнении с mod_perl API доступа к обьектам самого апача. В то время о нем особо не было слышно; midgard например работал похожим образом, имел свой аппликационный сервер (на подобии томкэта) которому апач гнал запросы через прокси, но вот имменно этот модуль они не использовали. Хотя, давно это все было.Забавно, http://perl.apache.org/outstanding/sites.html пишет что сайт аdobe.cоm работает на mod_perl, хотя их rоbоts tхt намекает что не совсем:
Disallow: /*Ljava.lang.Object*
Disallow: /*.sql$
>> This morning at The Perl Conference in the Cloud, Sawyer X announced that Perl has a new plan moving forward.Вы поглядите - "moving forward"!!! А forward - это КУДА??? Какую проблему вы решаете этой новой веткой???
>> Расскажите, а не просто кидайтесь какулями.Ой, Извините! Это Я не верно выразился -
>> Я так понимаю ничего "экстра большого" (NodeJS)
>> или "экстра важного" (как в браузере) просто на Perl не делали и нокогда?- я имел в виду - что ВООБЩЕ на Perl нет крупных проектов - ВООБЩЕ НЕТ! - поэтому (одна из главных причин) Perl и ***не развивается*** - Perl так, пускалка однострочников и толкала внешних тулов, поэтому "зачем ему производительность интерпретатора".
Что такое крупные проекты? - Это MS Word, и это OpenOffice. Даже так - Крупные и Сложные! И таких много. А раз возникает "сложность" то возникает нужда её забороть. Как забороть? - А выработать "приёмы", может расширить язык для их ("приёмов")эффективной работы, оптимизировать что-то, улучшить и т.п. А на Perl просто не случилось этих огромных проектов которые бы подтолкнули к развитию язык\интерпретатор. Всё это моё IMHO конечно.
> - я имел в виду - что ВООБЩЕ на Perl нет крупных проектов - ВООБЩЕ НЕТ!Успокойся. Крупный -- это сколько? Считается https://github.com/Logitech/slimserver ?
Обнулили Перл 6?
И сюда добрались модные молодёжные тенденции бессмысленной ИБД. Увы… :-(
> Наиболее заметным изменением в Perl 7
> станет включение по умолчанию режима
> "strict", подразумевающего строгую
> проверку объявления переменных,
> использования символьных указателей
> и присвоения подпрограмм. Использование
> "use strict" является хорошим тономА для отключения этого хорошего (но теперь по умолчанию включаемого) тона теперь надо будет ручками приписывать no script и no warnings к своим скриптам?
Тон-то может быть и хороший. Для новых скриптов.
Но в старых скриптах, написанных без учёта этого хорошего тона, проще будет отключить strict да warning, чем лазить по всем скриптам да подгонять их код под работу в условиях хорошего тона.
> В более отдалённых планах по умолчанию рассчитывают
> включить поддержку Unicode, что избавит разработчиков
> от указания "use utf8"А разработчикам, которым utf8 может помешать, придётся тоже ручками дописывать что-то типа no utf8 к своим скриптам? (ну в качестве фразы "спасибо, не надо")
Leon Timmermans молодец! Всё правильно сказал!От себя добавлю:
Хотите наваять что-то новое без поломки старого? Ваяйте! Но старое не трогайте, если пытаетесь сохранить "совместимость с ранее разработанными приложениями".
А то на тебе! Куча штук, которые могут поломать большое количество скриптов: strict, warning, utf8.
А как вам CGI->new вместо new CGI? Да вебмастера как от чумы будут бежать от этой 7-й ветки перла. И никакими use compat::perl5 их туда с перла5 не переманишь!
Новые скрипты под новые требования писать можно. Они не сильно плохие. Но старому коду в основном будет требоваться перл5 животворящий.
>>>А как вам CGI->new вместо new CGI?Я тоже обратил внимание. Думаю что там (где эти решения принимают) нет спецов\ориентирующихся в других языках (в первую очередь C++\C\Java + скриптовые конечно). Для чего эти специалисты Perl-у? Ну что бы при разработке Perl не наступать на грабли где уже бахнуло в этих других языках кончено. Вот к примеру доступ через "this->" (или self) это явно признак плохого кода(да, такое было "на заре", там ещё его на NULL проверяли!!! сейчас такое может разве что в диких "трюках" может быть)! А в Perl это похоже норма.
Давай я тебя успокою. reg.ru работал еще три года назад на 5.10 и я сомневаюсь, что они с него съехали. 7я ветка это для нового кода, где нет new CGI.CGI выкинули из основной поставки толи 3, толи 4 года назад, а разговоры о выпиливании шли аж 2013 года. Кроме того, примерно с 2015 года мейнстримом стал mojolicious. Вдовесок, много влюбились в тормозной Moose (Moo или хер знает как его сейчас называют). И кто-то выше писал, что self->/this-> это дурной тон, смотрите синопсис https://metacpan.org/pod/Moose Но не думайте, что у него нет поклонников.
Итог. Людям нравится что угодно, кроме реально высокопроизводительных серверов actix, drogon, h2o. А если производительность на 10 месте, то лучше сразу на C#. Там и код читабельный, и потоки нормальные, событийка что надо, SignalR вообще огонь, ну и человечный ООП.
> 7я ветка это для нового кода, где нет new CGI.Против просто 7-й ветки ничего не имею. Для нового кода эта ветка, думаю, должна быть нормальной, т.к. ейные разработчики заявили о том, что они её считают развитием ветки пятой. Ну развитие так развитие - дело хорошое, похвальное. Но только они ж семёрку пророчат в такие разпреемники пятёрки, которая не ломает совместимость старого кода новым требованиям. А из описания семёрки мы видим, что совместимость там в некоторых местах уже поехала.
Делаете новое - ну делайте, конечно, на здоровье. Новый код под новую ветвь народ с нуля-то наваяет. Но просто не заявляйте о совместимосью с ветвью пятой, если реально такой совместимости во многих местах нет. Тогда пользователи "пятого" кода хоть сразу не будут надеяться на то, что их "пятый" код будет гарантированно работать в семёрке и тогда сразу будут про это знать. Предупреждён же = вооружён? А то наобещали народу совместимость, а народ-то отчасти - доверчивый же. И посыпятся у народа системы из (как там выше говорили) скрипто-портянок на местных заводиках/телекомах...
Надо было с 5.22 провозгласить Perl 7. С нее пошли изменения во внутренних API.
Кстати.А запланирован релиз 7-й ветки Перла - так же на Рождество?
Или на этот раз - на Пасху? :-)
Надо наоборот, включать новые дефолты, фичи и так далее по прагме <b>use v7;</b>
но тогда не получится сломать старые скрипты... цель же была - заставить всех переписывать существующее.
perl 7 устарел не родившись, уже есть perl11: http://perl11.org/И нахрена мне это надо? Мне как надо, я настрою perl5, обычно всегда common::sense залетает "на ура". Вот только не надо обо мне заботиться всякими use strict и прочей ерундной, пожалуйста! - Я прекрасно отдаю себе отчет что делаю и как.
Вот же с#ки, лучше бы со smartmatch разобрались до конца или поддержали бы реентерабельность perl5 и pthreads - но это же сложно, а вот bump'ить номер версии - это легко! Нам тут, в perl, слабаков кто ищет легкие пути в perl на#ер не нужно - валите от нас в php, python, js..куда угодно валите!!
PS: Звучит конечно странно, но меня perl спасает от стресса - после изучения и программирования на perl я могу выспаться. Так что с perl я похоже влип конкретно, и это..кайф! :)