Дэн Бук (Dan Book), поддерживающий более 70 модулей в CPAN, провёл анализ рисков при воплощении предложенного плана внедрения Perl 7. Напомним, что в ветке Perl 7 намереваются включить по умолчанию режим строгой проверки "strict", активировать "use warnings" и изменить значение ряда параметров, влияющих на совместимость со старым кодом...Подробнее: https://www.opennet.me/opennews/art.shtml?num=53284
А как же написание обфусцированных однострочников для вызова rm -rf --no-preserve-root /?
Как он связан с Raku?
Да почти никак не связан, Raku теперь другой язык. В предыдущей новости об этом чуть подробнее было, когда 7 версию анонсировали:
https://www.opennet.me/opennews/art.shtml?num=53226
а старый перл по-любрму придётся поставлять ибо на нём dpkg/apt, например.
Ты рехнулся? apt на плюсах. dpkg преимущественно на сишечке, на перле только вспомогательные скрипты из dpkg-dev. И эти скрипты написаны грамотно, вряд ли там вообще какие-то изменения понадобятся для перехода.
Это ты рехнулся, из важного как минимум debconf на перле.
Ну перепишем. Не такая уж и проблема. И времени на это -- вагон. Возможно даже больше, чем сами deb-пакеты проживут.
>Ну перепишемНа python
Во-первых, debconf — это не dpkg и не apt. А во-вторых, ну покажи, где в нём хотя бы один файл без use strict.
Тыщу лет на перл 5 работали и продолжат на том же 5 так и работать.
Опять будет как с питоном 2 и 3.
будет гораздо хуже - никто, кроме полутора больных, ничего переписывать на новый модный не будет. Потому что одни сделались вечноживые, другие торгуют семками, третьи уже лет десять вместо этого пишут на C# и поверщель.Как только бросят поддержку пятой версии - можно будет просто нигде больше эту ненужность и не ставить.
Эх, была надежда после истории с шестым, что хоть тут разум ненадолго победил. Но нет, как это так, ничего не ломать?
>будет гораздо хуже - никто, кроме полутора больных,а ты типа здоровый? =)
перечитай еще раз новость.
чувак близкий к теме гораздо адеватней тебя.
А сейчас 3.5 и 3.7 несовместимы. Регулярно сталкиваюсь.
Не будет!
Популярность Perl уже далеко не что была в еще 10-15 лет назад. Большинство дистрибутивов его даже в минимальный набор при инсталяции не добавляют, что опять же еще 10 лет назад было немыслемо!
Пишу на перле за деньги не первый десяток лет.
Считаю все тезисы высосанными из пальца. Ерунда это всё.
> Пишу на перле за деньги не первый десяток лет.здесь тебе денег не обломится.
> Считаю все тезисы высосанными из пальца.
ну да, ты-то своего дерьма - писатель, пользоваться и вечно башлять тебе за переписывание твоей писанины на модные современные средства вынуждены другие.
Но придется тебя огорчить - этих других скоро вообще не останется (а немногие упершиеся намертво в legacy - так и будут использовать какой-нибудь 5.10, именно потому что legacy) - и остаток жизни проведешь ты на помойке.
В Букинг.ком судя по всему еще долго будут таких держать как минимум.
ну ок, целых два рабочих места.Да и то не факт - придет новый менеджер, и обоих "при помощи ноги". Потому что дешевый серпентарий кодеров на питон и nodejs и дешевле, и легче заменяется если неправильно кланяются.
Если быть прям точным 160 человек перловиков. И кроме Перл они больше ни на чем больше не умеют.
Букинг на руби по большей части.
> здесь тебе денег не обломится.Не говори за всех. Я, например, заказчик и мне он интересен как кандидат на удаленную разработку.
Если сломаются однострочники, то это будет не баг, а фича.
парсер JSON там есть/будет? Сразу бы альтернативу осушающему скрипту на Перле 7 написали - взлетел бы.
https://letsencrypt.org/docs/client-options/#clients-perl
> Путаница у новичков из-за неработоспособности в Perl 7Новичков в Perl? Это такая шутка?
> Perl активно используется не только для написания больших скриптов, но и для создания однострочников и коротких сценариев
Как раз в основном для однострочников и используется. В древности и большие скрипты делали, но сейчас в здравом уме никто не будет писать.
> У дистрибутивов возникает проблема одновременной поставки исполняемых файлов для запуска скиптов Perl 7 и Perl 5 (ожидается повторение истории с Python 2 и 3).
Из большинства дистрибутивов уже выпилили.
Я научился перлу в 2013 году. На 5.18 - 5.20 учился. В то время перл особенно активно хоронили, лол.
Все написанное тобой - расхожие стереотипы. Мы скорее увидим, как питон закопают по причине полной непригодности для реального продакшена, чем перл откуда-то выпилят.
А как же тогда Python широко используется в _реальном_ продакшене, ежели он полностью не пригоден?
Писатели на Перл живут в своем манямирке. Это примерно как писатели на Коболе медленно переходили в маразм.
>Писатели на Перл живут в своем манямирке.Это как правило люди с ~15-20-летним опытом, принципалы, и пишут на 5-6 языках как минимум.
Ты еще хочешь что-то мяукнуть? =)
В своем уме никто не будет в продакшне писать на питоне. Казуалам и учöным делат обертки-интерфейсы для взаимодействия с библиотеками написанными на статически типизированных языках.
И разве это плохо? Обёртки-то выходят не менее эфективными.
> Казуалам и учöным делат обертки-интерфейсы для взаимодействия с библиотеками написанными на статически типизированных языкахНо на перле обертки никто делать не будет.
Значит ли это, что к любой библиотеке на питон, для статистики, например, или маш. Обучения, можно найти соответствующую на другом языке?
А в том и суть, что перл выпилят разве что вместе с питоном. Не уверен насчёт никогда, но точно не скоро
Ну, сторого говоря, это не "продакшен", а какой-то временный хайп для смузихлёбов.
То, что кто-то взял "простой" Пестон и напестонил каких-то вызовов к Сишечке, не делает сам пестон "продакшен языком". Язык на отступах - он вообще полный маразм для 21 века.
Популярность Perl падает последние 15 лет. Раньше постоянно на скрипты .pl натыкался при инсталяции чего-либо.
А так он конечно проживет еще много лет продолжая терять популярность, вон Delphi же жив до сих пор
Да.
Теперь вместо этого скрипты на питоне.
Не работает? Это потому что ему нужен Другой Питон!
При Столлмане такого не было.
Всё правильно этот Дэн Бук сказал. Доводы (они хоть есть!) гораздо разумнее чем объявлялось в предыдущей новости о Perl7
Предлагаю рассмотреть "как это было" с "C" и "C++"В начале C++ умел компилировать программы на C - кто хотел писать "в стиле C" - мог это делать но уже например более фривольно - объявлять переменные не в начале функции а ближе к месту использования (шикарная особенность для человека и кончено источник проблем, но достоинства этой фичи - ПЕРЕКРЫВАЮТ).
C++11 это ДРУГОЙ язык (несовместимости есть, но они редки и экзотичны на StackOverflow есть занятные темы), но КТО ХОЧЕТ\МОЖЕТ\РАЗРЕШЕНО сможет по прежнему программировать с стиле "старого C++", но иногда всё же юзая например "auto" и таким образом ПОСТЕПЕННО переползая в НОВЫЙ МИР. А не то как сделали с этим Raku - просто всех швырнули, а народ судя по всему не хочет.
С готовыми библиотеками в этих языках - тоже разное всякое интересное, но в целом ОТБРАСЫВАТЬ и заставлять переписывать было нельзя - ибо потеряете пользователей т.е. разработчников. Developers Matter :-)
1) Уже стандарт C99 позволяет декларировать переменные не только вначале, но и внутри блоков/функций [1]
2) Легаси в C++ сначало популяризировало С++ ("Это Си с классами!"), а затем сыграло с языком злую шутку. Есть целая книга[2], где обсуждаются не явные(!) конвекции, отхождение от которых ломает код.
[1] https://stackoverflow.com/questions/288441/variable-declarat...
[2] Scott Meyers, Effective C++
*конвенции
> в ветке Perl 7 намереваются включить по умолчанию режим строгой проверки "strict", активировать "use warnings"Очередные последствия обвала порога входа в отрасль.
Тупые не хотят напрягать свой мозг. Они хотят заботливую твёрдую руку и заповеди свыше. (кхе-кхе, пистонята)
Для односточников strict излишен, но ведь можно отключать по умолчанию в однострочниках -- не думаю, что это проблема такая уж. Не совсем понятен синтаксис в "режимами совместимости" потому, как есть уже "v5.blah" с 18, если правильно помнится, который пытается эмулировать поведение.
Принудительное отключение старых и "depricated" возможностей сейчас -- плохо. Затягивание с отключением и десятки лет носить их, как это сейчас -- тоже плохо. Объявить устаревшей и через релиз отключить? легаси.
походу смузисты добрались и до Perl'a
Погоди, ещё не добрались до запрещённых слов.
Забить на Perl 7 и начать пилить уже Perl 8 с полной обратной совместимостью с 5
Perl 8 получится Metro-Perl и с производительностью так себе. Поэтому быстренько потребуется новая версия... Стоп, 9-е версии принято пропускать. Ага, и тут выйдет Perl X ! :)
Perl 10 с Perl 5 Subsystem for Perl 10.
Вы несколько остали от жизни: https://www.opennet.me/openforum/vsluhforumID3/121044.html#187
Ну, хоть движуха началась.
Как то все печально с перлом
Пора хоронить
Давно пора.
Perl пережил уже не одно поколение своих могильщиков.
Тем не менее (как бывший перлист) хочу сказать, что желания на нём писать всё меньше и меньше.Тот же C# в виде .NET Core уже появился на Линуксах. Куда более приятная и мощная альтернатива.
> C#Я не знаю что ты, но точно не бывший перлист.
Кстати где про то что Перл 5 идеален и новые версии ему не нужны?
Perl5 идеален и новые версии ему не нужны!
Новые языки программирования, нужны для того, чтобы переписывать на них старые программы и выбивать на это бюджеты. Таков закон экономики ....
> приведёт к неработоспособности в Perl 7 большого числа модулейПрикол в том, что новые поколения в силу своего хипстерства и веб-макакства просто физически не в состоянии поддерживать действительно полезные для продакшена библиотеке.
Тут речь как бы о предыдущих поколениях, нспособных поддерживать библиотеки в силу примерно тех же качеств, только называемых другими словами.
Ну хоть кто-то заботится об обратной совместимости, а не как в vapoursynth.
>[quote]Возникает риск выгорания и ухода активных разработчиков интерпретатора Perl, модулей, инструментариев и сопровождающих пакетов из-за возникновения большой дополнительной нагрузки без должной мотивации (не все согласны с необходимостью создания Perl 7). [/quote]С отфильтровыванием ненужных для v5 версий модулей с CPAN ещё как-то надо решить.
Если не ошибаюсь, то есть некоторые проблемы, если пытаться установить модули для какой-либо более старой версии, чем возраст уже обновлённой кучи модулей.В мета можно указать минимальную версию модуля зависимости, но не максимальную... или ошибаюсь?
заходил в IRC-чат чем-то интересоваться насчёт cpan,
очень удивил коммент, типа "Неужели кто-то ещё этим пользуется" :)
Похоже что пришло время форкать всю экосистему и perl. Эти "разработчики" наразрабатывают что все сломается. Bump-версии - это чистое нубство, а нубам я не доверяю - они обычно бестолочи.
>Путаница у новичков из-за неработоспособности в Perl 7 некоторых примеров и рекомендаций из руководств, написанных для Perl 5.новички неспособные отличить нормальные примеры от васянских могут сразу пройти в JS
>Не изучено влияние на разработку однострочников.
обалдеть. оно серьёзно?
>У дистрибутивов возникает проблема
это что-то новое? у них всегда возникает. покуда не будет единого дистра. а пока нехай пердоляцца
>Фундаментально поменяется культура в сообществе и отношение к стабильности Perl.
шта? разве что к лучшему.
>Будет подорван авторитет языка из-за критики о нарушении совместимости
этот чувак похоже засланный казачок говноскрипта, сколько бы модулей он не поддерживал
5 лет проработал с Catalyst'om, ушел из-за бардака с пакетами. Запустить каталист на линухах стало большим приключением. Как по мне, так лучше вычистить CPAN от тухляка, что можно приурочить к выходу 7ки.
Как бывший перлист (сейчас C#) скажу: Перлу не нужны никакие 6, 7, 8 версии. Ему нужен порядок в библиотеках. И дать ему спокойно помирать на обочине мэйнстрима.
Перл - писать на нём забавно, но только если твой код от силы одна страница. И если ты усердно вложил время в привыкание к $#@&* (это синтаксис, если что, а не мат :) ). А так писать на "чистом" языке типа жабы или цэшарпа куда приятнее.
Поэтому Перл - ну как бы доживающий язык, т.е. за ним ещё стоит какое-то комьюнити, но он уже явно бесперспективный язык.
Как человек который закончил писать на С++ и Java, скажу что писать на Perl - сплошное удовольствие. Perl дает столько степеней свободы что определяющим успех проекта является знание технологии и порядок в голове программиста, иначе вы запутаетесь нитях степеней свободы и, да, тогда порядка в библиотеках у вас не получится. В конце-концов, perl может просто сэкономить вам ОГРОМНЫЙ объем времени в разработке если вы дружите с головой. Интенсивность и итеративность разработки на perl существенно отличается от других ЯП, так как, повторюсь, степеней свободы очень много. Кому конечно как, но вместо C++ и Java я предпочитаю Perl+Си.
Если человек говорит про свободу, значит он познал Perl.
> Перл - ну как бы доживающий язык, т.е. за ним ещё стоит какое-то комьюнити, но он уже явно бесперспективный языкв качестве скриптового языка Perl, как минимум, неплох. а жаба и C# - это вообще не столько ЯПы, сколько "технологии разработки ПО, доступные широким массам". Perl - это скриптовый язык здорового человека, лучше отсеивающий макакинг-писателей, нежели пистон или какая-нибудь гошка
> Как бывший перлист (сейчас C#) скажу: Перлу не нужны никакие 6, 7, 8 версии. Ему нужен
> порядок в библиотеках.так вот и кончится теперь порядок - точнее, "новый порядок" наведут - "этот модуль с cpan несовместим с вашим перлом - немедленно обновитесь. Да нам плевать что другие используемые вами модули несовместимы с модным перлом, а автор давно уже "программист на C#" - перепишете!"
6я версия, изначально заявленная как совершенно отдельная разработка - ничего не ломала, но никем и не использовалась, как нетрудно в общем-то было предугадать. Но макаки не любят, когда ничего не ломается.
Предложенные чуваком полумеры (которые еще не факт что будут одобрены) вряд ли кого-то спасут - ведь "чистка от устаревшего синтаксиса" непременно продолжится, а ты теперь даже различить по номеру major версии, где еще не зачистили от new CGI не сможешь.> И если ты усердно вложил время в привыкание к $#@&* (это синтаксис, если что
он вообще-то a) опционален b) придуман теми и для тех, кто уже привык - пользуясь шеллом (причем, разумеется, csh преимущественно) - уникальных именно для perl внутренних переменных практически нет
Если твой код на одну страницу пол-cpan'а за собой тянет - то это уже не код на одну страницу, а просто хороший code reuse.
Ну а что-то большое и сложное, наверное, и впрямь на C# запилить проще и легче потом поддерживать - только перл-то тут причем?
И почему именно C#, а не игого какой?