После 11 месяцев разработки опубликован релиз новой стабильной ветки языка программирования Perl - 5.40. При подготовке нового выпуска было изменено около 160 тыс. строк кода (без документации и автоматически сгенерированного кода - 110 тысяч), изменения затронули 1500 файлов, в разработке приняли участие 75 разработчиков...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61343
Когда ждать перехода опеннета на новую версию перла?
На новую версию Python.
Ветка 6.х будет пропущена как проклятая...
Perl6 это Raku.
Добалю свои пять. Измененая в проекте "Perl6" было настолько значимыми, что решили создать новый язык не заботясь об обратной совместимости с Perl5.
На то оно и мажорный релиз - существенные изменения.
Просто обьявят кодовым именем и назовут perl6 потом выпустят perl7
Чью с Raku?
FOREVER 5! )))тут куча неосилянтов сейчас набегут, а как не посмотрю какой нибудь проект - там perl добавили ))))))
Это какие например проекты?
Его личные хомворлды, разве что только.
Может, они кружком пенсионеров собираются, закрывают какие-то гештальты
А новые проекты на нем создают?
Да. И не мало. Но это специфические проекты для администрирования в основном.
Например?
> Например?Вбиваете в поиске github language:Perl
Вбил, отсортировал по звездам: из 10 первых проектов 2 deprecated, 3 вообще не связаны с IT, 4 какие-то вспомогательные скрипты, 1 шуточный, 1 скриптик хоть как-то похож на администрирование, но последний апдейт в 2020. Может вы дадите пример этих специфичных новых проектов для администрирования? Хотя бы топ 3.
Что за странное желание хотеть именно *новых* проектов? Это о чём-то вообще разве говорит? Администрирование 3, 5 лет назад разве чем-то отличалось от сегодняшнего? Бред какой-то.
Например, его личные скрипты, которые не нужны примерно никому
Хотя бы мастаба munin.
Создают. Но на гитхаб не выкладывают.
Секретные проекты в ЦРУ и пентагоне, а там еще другие коллеги сразу на COBOL помогают.
Язык мертв наполовину. Новое поколение ообходит как легаси. Умрет через 20-30 лет окончательно.
>Язык мертв наполовину.Программист-археолог -- так-то профессия будущего.
>Новое поколение ообходит как легаси.
Новое поколение еще радостно самостоятельно шишки набивает, проходит по тем же граблям и в открытые двери ломится. Писать все с нуля им никто не даст, так что встреча с тем или иным легаси для них лишь вопрос времени.
>Умрет через 20-30 лет окончательно.
Ну ты-то вечно жыдь собрался вместе с "новым поколением" (тм) "И это пройдет" (с)
Помнится, был тут кто-то, написал Desktop Environment на Perl. Его просто не видно на фоне священных войн X11 vs. Wayland и нытья по поводу "каким должно быть DE" сотен экспертов. Ссылку не просите, я их в принципе не сохраняю (тем более что Perl мне не очень понятен). И тем более не стоит понимать это как неуважение к проекту или автору - таких бы человек 10, и не пришлось бы гордиться трендовыми сетами иконок и нескучными обоями.
ДА: https://github.com/trending/perl
> Добавлено новое ключевое словоПомню как перлунишки с пеной у рта доказывали, что bless - это все, что им нужно.
Эксперементальный синтаксис, как мне показалось, несколько скуднее возможностями. и высокоуровневее
К нему ещё добавлять и добавлять )) для того чтобы переманить особо искушённых.
> для того чтобы переманить особо искушённыхСильно ли нужны такие особо искушённые, которые объявляют перл коболом наших дней? :-)
Жаль, что развитие поехало, когда perl перестал использоваться.
Руководствовались принципом работает не трогай и застогнировали.
С каких это пор перестал использоваться? Используется, да ещё как. Да хотя бы в ядре Linux.
там на раст его потихоньку заменяют
никогда на раст не заменят, синтаксис перла идеален по сравнению с растом
Дашь ссылку на твои проекты на перле? А то в прошлый раз ты слился аккурат на этом вопросе)
А никто не слился, просто твою борзость игнорировали.
Ты уже неоднократно пытаешься нарушить закон о защите персональных данных, выуживая чужую информацию, которую тебе никто показывать не обязан.Сам Столлман не стал делиться своим emacs-конфигом, сославшись на персональные данные. А ты хочешь целый проект. Ты бы ещё у Столлмана попросил первую версию Emacs, которую он мошенническим способом заполучил от Гослинга.
Представляю, как бы он тебя послал.
На перле есть целый линукс дистр!! Но за тебя я его гуглить не буду - развивайся, лентяй!
Прямиком из 2005 года, да: https://sourceforge.net/p/perllinux/code/ci/master/tree/В бьюзибоксе утилит больше, чем там.
>синтаксис перла идеален по сравнению с растомОт '$' в глазах не рябит?
Ты точно видел синтаксис rust :-)?
кобол нашего времени.
Так ли много перла используется на практике? Он был минимально популярен в 90-е и с тех пор использовался исключительно теми, кому лень баш освоить.
Напротив, это на баше писали те, кому было лень освоить перл. А писать на баше -- это боль и содомия.
Баг всегда считался write only языком 😁
Кому не хватает Баша, те добавляют Петончека.
> Кому не хватает Баша, те добавляют Петончека.Это сейчас петухончег, а раньше была перловка.
Прировнять Perl к Bash... Ммм... У тебя винегрет в голове.
Мысли формулирует плохо, но идея верная. В применениях для автоматизации чего-нибудь почти всегда есть возможность написать шелл скрипт. Делать это обычно есть смысл, и вот почему. Перл чаще всего приходится устанавливать. Перловые зависимости нужно устанавливать, они обычно компилируемые. Все это добавляет еще один этап - установку перла и зависимостей проги на перле. Который в разных осях будет немножечко разным. Мучаться с этим ради чего? Чтобы на перле пописать?
Я обожаю перл, но в таких случаях всегда пишу шелл скрипты. Фактически, я всегда их пишу. На перле только сложные утилиты или демоны, что бывает раз в 200 лет примерно. Для демонов в наше время голанг. Для утилит выбор языка часто определяют библиотеки и решаемая проблема. Перл далеко не всегда подходит. Еще раз, я обожаю перл, это мой любимый язык. Но я не пишу на нем все, как это любят делать дети, умеющие только на одном языке.
Есть такая штука называется вендоринг. Это когда зависимости идут с прогой как часть программы и ниоткуда не скачиваются. Это секретная техника никому про неё не рассказывай.
PP зависимости конечно легко можно подложить в папочку. Но перл без XS - как водка без пива.
Особой разницы нет, ставишь ты зависимости через cpan i (и они скачиваются) или они у тебя уже в папочке и ты делаешь там perl Makefile && make && make install? Ты компилишь и куда-то ставишь модули. Можешь их опакетить заранее. Но всем этим надо заниматься. С шелл скриптами все гораздо проще.
Модули Перла могут быть на БЫСТРОЙ сишечке, давая "типа скриптовому" Перлу мощь железа. А просто "шелл" так и останется навозной мухой - никаких расширений там не будет, пока не напишут и не всунут в ядро.
> Перл чаще всего приходится устанавливатьГде? ниодного дистра не видел чтобы там не было перла из каробки.
> В применениях для автоматизации чего-нибудь почти всегда есть возможность написать шелл скрипт
Писать конечно разное можно, но shell из каробки, монтирует образы, создает netns маршруты навешивает...вот на днях для голанга гуглил либу для монтирования, есть, но не работает пока ковырял выяснил что это просто обвязка к стандартной утилитке, забил написал свою
и зачем голанг или перл если они один черт используют стандартные тузлы
> Где? ниодного дистра не видел чтобы там не было перла из каробкиУ наших перл во времена моей молодости вроде был прямо в коробке.
А потом лет 10 назад его из коробки выкинули и теперь он устанавливается в систему дополнительно.
Ну я его руками сам в систему всё-равно не устанавливаю, т.к. я устанавливаю Midnight commander, а ему для работы зачем-то нужен perl и поэтому миднай затягивает мне перла в систему сам без моих каких-то отдельных усилий. :-)
> В применениях для автоматизации чего-нибудь почти всегда есть возможность написать шелл скрипт.Если под автоматизацией понимать последовательный вызов утилит с несложной тасовкой параметров - да. Но если логика чуть сложнее, баш с костылями на месте массивов и хешей сразу теряет очки. Правда, для таких задач подходит уже не только перл и всё упирается в знания/предпочтения.
Ну ты балбес конечно :-D. На perl'е пишутся программы побольше и посложнее нежели на bash. На bash подобное это боль. Говорю это как человек, который периодически делает достаточно ёмкие программы на bash.
Неа, не пишутся. Да и какие, например? Писать "программы" на языке обработки текстов это уже диагноз. А с обработкой текстов баш получше справляется. Речь именно о том, как этот язык используется на практике.
> Неа, не пишутся.Ну тебе, конечно, виднее :-).
> Да и какие, например? Писать "программы" на языке обработки
> текстов это уже диагноз.Во-первых, perl давно не ЯП для обработки текстов. На данный момент он не более для обработки текстов, чем любой другой скриптовый ЯП. Во-вторых, ну допустим код серверной части web-приложения - вот тебе обработка текста. Весь http это обработка текста, xml, json и т.д.
> А с обработкой текстов баш получше справляется.
Нет. Не лучше. В том-то и дело.
> Речь именно о том, как этот язык используется на практике.
Так и я о том же. Тебе-то это откуда знать :-)?
А ты откуда пишешь, из болота какого-нибудь битрикса? Жуткое легаси и технический долг, смотри на вещи трезво.
> смотри на вещи трезво.Хорошая мысль. Для Bash есть аналог doxygen?
Не согласен. Кобол - узкоспециализированный многословный язык для финансовых приложений. Perl это даже его противоположность.
Общее у них то, что оба живут в своих нишах и не собираются умирать. В отличии от всяких Ruby (скоро и Rust с Go). Которые хайпанули и ушли в небытие.
Rust с Go никуда не уйдут. Они тоже нашли свои ниши.
Даже Ruby, к сожалению. Хотя если гитлаб однажды перепишут, количество Ruby-кода на серверах серьёзно упадёт.
Кобол - это язык для манагеров, а Perl - язык для хакеров
>Кобол - узкоспециализированный многословный язык для финансовых приложений. Perl это даже его противоположность.Perl - Practical Extraction and Report Language («практический язык для извлечения данных и составления отчётов»).
Если бы мне нужен был скриптовый язык, я бы выбрал именно перл. Не баш и не питон. Перл. Почему? Потому что я его знаю лет 20 как 🤗
Опеннет тоже сделали на перле потому что автор сайта ничего другого не знал. Да и моды на пхп тогда особо не было.
Сомневаюсь, что автор сайта опеннета не мог сделать его на php; но если бы он сделал его на php - то вынужден был бы регулярно переписывать с выходном очередной версии, что, имхо, просто бредово. А софт на perl'е работает десятилетиями, не требуя регуляоных правов из-за очередной блажи разработчиков языка.
Мог но не знал. Пхп переписывать это только если готовую cms взял с комплектными отверстиями.
> Опеннет тоже сделали на перле потому
> что автор сайта ничего другого не знал.
> Да и моды на пхп тогда особо не было.Дело ж не в моде на ПХП, который тогда, кстати, существовал уж.
Я вот когда в последние пару лет в университете учился, у меня нигде не было веб-сервера, на котором можно было бы серверную часть сайта ваять.
И вот как-то раз я узрел, что на сервере chat ru можно ваять на ПХП.
Ну ПХП, подумал тогда я, не Перл, конечно, на котором тогда было принято программировать серверную часть сайта, но деваться-то некуда - дают только ПХП.
Ну раз дают только ПХП, пришлось поюзать ПХП. Временно. Нашукал документацию на этот ПХП и пострадал пару лет на нём.
А потом после университета устроился на узел интернет-провайдар сисадмином и там уж хоть ПХП, хоть Перл, хоть где ни скажу. Ну соответственно тогда я от вынужденного на пару лет страдательства программирования на ПХП таки избавился и больше никогда на нём не программировал, ибо зачем, если доступ к перлу есть уж. :-)
Да и сам ПХП-то расшифровывается-то как: perl home page.
Ну типа перл для домашних страничек. Ну типа кому-то наверно нравится серверные программы втыкать прямо внутрь html, который вообще-то предназначен не для серверной работы, а для браузерной, клиентской. :-)
Personal home page = PHP. Мда.PHP до 4-й версии во всём проигрывал Perl. Да и 4-я версия во многом была кривая
Аналогично) Perl 5 отличнейший язык! С помощью него вы всегда решите поставленную задачу, выполните свою работу. Программы выглядят не слишком изящно? Ну и что, это не главное!
Программы выглядят так, что непонятно, валидный ли это код на Перле или битая файловая система.
Перлу и не надо быть понятным ДИЛЕТАНТАМ, для этого есть "язык черепашки" :)) А профи читают Перл не сложнее лиспа. Вопрос практики (и подсветки).
>Ну и что, это не главное!Нет, друже, это, как раз, для программиста-человека главное. Ну разве, что для программиста-ИИ не главное.
> Если бы мне нужен был скриптовый язык,
> я бы выбрал именно перл.
> Не баш и не питон. Перл.
> Почему? Потому что я его знаю лет 20 как 🤗Аналогично, коллега!
Я начальные понятие программирования на перле получил в конце 90-х годов (т.е. тоже более 20 лет назад уж) из "Введения в Перл" Владимира Маслова и с тех пор не унываю!
Удивительно, но на Перле можно сваять почти все Линуксовые утилиты! (есть даже такой дистр) Это если не хочется канаёпицца с Си и его играми в память.
> если не будет принято решение перейти к нумерации 7.xА чё - эта идея до сих пор витает?
Я думал, что про неё все давно забыли уж.
Давно ж не было новостей по теме этой идеи.
Я думал, что несколько лет эта идея повитала-повитала, да заглохла.
> вместо не очевидных манипуляций с "eval"Ну зато в неочевидный eval можно ж затолкать такие несусветные неочевидности, как:
1. myy $a = 1 (вместо my $a = 1)
ну или более интересный вариант
2. несоответствие скобок:
if ($a == $b ) { say "и ага!" }}А если попытаться затолкать несоответствие скобок в "очевидный" try, то в отличии от варианта "неочевидного" eval наверно не выполнится вся программа:
try {Ошибочная скобка в конце строки if будет означать закрытие блока try, после чего в основной программе появится неожиданная закрывающая скобка }, которую "неочевидный" eval скушал бы молча, а в варианте "очевидного" try не запустится вся программа. Вот и вся очевидность-неочевидность. :-)
if ($a == $b ) { say "и ага!" }}
}
>1. myy $a = 1 (вместо my $a = 1)```
use v5.38;
eval {
myy $a = 1;
}
```
Scalar found where operator expected (Do you need to predeclare "myy"?) at t.pl line 4, near "myy $a"
syntax error at t.pl line 4, near "myy $a "
t.pl had compilation errors.>2. несоответствие скобок: if ($a == $b ) { say "и ага!" }}
```
use v5.38;
eval {
if ($a == $b ) { say "и ага!" }}
}
```
Unmatched right curly bracket at t.pl line 5, at end of line
syntax error at t.pl line 5, near "}"
t.pl had compilation errors.Так что ничего eval молча не кушает.
> В настоящее время в модуле предложены функции
> true, false, weaken, unweaken, is_weak,
> blessed, refaddr, reftype, ceil, floor,
> is_tainted, trim и indexedА чё эти функции делают?
функционируют
> Логическое выражение "$x ^^ $y" вернёт TRUE,
> когда либо "x", либо "y" имеют значение TRUE,
> но не одновременноНу понятно, что это исключающее или.
Но зачем для этого ещё один оператор, если для этой логической операции оператор xor существует уж?
Для всяких скриптов самое то. Удобно. Большие проекты - точно нет. Производительность на уровне Питона, т.е. в сотни раз медленнее С++, к сожалению.
Смотря как писать. Если вы будете на перле писать как на плюсах, классы изображать, типы на коленке лепить - будет очень медленно. Если перл ничего тяжелого не делает, ресурсоемкие вещи в XS, все это может работать вполне быстро. Perlbal в качестве примера.>Производительность на уровне Питона
Примерно в два раза быстрее :) А еще в питоне GIL и GC, то есть он в принципе не годен, а перл можно приспособить. Не надо их даже сравнивать.
Как угодно можно писать. Всё равно в сотни раз медленнее. Делал как-то проект. Думал побыстрому сейчас на любимом Перле всё сделаю. Но всё упёрлось в производительность. По факту пришлось всё переделать на С++ с ассемблером. Получилась производительность в 500-1000 раз лучше, чем на Перл. Исследования показали, что абсолютно любая простейшая операция (сложение, вычитание и т.д.) на Перле выполняется ооочень медленно. Так что для каких-то утилит - да (сам иногда для этого использую Перл), но для обработки больших объёмов данных - точно нет, просто без шансов, для этого выбирайте С++ в связке с ассемблером, тогда будет вам производительность.
>С++ в связке с ассемблеромСпасибо, я лучше возьму голанг какой-нибудь. Из скриптовых на производительность можно брать luajit, но программировать надо аккуратно, без лишнего кода. Производительность в разы может отличаться в зависимости от реализации, при том же самом алгоритме.
>простейшая операция (сложение, вычитание и т.д.) на Перле выполняется ооочень медленно
Небось пишешь на перле как на плюсцах, вот и получается в 500 раз медленнее.
>я лучше возьму голанг какой-нибудь. Из скриптовых на производительность можно брать luajit, но программировать надо аккуратно...Возьми, но производительность будет существенно хуже. Lua будет раз в 10 медленнее Си.
Если нужна именно производительность, то нужно брать лучшие в этом инструменты, а именно парочка компиляторов С/C++: GCC и Clang.Если производительность не нужна, то используй то, что знаешь.
>>простейшая операция (сложение, вычитание и т.д.) на Перле выполняется ооочень медленно
>Небось пишешь на перле как на плюсцах, вот и получается в 500 раз медленнее.На Перле я пишу, как на Перле. Лучше давай-ка ты проведёшь сравнительные тесты Си и Perl и выложишь здесь результаты. Тогда и поговорим.
Процедура перемножения матриц написанная инженерами Интел на ассемблере с учётом архитектурных особенностей всего в 8 раз быстрее чем на с++ так что никаких lua, нужно брать готовое.
perl - для админских однострочников, или полэкрана. не заменим.
>однострочниковПривет из 2к24! Как там в 1998?
Сначала тебе нужно будет поставить этот твой Perl в систему, рядом с Python, который уже везде есть.Опять же, зачем тебе нужны эти костыли, когда есть божественный Ансибл.
Перл скрипты до сих в ходу.
Там, где их тридцать лет назад написали, а в инфраструктуре до сих пор торчит что-то перлоспецифичное, типа багзиллы. Во всех остальных случаях связываться с перлом нет никакого смысла. Зачем тащить ещё один язык в инфраструктуру, если можно не тащить.
>божественный АнсиблНастолько уродливый хлам, что cat setup.sh | ssh host bash начинает казаться хорошей вещью.
Самописные скрипты ты ещё полгода отлаживать будешь, чтобы у тебя хотя бы на паре десятков машин всё воспроизводилось. А лет через двадцать, может, и накостыляешь что-то отдалённо похожее на Ансибл. Только зачем этот мартышкин труд?
Это, конечно, сильно преувеличенная оценка. За несколько месяцев вполне можно написать свой аналог Ансибла, не прибегая к дополнительному синтаксису Ансибла (jinja, yaml, json и прочие поделки). Разумеется, он не будет настолько же универсален, но часто это и не требуется.
>божественный АнсиблТолько для очень простых, типовых случаев он божественен. Для чего-то узко-специализированного - скорее, убожество редкое.
Для чего-то узкоспециализированного пишется программа.Ансибл расширяемый, и если чего-то не хватает, ты всегда можешь написать модуль или фильтр. Использовать его как язык программирования, само собой, не нужно.
А уж там, где используют перловые скрипты, Ансибла более чем хватит.
Вообще-то я хотел сказать, что часто (не всегда) без Ансибла прекрасно можно обойтись, не внося в инфраструктуру лишние сущности.
не заменим, но почему-то много где заменяется удобном случае
Не только. Что мешает создать на Перле почтовик? (и сервер, и клиент) Практически всё есть. А имея регэкспы, можно парсить тонны разных данных вообще во все поля.
Потому что ворочаться этот твой почтовик будет как тюлень. Даже когда перл был популярен, это никому не было нужно.Регэкспы перловые давным-давно уже везде есть, а на одних только регекспах ты далеко не уедешь. Больше нет необходимости постоянно парсить текстовые файлы, JSON уже почти двадцать лет как придумали.
Перл, конечно, лучше баша, так как что угодно лучше баша. Но он хуже чего угодно другого.
>JSON уже почти двадцать лет как придумалиJSON настолько хорош, что придумали JSON-LD
JSON достаточно хорош, чтобы не хотелось XML. Или парсить плейнтекст регекспами, да.
Python справляется гораздо лучше во многих случаях (речь не про однострочники, конечно же).
Стоит ли учить Перл в 2024?
Ну что бы стать тру программером
Ни в коем случае.
Учить надо Баш и Питон, что бы писать операционные системы и ИИ. Пёрл учить вообще не надо: тру программеры его знают сразу, а не тру, кто знает хотя бы Си, и так сможет написать что-то простое.
> Учить надо Баш и Питон, что бы писать операционные системы и ИИНа баше и питоне, серьёзно?
Я вообще не уверен, что в баш сейчас даже сисадмин должен углубляться. Всё, что чуть сложнее простенького цикла, в итоге оказывается быстрее написать на питоне, который есть везде. Логика скриптов хреново расширяется, скрипты хреново отлаживаются. Даже если нужно сохранить какие-нибудь значения в переменную и использовать их списком, проверить состояние списка, объединить с другим списком, это уже начинает выходить за рамки тривиальной задачи.
Кроме того, чтобы написать точку входа для контейнера в несколько строчек, я не знаю зачем ещё использовать баш. И даже для этого лучше не использовать, если есть возможность.
>> Учить надо Баш и Питон, что бы писать операционные системы и ИИ
> На баше и питоне, серьёзно?По мнению некоторых местных майнтайнеров (в частности, здешний регистрант Survolog), они занимаются разработкой полностью автономной операционной системы, на языке Баш.
Вот в чём дело, ясно. Ну, тут выше уже предлагали дистрибутив линукса с базовыми утилитами на перле. Каждый развлекается как может.
Perl или Python (или их диалект) вместо Bash в командной строке имели бы смысл, как по мне. На bash пишут не базовые утилиты, а сборочные сценарии пакетов, называя это "разрабатываем ОС".
тебе оттуда разве что PCRE будет надо
Смотря как учить и что ты уже умеешь. На примитивном уровне на перле можно сразу начать писать как на JS или PHP. Из перла при желании можно вылепить любой язык, на котором ты уже программируешь. Обычно люди это принимают за освоение перла или даже за преодоление его "недостатков", но в реальности это потеря времени.Перл надо учить не первым языком, уже имея большой стаж программирования и знания, глубокое понимание концепций программирования. Еще на перле надо постоянно программировать, чтобы развиваться. У перла много мелких особенностей и приемчиков, которые забываешь, когда долго не используешь язык.
> У перла много мелких особенностей и приемчиковИменно это и делает его ужасным. Заглянув в скрипт, который ты написал полгода назад, ты уже не сможешь вспомнить почему ты здесь сделал так, а не иначе. Что уж говорить про чужие скрипты. Читаемость просто отвратительная.
Перл хорош уже тем, что он портабельный и мощный. Я б его точно учил - люди на нём целые сайты ваяют - почему нет? Много высокоуровневых конструкций, поэтому когда пишешь код, СИЛЬНО сокращаешь топтание по клаве.
ООП в Перле вообще крутизна - даже мощнее, чем в C# (можно даже сказать, что это Смоллток).
> люди на нём целые сайты ваяютЛюди на нём тридцать лет назад сайты ваяли, потому что у них ничего другого не было. С тех пор для ваяния сайтов много чего другого понаписали. Даже с джангой ты и управишься сильно быстрее, и работать это будет надёжнее, и запускать на вебсервере сможешь без особых танцев. И OOP/MVC у тебя будет из коробки.
Писать-то писали. Но PHP изначально был фреймворком для Perl. Так что насколько он удобен был
Я свой дипломный проект написал на Perl'е. Правда, это было давно. Но в работе c Perl'ом ни разу не сталкивался.
Да, стоит
Нет, не стоит. Python для скриптов намного приятнее. А более ни для чего в наши дни Perl не нужен.
Не надо Питон. Это не язык, а недоразумение!
Тем не менее, он а) есть везде из коробки; б) удобен для написания скриптов; в) востребован на рынке.Лет через дцать, возможно, что-то более удачное подкинут, если к тому времени всю скриптуху ещё не будут писать нейросетки.
Типа Perl лучше? ИМХО, ужас ужасный. Write-only.
> Стоит ли учить Перл в 2024?Сама рабская постановка вопроса на постсоветском пространстве меня убивает! Программирование ради программирования, а не результата. Вот поэтому и мало открытого кода.
p.s. лучше выложи на gitflic что ты умеешь делать, чем ставить себя в позу этим вопросом
p.s.s. всем известно что личное время очень ограничено и адекватный человек поймет что мегапродукта не стоит ожидать. Если есть законченный программный продукт, то он больше расскажет о человеке чем у недосиньйоров без таких продуктов. Даже если там будет ужасный код. Вот на собеседовании и можно обсудить в выделенное время на собеседование о парном программировании касательно улучшения кода, если придираться к навыкам. А для всего остального (так называемого технического собеседования) есть образование. Почему у работодателя нет доверия к ним? Потому что нет обратной связи и из-за коррупции. Почему покупка диплома обесценивает образование? Это уже к юристам, особенно тем кто ближе к управлению. Все эти вопросы из-за сложившихся процессов не нормальны и не здоровы!
У Perl очень высокий порог входа, это своеобразная зарядка для ума, послушайте неасиляторов, они правду говорят, не связывайтесь ...
> * Расширены возможности, связанные с появившемся в прошлой версии экспериментальным синтаксисом для создания классов.
> * Объявлен стабильным синтаксис обработки исключений try/catch
> * Стабилизирован синтаксис "for my (VAR, VAR) (LIST)" и "foreach my (VAR, VAR) (LIST)
> * Объявлен стабильным модуль builtinВ питоне все это мульон лет как есть.
Это в вашем питончике если чего-то нет, то вообще нет, и вы ждете, пока завезут. В перле всё было всегда. Если ты не знаешь, как поймать ошибку из eval, или как массивчик в переменые внутри цикла раскидать - это не проблемы перла.
Конструкция eval { ... } ; if ($@) { ... } гораздо лучше отражает логику программы и не создает вредных иллюзий. Дело в том, что никаких настоящих исключений в перле как не было, так и нет. И try catch только вводит в заблуждение. Это же тупо сахар вокруг $@. Непонятно, для кого это вообще, чтобы что. Позорище.
> Конструкция eval { ... } ; if ($@) { ... } гораздо
> лучше отражает логику программы и не создает вредных иллюзий. Дело в
> том, что никаких настоящих исключений в перле как не было, так
> и нет. И try catch только вводит в заблуждение. Это же
> тупо сахар вокруг $@. Непонятно, для кого это вообще, чтобы что.
> Позорище.В eval, кстати, сейчас только об этом подумал, есть ещё одно преимущество перед try.
Программу для eval можно затолкать в строковую переменную, которую потом можно подставить аргументом в eval:
$operator = '$a = 1';
eval $operator
print "$a\n";А в try не затолкаешь же строковую переменную с программой, которую надо выполнить. В try надо наталкивать непосредственно только сами операторы.
Не будет же работать так:
$operator = '$a = 1';
try { $operator }
(ну т.е. ошибки-то вообще-то тут не будет, но смысл будет другой - не присвоение единицы переменной $a, а просто бесполезный безошибочный оператор - вставка переменной в позицию)Для try надо писать только явно:
try { $a = 1 }П.С.
А тут для отправки сообщения код просят ввести почему?
Вообще не понятно. Тут в сообщении нет вообще ни одного выражения, похожего на урл.
Ты даже не понимаешь, как устроен эвал в перле.
>надо наталкиватьНадо прочитать книжки с ламой, хотя бы.
>это не проблемы перлаВообще-то, если какие-то конструкции языка не являются очевидными - это, как раз, проблема именно этого языка. Тут уже кто-то написал, что в Перл слишком много всяких неочевидных вещей, которые очень быстро забываются, если на Перл долго не программируешь. Что ж тут хорошего, если тебе постоянно надо держать в голове этот хлам вместо того, чтобы сосредотачиваться на коде? Это был риторический вопрос.
Ну так исправь perl и напиши его сообществу об этих недостатках, ну и посмотрим чья это проблема.
Разработчики выпилили оператор goto ... похоже они свернули не туда ...
Still alive!
Perl - лучший! Был хорош, а стал вообще бомба. Вот те, кто по подростковой дypu ненавидит микрософт, можете смело брать Перл (всяко лучше жабы, жабоскрипта и похапэх) и ваять ЛЮБЫЕ приложения - хоть гуйню, хоть вебы.
Отвратительный язык с вырвиглазным синтаксисом. Write-only, как раньше шутили.
> Perl - лучший! Был хорош, а стал вообще бомба. Вот те, кто
> по подростковой дypu ненавидит микрософт, можете смело брать Перл (всяко лучше
> жабы, жабоскрипта и похапэх) и ваять ЛЮБЫЕ приложения - хоть гуйню,
> хоть вебы.s/Perl/Lisp/
Штош, очень даже ничё так. Консервативно и нужно
Perl это панковский язык.
И хейтят его конформисты.