Когда-то на нем было написано множество системных скриптов в UNIX/Linux, а сейчас он ИМХО незаслуженно позабыт, и новое поколение программистов даже считает его «плохочитаемым», отдавая предпочтение более модным и современным языкам с синтаксисом еще более древнего PL/1
Хотя как он может быть непонятным и плохочитаемым, если типовая «первая программа Hello world!» выглядит буквально так:
print "Hello, world!";Поскольку perl изначально все-таки для UNIX, то и программы для него, как правило, в типичном стиле для shell-скриптов начинаются со строчки запуска интерпретатора:
#!/usr/bin/perl
print "Hello, world!";Для пришельцев из windows-мира, которые до сих пор не знают зачем это нужно - это позволяет просто обозначить файл как исполняемый и запускать его, как любую другую программу, не указывая дополнительно чем и как его интерпретировать - это как раз и написано в первой строчке.
В языке есть переменные, которые начинаются со знака $, точно так же как в sh, bash или PHP, например. Это на самом деле довольно удобно, сразу понимаешь, где переменная.
my $a = 2;
my $b = 3;
my $c = $a * $b;
print "$c\n";Ключевое слово my обьявляет переменную в рамках области видимости. В данном случае область видимости - весь скрипт с момента обьявления переменной, но если ограничить ее скобками { ... } - то видимость тоже будет ограничена.
# комментарий
my $a = 1;
{
my $a = 8;
print "$a\n"; # результат 8
}
print "$a\n"; # результат 1Всякие циклы как в С:
for( my $i = 0 ; $i < 10 ; $i++ ){
print "$i ";
}
# "0 1 2 3 4 5 6 7 8 9 "Есть дополнительные штуки типа foreach и elsif:
my @array = [0,1,2,3,23,44,23,23453,5];
foreach my $item (@array){
if ($item < 2) {
print "Less than 2\n";
}
elsif ($item < 10){
print "Less than 10 but greater than 2\n";
}
else {
print "hz...\n";
}
}(а кого бесят скобки - вспоминайте про область видимости, иногда очень удобно ограничить ее для одних, локальных переменных, при этом пользуясь другими, общими, объявленными выше)
Есть множество встроенных функций, man perlfunc, и можно писать свои:
sub my_func {
my ($arg1, $arg2, $arg3) = @_;
print "$arg1 * $arg2 = $arg3!\n";
my $x = $arg1 * $arg2;
print "На самом деле нет: $x\n";
}
my_func(32768, 100500, "Неисчислимое количество");
# "32768 * 100500 = Неисчислимое количество!"
# "На самом деле нет: 3293184000"Есть подключаемые библиотеки, которые позволяют делать почти всё что угодно, если кто-то удосужился соответствующую библиотеку написать:
use pQuery;
my $page = pQuery("http://google.com/");
my $title = $page->find('title');
print "The title is: ", $title->html;Ну и конечно, регулярные выражения:
my $a = "Мама мыла раму";
if( $a =~ /^(Мама)\s(мыла .*)$/){
my $who = $1;
my $do = $2;
$do =~ s/мы/пи/;
$do =~ s/аму/ом/;
print "$who $do\n";
}
В общем, полноценный язык программирования, на котором можно писать как простые системные скрипты, так и сложные веб-системы.
Другой вопрос, что он очень гибкий и пофигистичный, и то же самое можно написать примерно вот так:
my$a="Мама мыла раму";if($a=~/^(Мама)\s(мыла .*)$/){$a=$1;my$x=$2;$x=~s/мы/пи/;$x=~s/аму/ом/;print"$a $x\n";}и оно всё еще будет работать, но вот поддерживать потом такой "скрипт" - да легче новый язык программирования придумать!
И это мы еще не углублялись в загадочный мир встроеных переменных типа $_,@_,$!,$|,$<,...
В общем, никто за программиста не подумает, кроме самого программиста.
Но - как сейчас говорят, "он давно не развивается". Отдельные попытки где-то что-то поломать не в счет, работает он так же как и 10 лет назад, а по нынешним меркам это всё равно что умер.
Удивительно, как до сих пор не начали алфавит развивать, добавляя в него новые буквы и цифры (хотя вот смайлики добавили, да).
Комментарии (149)
Mox
09.01.2025 15:12Забыт он скорее ради Ruby и Python и возвращаться на perl совсем не хочется. Закопать стюардессу.
JBFW Автор
09.01.2025 15:12Много-много лет назад на вопрос "на чем лучше делать сайты?" Гуру ответил: на Ruby on Rails!
Прошли годы. Попадалось вживую множество сайтов на Perl CGI, на Perl не CGI, на PHP, на Java, на Python, на NodeJS, даже на .NET - но ни разу не попался на Ruby on Rails
Как-то так само получилось...Mox
09.01.2025 15:12Последний Perl CGI мне попадался в 2004, а Ruby On Rails мне попался на глаза только в 2007.
А так то дофига сайтов - github, airbnb, shopify в голову приходят
Из наших кого помню - Рокетбанк, Кухня на районе.JBFW Автор
09.01.2025 15:12Вот, и у вас тоже Perl CGI )
CGI это отдельная технология, просто в то время других скриптовых языков в общем-то и не было: sh, tcl да perl. Ну еще бинарники на C/C++.
Устарела давным-давно, хотя применение и ей найти можно. Но она - не Perl.Мне про Ruby намного раньше говорили, в общем-то расхваливали - но как-то не сложилось, а потом не надо было, и случайно уже не попадалась.
В общем верю что хорошая - но забИтая PHP-шниками, как наиболее массовым явлением.
YegorP
09.01.2025 15:12Вся заметка выглядит как тоска по самому обычному языку программирования. Так чего там особенного-то было? В цифровом мире "просто работает" и "не ломается" десятилетями что угодно кроме железа и YY вместо YYYY.
Удивительно, как до сих пор не начали алфавит развивать
На русскомъ ли языкѣ заикаться о таковомъ?
JBFW Автор
09.01.2025 15:12Удобство. Он легкий, простой, быстрый, напоминает одновременно С и JS.
Из недостатков разве что специфическая работа с UTF8 и в некоторых случаях особенности нецелочисленной арифметики, можно получить значения типа 3.00000000000000001 вместо 3.00А алфабет текущий не менялся уже лет сто. Ну, если не считать редуцирование буквы ё, которая тем не менее пока сохраняется.
YegorP
09.01.2025 15:12Ок, погнали.
простой
Я пошёл на https://www.perl.org/get.html и сразу же мне надо знать чем Strawberry Perl отличается от ActiveState Perl. Напоминает Python 2 vs Python 3.
легкий
Я нажал Strawberry Perl и увидел следующее:
5.40.0.1 MSI (196.4 MB)
5.40.0.1 Portable zip (285.5 MB)
5.40.0.1 PDL zip (335.0 MB)Для сравнения: Node.js - 30 МБ, PHP - 30 МБ
специфическая работа с UTF8
То есть вѣковыя русскія буковки не подъхватитъ?
можно получить значения типа 3.00000000000000001 вместо 3.00
А это разве касается конкретно Perl?
JBFW Автор
09.01.2025 15:121 - это UNIX/Linux вещь, не Windows )
Под Windows есть порты разной степени проработанности, но это мягко говоря не совсем то.
Если у вас Windows - проходим мимо сразу, лучше не мучаться, там даже форков нет.2 - в "комплект" обычно входит некоторый набор библиотек, и в общем случае он может быть очень разным, от минимального, где собственно интерпретатор + утилита установки библиотек до такого, куда поназапихано всё что счел нужным запихать автор дистрибутива.
А софта там мнооого.3 - буковки русския подхватывает, но внутренняя кодировка UTF8 у него своя, и чтобы понимал он их так же как стандартные - их нужно в эту кодировку конвертировать, а потом из этой кодировки выконвертировать обратно.
Но к счастью это нужно далеко не всегда, в большинстве случаев ему пофиг что там за двухбайтицы такие, оно просто с двухбайтицами работает.4 - это недостаток. Недостаток же? Ну, неспецифический, но есть.
YegorP
09.01.2025 15:121 - 3 недостатки, а вот 4 вполне ожидаемое стандартное поведение.
0.1 + 0.2 в любом мейнстримном ЯП общего назначения выдаст 0.30000000000000004. Программистам это лучше бы знать. Вместе с ±0, NaN'ами и Inf'ами.
verls
09.01.2025 15:12#!/usr/bin/env perl use v5.34; use strict; use warnings; use Math::BigFloat; my $a = Math::BigFloat->new('0.1'); my $b = Math::BigFloat->new('0.2'); my $sum = $a + $b; say "Sum: a + b = $a + $b = $sum";Выдало:
Sum: a + b = 0.1 + 0.2 = 0.3YegorP
09.01.2025 15:12А вот это что выдаст?
if (0.1 + 0.2 == 0.3) { print "Equal\n"; } else { print "Not equal\n"; }
amironov
09.01.2025 15:12Библиотеки для работы с большими числами есть в любом языке. Некоторые языки имеют встроенную поддержку, в том же C# это будет:
var a = 0.1m; var b = 0.2m; var sum = a + b; Console.WriteLine($"Sum: a + b = {a} + {b} = {sum}"); // Sum: a + b = 0.1 + 0.2 = 0.3
verls
09.01.2025 15:12ActiveState сборка от компании, Strawberry свободная реализация
Здесь сборки образа докера до 50Мб https://www.reddit.com/r/perl/comments/sd5403/tiniest_perl_docker_image/?rdt=56900 Можно из исходников собрать то, что тебе нужно.
В Perl одна из первых и наилучших поддержек unicode.
use utf8;+binmode
fiego
09.01.2025 15:12Я нажал Strawberry Perl и увидел следующее:
5.40.0.1 MSI (196.4 MB)
5.40.0.1 Portable zip (285.5 MB)
5.40.0.1 PDL zip (335.0 MB)Там в комплекте идёт, огромный набор инструментов, чтобы максимально приблизить Windows к UNIX:
It includes perl binaries, compiler (gcc) + related tools, all the external libraries (crypto, math, graphics, xml…), all the bundled database clients and all you expect from Strawberry Perl.Что позволяет устанавливать отсутствующие модули, которые требуют компиляции своих частей при установке на машинах пользователя вручную. Такая себе претензия к дистрибуции...
YegorP
09.01.2025 15:12Речь шла про "лёгкий". Нет, не лёгкий.
kmeaw
09.01.2025 15:12Но ведь если аналогичный комплект разработки расширений положить для Node.js и Python (чтобы npm и pip могли при установке пакетов что-то дособрать), то и они сильно распухнут, особенно в случае Windows.
Если пытаться более честно сравнить, то будет вот так:
$ docker run --rm alpine:latest apk add perl ... OK: 45 MiB in 17 packages $ docker run --rm alpine:latest apk add nodejs ... OK: 66 MiB in 28 packages $ docker run --rm alpine:latest apk add python3 ... OK: 49 MiB in 32 packages
amironov
09.01.2025 15:12Удобство. Он легкий, простой, быстрый, напоминает одновременно С и JS.
Он сильно отстал от жизни: типизацию не завезли, актуальных библиотек не найти, по скорости и по памяти, думаю, он тоже в аутсайдерах. Единственное, где его сейчас возможно применить, это замена sed и awk, здесь по удобству он будет вне конкуренции.
JBFW Автор
09.01.2025 15:12Была такая священная корова - ООП: "Оооо, нам нужно ООП!"
Теперь священная корова "типизация" - "Оооо, нам нужна типизация!". Зачем она тут? )
"Актуальная библиотека" пишется руками, если своего ума хватает, либо ставится с CPAN, если не хватает. Ну это факт, реально.
Поэтому слова "актуальных библиотек не найти" говорит ровно о двух вещах:
1 - своего ума не хватает ее написать (вот мне - не хватает, например, для YOLO)
2 - других умов не нашлось, они для Python писали (о чем и речь была)По скорости и памяти - ну это домыслы )
Сравнивая системы на perl с системами на PHP подобной сложности - лично у меня _ощущение_ что PHP существенно тормозит, но разве это кому-то мешало использвать PHP?amironov
09.01.2025 15:12Зачем нужна типизация? Серьезно? Например, для того, чтобы не передавать в твою my_func строки или массивы? В лучшем случае получишь ошибку во время выполнения, а то и вообще неверный результат. В языке же со статической проверкой типов, ошибка будет еще на этапе компиляции или проверки линтером.
Поэтому слова "актуальных библиотек не найти" говорит ровно о двух вещах:
То есть сначала пишем свою реализацию, а только потом смотрим на существующие? Хороший план, надежный)
Сравнивая системы на perl с системами на PHP подобной сложности
Ну посмотри здесь, я не нашел тестов, где perl быстрее.
JBFW Автор
09.01.2025 15:12Так это как раз и удобно, что можно передавать и строки, и массивы!
Вы не знаете что нужно передавать в конкретную функцию? Или это такой новый стиль программирования, "передам что-нибудь, вдруг получится"? Или это защита от рукожопства средствами языка?
Тогда это к программистам вопросы...
CaptainFlint
09.01.2025 15:12Будучи сам заядлым перлистом, всё же не могу не отметить, что у динамической типизации есть свои минусы. Во-первых, человеки банально могут ошибаться. Во-вторых, забывать. Попробуй через три года влезть в проект и сходу понять, что там куда и как передаётся. Комментарии, конечно, помогают, но они тоже зачастую пишутся "в моменте" и могут разъяснять совсем не то, что окажется непонятным когда-то в будущем. В-третьих, есть ещё задачи по изучению и поддержке чужого кода, когда надо понять, что за фигня сидит в переменной, а инициализация этой фигни живёт за тридевять прослоек в тридесятом модуле, да ещё и делается по-разному в зависимости от сотен условных веток исполнения.
JBFW Автор
09.01.2025 15:12ну тут типичная проблема баланса: с одной стороны удобно без типов вообще, с другой стороны возможны проблемы, но если начать всё типизировать - простой и понятный код становится сложным, и там где можно было решить простую задачку "на коленке" применять его станет неудобно.
Очевидное решение - появление в этом уравнении "другого языка" - либо для сложных случаев, либо наоборот, для простых.
А чтобы и так и этак - ну, это фантастика..
Tony-Sol
09.01.2025 15:12Или это защита от рукожопства средствами языка?
Да. Это именно она и есть, потому что это самое рукожопство - оно с любой стороны может прилететь и все сломать. Как php сообщество радовалось, когда вместо подобного
function foo($var) { // $var - это массив if (!isset($var) || !is_array($var)) { thow new \Exception('!'); } ... return $result; // тут массив }Стало можно писать
function foo(array $var): array { ... return $result; }Не говоря уже про пересечения типов, хоть и давно перестал писать на php, но прямо даже просто смотреть приятно на
function squareAndAdd(float|int $bar): int|float { return $bar ** 2 + $foo; }
amironov
09.01.2025 15:12Если функция может принимать и строки, и массивы, то как раз типизация и позволяет это зафиксировать в контракте. Иначе придется лезть в реализацию, чтобы понять, что можно передать.
Вы не знаете что нужно передавать в конкретную функцию?
Вот есть функция my_func, откуда я должен узнать, что в нее можно передать?
Или это защита от рукожопства средствами языка?
Нда, завидую людям, которые никогда не ошибаются.
JBFW Автор
09.01.2025 15:12Вот есть функция my_func, откуда я должен узнать, что в нее можно передать?
vim -o my_code ~/lib/VeryOldFkn.pm
amironov
09.01.2025 15:12То есть смотреть реализацию, вместо того чтобы посмотреть на сигнатуру метода? Очень эффективная методика :)
JBFW Автор
09.01.2025 15:12Есть еще man Something, но это было очевидно...
JBFW Автор
09.01.2025 15:12Человек, который не читает маны, и сравнивает их с ЧатГПТ - вот он, держите его! )
JBFW Автор
09.01.2025 15:12man perlfunc
man Net::IO какой-нибудь
Там все описано. Люди не осиливают. Людям надо чтобы они не могли в функцию вместо ip-address число 5 передать, а то непонятно что получится...
Vedomir
09.01.2025 15:12>Вы не знаете что нужно передавать в конкретную функцию?
Когда этих функций сотни и тысячи - то да даже в своем проекте над котором работаешь один уже не знаешь. При работе в команде тем более. А когда проект чужой и функций там тысячи и надо срочно разобраться как они работают и поправить глюки - то не знаешь в кубе.
JBFW Автор
09.01.2025 15:12Отсутствие документирования, отсутствие использования автотестов, потогонка "давай-давай!" детектед.
Vedomir
09.01.2025 15:12Если вы работаете исключительно в расслабленном режиме, когда никуда не надо торопиться, всегда оплачивается создание детальной документации, никогда не приходится работать с чужим кодом написанном не в таком расслабленном режиме, все и всегда пишут автотесты я рад за вас.
Но, думаю, подавляющее большинство разработчиков работают в других условиях.
На как ни странно плюсы статической типизации даже вы этом случае никуда не исчезнут.
Можно например определить статическую типизацию как обязательные для всех автотесты встроенные в компилятор.
И как обязательную для всех документацию/комментарии встроенные в компилятор и автоматически обновляющиеся при любом изменении кода.
При создании TypeScript молодежи не знающей ничего кроме JavaScript ее нередко так и объясняли.
Tony-Sol
09.01.2025 15:12Сравнивая системы на perl с системами на PHP подобной сложности - лично у меня _ощущение_ что PHP существенно тормозит
Звучит очень неправдоподобно, учитывая, что в однопотоке - php один из самых (если не самый) быстрых скриптовых языков
JBFW Автор
09.01.2025 15:12а зачем же вы его в однопотоке используете?
Форки хотя бы, как минимум, параллельные процессы...amironov
09.01.2025 15:12А что это изменит? В каждом процессе все равно будет один поток.
JBFW Автор
09.01.2025 15:12Ну вот смотрите: была некоторая старая система на PHP, например - после переписывания ее на Perl она стала быстрее, с точки зрения юзера. Хотя переписана почти "дословно".
Это по субьективным отзывам юзеров.А как оно там по тестам в интернетах - да какая разница...
Всегда найдется тест, который покажет то, что хотел доказать тестировщик.Tony-Sol
09.01.2025 15:12некоторая старая система на PHP, например - после переписывания ее на Perl она стала быстрее, с точки зрения юзера. Хотя переписана почти "дословно"
Я не верю что это возможно в нашей вселенной) если только речь не про PHP <= 5.6, тогда еще с натяжкой крайне маловероятно, но может быть
Vedomir
09.01.2025 15:12Реально дословно или все-таки система и инфраструктура поменялось? В старых системах бывает очень много говнокода и старевших технологий. Особенно смущает то что именно с точки зрения юзера.
Приложения крайне редко упираются в производительность именно PHP, как правило бутылочные горлышки гораздо раньше встречаются - СУБД, сеть и так далее. Чисто вычислительная нагрузка где важна скорость языка в приложениях на PHP бывает очень редко.
Но даже так например PHP 7 примерно в два раза быстрее более старых версий.
Tony-Sol
09.01.2025 15:12Потому что до относительно недавнего времени подходы был такой что "один запрос - один процесс" и созданием процессов рулил php-fpm
Так, на каждый запрос приложение полностью инициализировалось с нуля и даже так, начиная с php 7, это обгоняло многие языки
Vedomir
09.01.2025 15:12Тут - это где? В маленьких скриптах и крохотных проектах она действительно не нужна.
Чем больше проект тем больше нужна типизация - банально потому что она резко сокращает количество ошибок, особенно неявных и сильно упрощает чтение кода.
А исправление ошибок и чтение кода - это и есть самые сложные задачи в разработки которые занимаю большую часть времени при разработке.
Да и написание ускоряет - банально то же автодополнение в IDE.
Tony-Sol
09.01.2025 15:12Удобство. Он легкий, простой, быстрый, напоминает одновременно С и JS.
php напоминает их гораздо больше, но (к моему огромному сожалению) и он не так распространен для всякого shell-scripting
Tony-Sol
09.01.2025 15:12А алфабет текущий не менялся уже лет сто. Ну, если не считать редуцирование буквы ё, которая тем не менее пока сохраняется.
Ох, сколько мне, человеку с фамилией Соловьёв это редуцирование буквы ё добавляет проблем)
a-tk
09.01.2025 15:12Из особенного - если есть массив @x, то $x - его длина. Или если %x - это хэш-таблица, то $x - её длина.
JBFW Автор
09.01.2025 15:12Это не совсем правильно, точнее совсем неправильно )
# это скалярное значение my $x = 1; # или "1", или "корова", или ссылка на массив или хеш. # это массив, он сам по себе, к $x не относится никак. my @x = ( 23, "да" ); # это хеш, он тоже сам по себе, к $x не относится никак my %x = ( name => 'товар', price => 123.43 ); # а вот это длина массива или хеша $x = @x; # или = %x, или = scalar @x; # просто она присвоена переменной $x
checkpoint
09.01.2025 15:12Я бы сформулировал это так: присваивание нескалярной переменной к скаляру возвращает её длину.
CaptainFlint
09.01.2025 15:12Кроме того, есть ещё $#x — последний существующий индекс в массиве @x (== длина минус один).
Tony-Sol
09.01.2025 15:12ИМХО - вот из-за таких преколов perl и оказался там, где сейчас
CaptainFlint
09.01.2025 15:12Это синтаксический сахар. Можно и не использовать, если не нравится. А писать нечитаемый код можно абсолютно на любом языке, это претензия не к языку, а к программистам. И особенно удобно, что перл позволяет делать ибыстро на коленке, чисто для себя, и детально-развёрнуто, для проектов с долгосрочной поддержкой. Подход TIMTOWTDI, There Is More Than One Way To Do It.
Но да, современный мир этого не любит, всем подавай упрощение и урезание.
Tony-Sol
09.01.2025 15:12Ну я больше иронизировал, подразумевая известный "однострочник на перле":
perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see'Но да, современный мир этого не любит, всем подавай упрощение и урезание
Какие-то взаимоисключающие параграфы - синтаксический сахар и призван для упрощения и урезания, поэтому не понял почему тут "Но" стоит.
Так то я всеми руками ЗА то чтобы писать максимально развернуто, просто часто был свидетелем того, как такие поделки "для себя" потом попадали в большой проект потому что "ну я уже решал подобную задачу, вот у меня заготовочка осталась, а переписывать ее подробно мне сейчас
леньнекогда"CaptainFlint
09.01.2025 15:12Какие-то взаимоисключающие параграфы - синтаксический сахар и призван для упрощения и урезания, поэтому не понял почему тут "Но" стоит.
Он сокращает код, но не всегда сокращение равносильно упрощению. Для программиста это требует более глубокого знания языка, а иногда и освоения нестандартных подходов, как скажем, булевый оператор диапазона. А сейчас всем некогда изучать глубоко, надо бегом-бегом клепать под очередной фреймворк, пока он не устарел.
А великий однострочник, хоть и навёл в своё время шороху, но больше из-за методики его применения, чем из-за того, что он перловый. Схожие примеры я видел и для других языков. Как, например, после выхода очередного стандарта C++ народ стебался, что теперь в нём выражение
([](){})()— это осмысленная компилирующаяся синтаксическая конструкция, язык достиг совершенства. Да и в чистом C определения типов порой такие, что никакой Перл с ним не сравнится.просто часто был свидетелем того, как такие поделки "для себя" потом попадали в большой проект
Опять же, это не специфично для Перла, а происходит с любыми проектами на любых языках.
Tony-Sol
09.01.2025 15:12надо бегом-бегом клепать под очередной фреймворк, пока он не устарел
Как хорошо, что я никогда не был в подобной ситуации:) С другой стороны, всегда оказывался в ситуации «у нас огромный монолит на php, который мы распиливаем» (кажется, что тут то и должно выстрелить «…на новый модный фреймворк», вот только он уже N мажорных релизов сменил с момента начала распила)
Опять же, это не специфично для Перла, а происходит с любыми проектами на любых языках.
Истинно так
Vedomir
09.01.2025 15:12>Он сокращает код, но не всегда сокращение равносильно упрощению.
Сокращение кода как по мне очень второстепенная задача по сравнению с читаемостью и очень часто приносящая больше вреда чем пользы. Это еще очень мягко выражаясь.
CaptainFlint
09.01.2025 15:12А вот тут всё совсем не так просто. Чем короче код, тем быстрее его можно охватить взглядом, просто за счёт меньшего объёма исходных данных. То есть при прочих равных (очень важное уточнение!) более короткий код выигрывает у длинного.
Но возьмём следующий пример. Какая из двух строчек тут быстрее читается и понимается?
amountOfSomeEntities = amountOfSomeEntities + 1; ++amountOfSomeEntities;Очевидно, вторая. Но очень легко представить аргументацию вида: вторая строчка использует какой-то странный оператор, который не все могут знать и помнить наизусть, а первая строчка совершенно чётко описывает действие на всем понятном языке. То есть такое сокращение вредит и ухудшает поддерживаемость кода, и в серьёзных проектах надо всем от него отказаться.
Я специально взял такой утрированный пример, ибо сложно представить программиста на C, который не знает про инкремент. И тем не менее, факт остаётся: код упростили, но для его понимания стала требоваться более высокая квалификация, более глубокое знание языка. Так вот, с Перлом всё абсолютно то же самое, просто выражено более явно за счёт большего числа "сахарных" конструкций и меньшего числа людей, которые готовы эти конструкции изучать и осваивать.
Весь вопрос в балансе между читаемостью и краткостью. Но баланс — дело субъективное. Для профессионала нет абсолютно ничего сложного в понимании всяких там
$_,$.,<>=~/foo/bar/gr, это стандартные типовые конструкции, он ими и сам по двадцать раз на дню пользуется, и в чужом коде постоянно видит, что там может быть непонятного? А кто-то другой смотрит на это нагромождение символов и материт разработчика за совершенно нечитаемый код. Казалось бы, давайте немножко подстроимся в пользу менее квалифицированных разработчиков, будем писать чуть более распространённо? Но для владеющего языком это предложение выглядит точно так же, как для сишника — предложение отказаться от инкремента и писать полные присваивания. В конце концов, для кого-то и регулярные выражения — неподъёмная тема, так что же теперь, от них тоже в своём коде отказываться, переписывая всё на дерево с цепочками сравнений подстрок?..
Vedomir
09.01.2025 15:12Понятное дело что в мире нет ничего абсолютного и нельзя сказать что абсолютно любое сокращение кода за счет ухудшения читаемости зло.
И понятное дело что если с кодом работают исключительно сеньоры которые превосходно знают текущий язык то все будет смотреться сильно иначе. Или вообще один синьор и пишет он код исключительно для себя.
Но как по мне в реальной жизни над кодом работают не только сеньоры, более того очень часто бывает ситуация когда сеньор напишет часть проекта или начальную версию и уйдет либо на другой проект либо в другую команду либо вообще в другую компанию. А поддерживать, исправлять ошибки, доделывать и развивать придется вообще не синьорам.
Не говоря уже о том что очень странные и сложные конструкции могут писать как раз не синьоры, скажем так люди с небольшим опытом, уже знающие о продвинутых возможностях но понятия не имеющие где их не стоит применять.
И первый и второй случай не раз видел на практике.
Так что я бы все-таки стоял на таком опытном правиле что читаемость приоритет почти всегда (и я вот так сходу не назову примеров когда она не нужна). Хотя бы потому что твой код потом возможно придется править и исправлять неопытному человеку и ты сам можешь оказаться в такой ситуации на новом стеке технологий. И средства языка как по мне должны поддерживать и поощрять это правило.
CaptainFlint
09.01.2025 15:12Я не отрицаю, что читаемость важна. Я пытаюсь сказать, что читаемость — субъективное понятие, зависящее в числе прочего от квалификации читающего. Невозможно подогнать формат кода под любого будущего чтеца. А попытки облегчить читаемость кода путём избавления от невразумительных (точнее, кому-то кажущихся невразумительными) конструкций могут привести прямо к противоположному эффекту, когда вместо одной простенькой операции, о которой можно прочесть в мануале, читателю придётся разгребать полстраницы кода, делающего то же самое. Пускай даже очень грамотно написанного и понятного кода, но полстраницы — это полстраницы.
JBFW Автор
09.01.2025 15:12Вот именно, начинается с того что люди, опытные программисты, начинают экономить на лишней строчке или скобке, вместо понятного по смыслу слова типа print начинают использовать закорючки, а потом приходит кто-то новый, видит там "std|None=None" и понимает что ничего непонятно, надо всё заменить на простое и понятное, для тупых.
amironov
09.01.2025 15:12Там привели не полную конструкцию. Должно быть:
s: str | None = NoneТак понятнее?
Vedomir
09.01.2025 15:12Популярность и не популярность языков очень часто связано не с их техническими решениями, а с политическими или стечением обстоятельств. JavaScript наверное самый наглядный тому пример. Да и PHP тоже в каком то смысле. Два языка который создавались как средства для создания простеньких и коротких скриптов в итоге применяются для написания огромных приложений и в них дико кривыми и неудобными способами тащат средства, предназначенные для написания крупных приложений.
e_u_g
09.01.2025 15:12Ага. А в универе, в 90е была курсовая: Написать консольного email клиента на awk, под SunOs. Как уже сказано выше - закопайте стюардессу
JBFW Автор
09.01.2025 15:12Если бы вы получали телеметрию от древней железяки по email, и вам потребовалось бы интегрировать ее в какую-то систему мониторинга - возможно, консольный awk по крону оказался бы вам очень кстати.
И намного более кстати, чем ждать, пока производитель новой системы мониторинга раздуплится написать для вас обновление, поддерживающее эту древнюю железку.Хотя почему древнюю? Это почти та же задача, которую пришлось не очень давно решать, забирая с email-сервера фотографию, снятую камерами наблюдения, для отправки на обработку в AI на предмет подсчета количества человек.
Просто я awk не настолько хорошо знаю, оказалось проще написать на perl перехватывающий smtp-сервер...e_u_g
09.01.2025 15:12Кажется, я не сумел донести мысль. Попробую развернуть.
Компьютерные технологии - это кладбище блестящих инженерных и научных идей и решений. И нет смысла их реанимировать. Нужно признать - они мертвы.
Да, в своё время perl, COM+, prolog и т.д. были в фаворе. Но нет технической причины их вытаскивать и как-то пытаться возбудить к ним интерес. Та же функциональность достигается сегодня иными средствами. И да, вполне вероятно, и эти средства через год/два/пять устареют и также исчезнут.
Каждый из нас несёт персональный груз подобных мёртвых знаний и навыков. Ваше воспоминание perl отрекошетило мне awk-ом. А ведь мог бы и коды калькулятора МК-56 припомнить :-)
JBFW Автор
09.01.2025 15:12Да никто не пытается "возбудить интерес" )
Я не продаю ни курсы, ни книги.Есть работающая штуковина - я об этом говорю. Это инструмент.
Есть задачи, решаемые. Вот понадобилось решить с теми же фотографиями - беру инструмент и решаю. Наверное, кто-то решил бы используя python (awk - вряд ли тут подойдет).
Кто-то напишет на С. Кто-то решит, заменив видеокамеры. Кто-то "обратится к специалистам, они сделают".А есть подход "эта лопата старая, поэтому ей копать я не буду, а буду копать новым смартфоном, он тонкий, легкий и современный!".
Newbilius
09.01.2025 15:12С первой частью комментария согласен - если есть необходимость решить задачу чисто для себя, не думая о том, что это придётся поддерживать другим людям - то нормально воспользоваться любым привычным инструментом)
А вот по поводу последнего абзаца - уже звучит как брюзжание, "да, моя лопата кривая и неудобная, но поивычная! А эта молодёжь напридумывала какую-то эргономику, понимаешь." ;)
karmael
09.01.2025 15:12экий вы торопыга.
ну вот ей богу, если в вашей жизни не существует awk то с вероятностью чуть более 99%, вы не инженер, не админ, и в целом от железно-аппаратных проблем держитесь на расстоянии абстракций, делая громкие заявления о мёртвости того, что у вас и живым то никогда и не было.
awk, bash, grep и их весёлые комбинации всё так же сопровождают по жизни системных инженеров и системных администраторов. Потому, что вот то что вы держите на расстоянии абстракций, не то что бы графического иного кроме консоли интерфейса не имеет, а нужно получать метрики, софты настраивать, за вами прибирать, громкими пограмистами.
вот эта тяга неуёмная к трэндам и кейсам, живет решительно в какой то своей параллельной вселенной полной комиксов и соевых новостей, про модные фреймворки опережающие своё время.
checkpoint
09.01.2025 15:12Я таких называю "смузихлёбы". Весь софтовый мир держится на людях программирующих на C и C++, знающих ассемблер и способных дебажить в gdb до талова ночи на пролёт. Как только последний сишник уйдет на пенсию, весь их чудесный облачный мир красивых и разнообразных фреймворков накроется п$#%ой.
Tony-Sol
09.01.2025 15:12Здесь и комментом выше - какие-то слишком черно-белые утверждения.
Например я, если выбор между gui и cli - в 99% случаев выберу cli, но это не значит, что я буду называть тех, кто пишет консольные тулы на js или ruby «смузихлебами» (конечно я и использовать такие тулы вряд ли буду, но по другим причинам)
А «Последний сишник» не появится никогда, ввиду того, что всегда (по крайней мере я хочу в это верить) будут люди которым интересно копнуть глубже фреймворка и `npm install`
kmeaw
09.01.2025 15:12gdb очень полезен вместе с awk или perl. Например, собрать все стеки, когда возникает какое-то событие, а потом каким-нибудь хитрым образом их поделить на классы. Или сгенерировать с их помощью скрипт для gdb, чтобы воспроизвести нужное состояние.
Kahelman
09.01.2025 15:12Вообще-то на awk и сей час писать Парсинг всяких логов и прочих текстовых файлов одно удовольствие. Работает везде даже под виндой. Проблем с обратной совместимостью нет. Да и скорость приличная- поскольку писали люди знающие а не скрипт кидс
fiego
09.01.2025 15:12Зачем писать на AWK то, что можно легче и гибче написать на Perl? Есть даже автоматический транслятор за авторством Ларри: a2p - Awk to Perl translator
JBFW Автор
09.01.2025 15:12awk быстрее стартует.
Так что смотря какая задача.
fiego
09.01.2025 15:12Довольно спорный аргумент. Запускать процессы Awk тысячами в секунду -- я бы посмотрел на этот Use Case... Perl стартует так же довольно быстро и редко это является проблемой. А вот прямо чтобы именно время запуска было критерием выбора пользоваться Perl или Awk -- мне такого не встречалось, а я на Perl начал писать примерно 25 лет назад.
JBFW Автор
09.01.2025 15:12Периодические функции по крону. Чем быстрее они отрабатывают и чем меньше памяти жрут тем выгоднее.
Другой вопрос что многие привыкли что у них всего с запасом, подумаешь, лишние 0.5%
fiego
09.01.2025 15:12$ time (for i in `seq 10000`; do awk ''; done)
real 0m12.103s
user 0m2.521s
sys 0m10.190s$ time (for i in `seq 10000`; do perl -e 0; done)
real 0m10.619s
user 0m3.206s
sys 0m8.038s
Я что-то не усекаю принципиальную разницу
Tony-Sol
09.01.2025 15:12Запускать процессы Awk тысячами в секунду -- я бы посмотрел на этот Use Case...
cat файл_в_тысячи_строк | awk '{print NR,$0}'И вот awk запустился тысячи раз, и на современных машинах скорее всего реально будет секунда </s>
amironov
09.01.2025 15:12Здесь awk запустился ровно один раз.
Tony-Sol
09.01.2025 15:12Хм, действительно, что-то я напутал - казалось в пайпе он будет запускаться на каждый элемент, переданный в stdin, то есть ожидал, что такая конструкция:
seq 1 10 | awk '{if (length(a) == 0) a=1; print $0 " " a; a++}'будет всегда печатать "1" во втором столбце, но нет - был неправ
fiego
09.01.2025 15:12И вот awk запустился тысячи раз
Каким, простите, образом? В написанной вами команде программа
catчерез пайп целиком отправляет файл в программуawk. Файл открывается один раз, пайп открывается один раз,awkзапускается один раз.
pawnhearts
09.01.2025 15:12Хм? awk постоянно использую в скриптах. Solaris был на работе когда-то, но и сейчас несмотря на все старания oracle его погубить есть масса применений, СХД всякие с ZFS(хотя даже nexenta вроде загнулась). Там отличная контейнеризация давно и можно было делать контейнеры и с линуксом, dtrace, SMF.
verls
09.01.2025 15:12У вас байты сыреют и осыпаются от старости? Давайте закопаем тогда арифметику с их
2+2 =4- ведь ей уже 2,5 тыс лет!
aeder
09.01.2025 15:12Вот именно то, что perl не меняется десятилетиями и при этом есть везде - и подкупает.
Да, изначальный синтаксис придумывали люди с более высоким IQ, чем у нынешних поколений - потому что это была эпоха, когда программист не мог назвать себя программистом, если не умел хоть немного писать в машинных кодах.
Но ведь не обязательно держать в голове все умолчания и сокращения, можно писать подробно.
arheops
09.01.2025 15:12Уже не везде. в полследних rhel его нету, к примеру.
Перешли на питон. И честно говоря приимуществ перед питоном у перла немного.
Tony-Sol
09.01.2025 15:12приимуществ перед питоном у перла немного
Не холивара ради, а просвещения для: а наоборот?, у перла перед питом какие есть преимущества?
CaptainFlint
09.01.2025 15:12Я, например, пишу на перле и на питоне, но когда требуется склепать что-нибудь для себя, первым делом выбираю перл. Во многих сценариях он намного лаконичнее:
my $out = `ls -la`; die "Oh no, we failed!" if ($?);import sys import subprocess try: out = subprocess.check_output(['ls', '-la']) except: print("Oh no, we failed!") sys.exit(1)Кроме того, перл гораздо свободнее в оформлении кода. Добавить отладочные принты с намеренным нарушением отступа, чтобы их потом можно было быстрее найти и удалить? Вставить в произвольное место некий временный кусок кода для какой-нибудь проверки наживую, а потом удалить его, без необходимости каждый раз выравнивать пробелы туда-сюда? Быстро сварганить однострочник для одноразового действия (включающего условные операторы)? Питон тут совсем не помощник.
Разумеется, существует и множество сценариев, где питон выигрывает. Как с любым инструментом, нужно просто оценивать применимость к конкретной задаче.
JBFW Автор
09.01.2025 15:12Ну вот тоже не холивара ради, вопрос:
Есть текстовый файл, условно 4 гигабайта, состоящий из примерно таких строчек:
XXXYYY 12 34 56 78 90 09 87 65 43 21
XXXYYA 23 45 67 89 09 87 65 43 21 10
bebebe! blablaba
XXXYYY 12 34 56 78 90 09 87 65 43 21
XXXYYA 23 45 67 89 09 87 65 43 21 10Требуется:
1 - в строчках типа XXXYYY переставить местами 12 34 56 78 -> 78 56 34 12 и так далее
2 - записать в файл байты 0x78 0x56 0x34 0x12
3 - строчки bebebe игнорировать.Время выполнения скрипта не критично. Способ выполнения scriptname <datafile> > result.bin.
На Perl это можно сделать например так (неидеально но работает)#!/usr/bin/perl $|=1; sub decoder { my $str = shift; $str =~ /(\w\w)(\w\w)(\w\w)(\w\w)/; print chr(hex($4)) . chr(hex($3)) . chr(hex($2)) .chr(hex($1)); } while(my $str = <>){ if($str =~ /^XXXY.*: (\w+) (\w+) (\w+) (\w+) /){ decoder($1); decoder($2); decoder($3); decoder($4); } }Время написания скрипта - ну, минуты две, наверное, чисто по ходу дела.
Напишите на Python?
Еще раз, не холивара ради, я Python практически не знаю, а то что видел - там нужно "создать окружение", потом уже в нем запустить программу - как-то неудобно это.Tony-Sol
09.01.2025 15:12Быстро на питоне я бы такое не написал, а сделал бы баш портянку, типа
less datadile | grep -v -E '^XXXY' | sed -E 's/(XXXY.+ )(.*)/echo \1$(echo \2 | rev)/e'но если это потенциально нужно будет переиспользовать мне, то как-то так
#!/usr/bin/python3 import sys with open(sys.argv[1]) as f: for line in f: if str(line).startswith('XXXY'): parts = line.rstrip().split(' ', 1) print(parts[0] + ' '.join(map(lambda a: chr(int(a, 16)), reversed(parts[1].split(' ')))))а если и не только мне, то написал бы читаемо
#!/usr/bin/python3 import os import sys def main(filename: str): if not os.path.exists(filename): sys.exit(1) with open(filename) as f: for line in f: if not str(line).startswith('XXXY'): continue [prefix, codes] = line.rstrip().split(' ', 1) codes = codes.split(' ') codes.reverse() codes = [chr(int(code, 16)) for code in codes] print(prefix + ' '.join(codes)) if __name__ == "__main__": main(sys.argv[1])JBFW Автор
09.01.2025 15:12sed не то делает, он циферки местами переставляет, а нужно было Little Endian HEX to bindata транслировать )
Группы по 4 "XX", переставлять и переводить из текста в байтыА в Python разве нет регулярных выражений? Должны быть по идее...
Tony-Sol
09.01.2025 15:12sed не то делает, он циферки местами переставляет, а нужно было Little Endian HEX to bindata транслировать )
да, точно, не законченный пример, но в gnu sed благодаря
/eможно дописатьГруппы по 4 "XX", переставлять и переводить из текста в байты
это не понял
А в Python разве нет регулярных выражений?
JBFW Автор
09.01.2025 15:12Это была довольно занятная история со снятием прошивки с девайса, где отрубили вообще возможность что-то куда-то сохранять, то есть никаких xmodem, никаких tftp, никаких fatwrite.
Можно только считывать кусочками в RAM и смотреть на экране по 256 байтиков, в HEX-формате 32-битных чисел, да еще LE, то есть там, где на PC строка "1234" выглядит как 31343334 - в дампе было 34333231
А строки выглядели вот так :
0x3e44430 01020304 05060708 80818283 84858687Первая группа - адрес, он более-менее постоянный, 0x3e4*, потом 4 группы по 8 символов, точнее 4 двухсимвольных, 4 байта.
И вот была задача потом всю эту простыню разобрать на группы, группы на байты, байты переставить в обратном порядке и записать в бинарник.
Ну, всё получилось в итоге.Регулярные выражения - вообще замечательная штука
Tony-Sol
09.01.2025 15:12Ааа, прикольно, действительно интересная задача
К сожалению, я не настоящий программист, а, что называется, веб-макака (переметнувшаяся в devops), поэтому у меня такого не было. Из интересного - нужно было в монорепе helm-чартов организовать запуск их линтеров/тестов затронутых merge request’ом, тогда намучавшись с bash’ом переписал на python. Возможно на perl получилось бы короче, но это была бы +1 технология, которая бы только мешала
JBFW Автор
09.01.2025 15:12а вот это правильно, если вы работаете с А и Б, то тащить туда еще и В без крайней необходимости не стоит, будет зоопарк...
CaptainFlint
09.01.2025 15:12Создавать окружение не надо, это требуется только в тех сценариях, где необходимо обеспечить фиксированный набор модулей и их версий, заточенный под конкретный скрипт.
amironov
09.01.2025 15:12Для подобного perl хорошо подходит, но здесь он как раз играет на поле sed, awk и прочих shell утилит.
pawnhearts
09.01.2025 15:12Ну так-то там неплохие фреймворки были для всего времени типа Catalyst. Если придерживаться принятого в тем стиля, а не https://ru.wikipedia.org/wiki/JAPH то можно было писать неплохой поддерживаемый кот. Вообще буквально пару лет назад работал в конторе где мы переписывали их код с perl на python, но, скорее потому что найти программиста на perl сейчас сложно.
Вообще raku очень прикольная штука вышла, там можно переопределять вообще всё и лепить всякие dsl, но уже не взлетит.
c0r3dump
09.01.2025 15:12Perl был первым языком на котором я начал писать, но сейчас нет никакого желания писать на нем и уж тем более читать чужой perl-код. А ЖЖ вроде был на перле изначально, интересно это до сих пор так, хотя бы от части?
checkpoint
09.01.2025 15:12Продолжаю использовать Perl5 для всяческой автоматизации, расчетов и конвертирования блоков данных. Хэши и pack/unpack - наше всё. Также мне очень нравится репозиторий библиотечных модулей с готовыми примерчиками и документацией - наливай да пей.
Сильно сожалею, что в борьбе за место под солнцем выиграл тормозной Python со своим уродским синтаксисом и кучей проблем совместимости между разными версиями. Только что наткнулся на неизвестную мне ранее конструкцию ": str | None = None" ипользуемую в стороннем приложении, которую ввели в Python 3.10, а у меня 3.9. Ставить еще один комплект питона в добавок к пяти уже установленным жутко напрягает. Хочется поубивать и тех, кто постоянно выдумывает новый синтаксиc, и тех, кто норовит запихнуть его во все места.
arheops
09.01.2025 15:12Хорошая конструкция, кстати.
Когда у вас 5-10 параметров со сложными типами очень помогает.
Мы из за нее пайплайн апгрейднули до 3.10
То, что в мелких скриптах она вам не нужна - не значит, что другим не нужна.
checkpoint
09.01.2025 15:12То, что в мелких скриптах она вам не нужна - не значит, что другим не нужна.
Но как-то же вы обходились без неё много лет ? Какой принципиально новый функционал эта фичка позволила вам внерить ? Заказчик доволен ? С колько кода пришлось переписать и времени на это потратить ? А сколько ждет чудесных моментов людей которые придут на Ваше место и наткнутся на этот код ?
arheops
09.01.2025 15:12Одно изменение ничего не влияет. Но сумма - да. А перл не развивается.
Главное, что команда довольна ;) Принципиально - обьявление функции стало не три строчки, и одну. Когда их дофига это сильно упрощает чтение кода.
Код переписывать не пришлось.
Если на мое место прийдут люди, не интересующиеся языком - гугл и чатгпт всегда помогут.
В частности в вашем примере правильно было написать Optional[str].
JBFW Автор
09.01.2025 15:12Поздравляю, вы и дошли к тому моменту, когда начинают писать нечитаемый код )
Вместо трёх строчек, понятных по словам - одна хитромудрая конструкция, понятная только опытному питонщику. Из написанной строчки совершенно не очевидно что именно она делает - присваивает None к переменной, а если она не определена - то к None? )
Тот, кто придет "вместо вас" не будет искать в Гугле, он скажет "это нечитаемый код, я напишу на современном языке Be!
Пока язык Be не обрастет сложными для понимания конструкциями, и очередной новый "пришедший вместо" не скажет: это нечитаемо, я напишу это на современном языке!
Таков жизненный цикл...
Tony-Sol
09.01.2025 15:12Из написанной строчки совершенно не очевидно что именно она делает - присваивает None к переменной, а если она не определена - то к None? )
Ой ну бросьте, это стандартный синтаксис который нужно знать, иначе все равно что открыть go-шный код и негодовать «это что за белиберда, потому для присваивания то
=, то:=используется?!»Тот, кто придет "вместо вас" не будет искать в Гугле, он скажет "это нечитаемый код, я напишу на современном языке Be!
А должен, потому что «написать на современном языке Be» конечно круто, только надо сначала понять, что делал исходный код, а без знания и/или гугления этого сделать не получится
JBFW Автор
09.01.2025 15:12потому для присваивания то
=, то:=используется?!Вот не помню, но в каком-то очень старом языке, типа REXX или тот же PL/1 было уже такое присваивание. Или в Prolog?
Зачем, почему - хз.
CaptainFlint
09.01.2025 15:12В Паскале/Дельфи такое присвоение, а одиночный = для сравнения и определения типов. Но историю вопроса тоже не знаю.
Tony-Sol
09.01.2025 15:12Какой принципиально новый функционал эта фичка позволила вам внерить ? Заказчик доволен ?
Доведенная до абсурда аналогия: «зачем придумывать понятные названия переменным, пусть будет a/b/x/y/i/j, что, от этого новую фичу можно будет внедрить или заказчик будет доволен?»
Заказчик будет доволен, когда новая фича появится в коде через неделю, а не 3 месяца, а чтобы это было возможным и добавляется подобный функционал, чтобы читая сигнатуру метода видел, что «ага, этот параметр отвечает за это и принимает или строку или ничего, а если ничего явно не передано, то там пустота»
fishHook
09.01.2025 15:12Хотя как он может быть непонятным и плохочитаемым, если типовая «первая программа Hello world!» выглядит буквально так
Какой интересный аргумент! Что же может быть сложного в ракетостроении, если формула Циалковского выглядит буквально так ...
Vedomir
09.01.2025 15:12Безотносительно конкретно Perl с которым дела не имел - как мне кажется как говнокод таки и хороший код можно написать почти на любом языке программирования и при выборе очень важное значение имеет банальный размер экосистемы. Сколько людей знают этот язык, сколько на нем библиотек и фреймворков, сколько разных платформ и сценариев использования она поддеживает, сколько из этих библиотек открытых и так далее вплоть до количества обучающих материалов и ответов на SO (и людей, сопособных ответить на новый вопрос).
Какая-то технология может быть ничуть не хуже других или даже лучше но размер экосистемы все равно будет очень сильно перевешивать.
Чуть выше писали что ничего страшного что библиотеки нет, ее же можно написать. В реальной жизни времени на написание библиотеки нет почти никогда и язык где библиотека уже есть будет очень сильно выигрывать, потому что на нем можно ее просто взять и использовать. Где библиотек несколько и/или они открытые еще больше выигрывать - как минимум если одна из них прекратит развиваться можно будет взять другую.
Есть конечно несколько больших классов языков - например при критичных требованиях по производительности подойдут языки класса C/C++/Rust и не очень подойдут языки класса PHP/TypeScript/Python/Java. Есть языки которые просто не поддерживают определенные классы задач - на PHP кроме бэкэнда ничего особенно не напишешь. Но за пределами этих не столько многочисленных обьективных параметров размер экосистемы один из важнейших критериев - и с ним у Perl явные проблемы.
JBFW Автор
09.01.2025 15:12Это потому что вы с ним "дела не имели" )
Так-то есть общедоступные библиотеки CPAN, MetaCPAN, где всякого разного полно. Именно такого, что связано с интернетом, UNIX, и прочим.
Но:
- вы о ней не знаете, и поэтому "ничего нет"
- там действительно есть не все, вот например YOLO я там не вижу. Никто еще не написал, а я не пробовал.Ну так и в Pytnon ничего нет, кроме скриптов для Гнома, разве не так? )
Tony-Sol
09.01.2025 15:12Ну так и в Pytnon ничего нет, кроме скриптов для Гнома, разве не так?
Если это не сарказм, вы ОЧЕНЬ сильно ошибаетесь)
Vedomir
09.01.2025 15:12Я не говорил что их вообще нет. Про вообще нет я цитировал и не про "вообще нет" а про "просто нет одной". Хотите сказать что там библиотек больше или столько же сколько же, как в экосистеме Python, Java, C# ну или PHP если говорить о бэкэнде?
Тут даже на C# например сталкиваешься с тем, что экосистема намного меньше чем у JavaScript например.
JBFW Автор
09.01.2025 15:12The Comprehensive Perl Archive Network (CPAN) currently has 221,249 Perl modules
Ну, если там не нашлось нужного модуля...
Конечно, на все случаи жизни наверняка не найдется, но мелочевку или специфическое своё туда обычно и не выкладывают, это оне гитхаб, где каждый - автор.Vedomir
09.01.2025 15:12В npm 3.1 миллиона, в PyPi 600 тысяч в nuget 432 749.
Хотя конечно сравнение чисто по количеств модулей не самое релевантное.
JBFW Автор
09.01.2025 15:12Помню, мы в детстве прикидывали максимальную скорость машины по номеру на ней.
Ну а зачем же еще он нужен, кроме как максимальную скорость показывать? Только непонятно было как цифры в скорость правильно переводить, не билось с реальностью...Вот тут то же самое )
Vedomir
09.01.2025 15:12Ну вот банально. Есть идея некого пет-проекта. Для него нужна открытая кроссплатформенная технология для написания графических интерфейсов приложений с поддержкой в том числе Linux (само собой винды, мобилки, веб тоже) и наличием открытого качественного компонента визуального редактирования форматированного текста. Хотя бы одного, лучше нескольких на случай если один умрет.
На C# такой нету, хотя 400 тысяч пакетов. А на TypeScript есть и несколько - сказываются те самые три миллиона пакетов.
В итоге если я соберусь писать этот проект то буду писать его на JavaScript/TypeScript. На самом деле конечно же не соберусь ни времени ни сил нет, но это другой разговор.
Хотя C# технически гораздо лучше. И быстрей и сам язык богаче и красивей.
Этот и есть тот самый размер экосистемы, который начинаешь понимать только тогда, когда задаешься решением практических задач.
Есть ли на Perl что-то такое?
JBFW Автор
09.01.2025 15:12Разумеется нет, потому что он вообще не предназначен для "написания графических интерфейсов", если не говорить о вебе.
Если говорить - то конкретно веб на нем и пишется прекрасно, под линукс, потому что запускать вебсервер на мобилке или на винде - ну, это отдельный вид развлечений, от языка не зависящий.Но никак не "компонент визуального редактирования форматированного текста".
Под эту задачу есть другие инструменты, и это нормально: вы же не пользуетесь в жизни одной столовой ложкой для всего, от супа до чая или там спагетти каких-нибудь?Но и обратное - когда инструмент "для визуального редактирования" начинают применять не по назначению - получаем вон как, есть одна такая, которая то виснет, то утечки памяти, то еще что-то - на nodejs работает.
Конечно может программист рукожопый попался, а может и сама технология не очень подходит )
Ее бы переделать по уму - но дешевле перезагружать раз в сутки.Vedomir
09.01.2025 15:12А C# и TypeScript предназначен. И это тоже повод для выбора в их пользу - больше задач можно решать на одном языке.
И это все тот же размер экосистемы.
JBFW Автор
09.01.2025 15:12А на С/С++ вообще можно любые задачи решать - но это не значит что всё надо на C делать )
Vedomir
09.01.2025 15:12С/C++ языки с ручным управлением памятью, это вполне объективное отличие. Ну и огромным нездоровым наследием ранних эпох развития инфотеха.
А чем Perl принциипально отличается от C# и TypeScript?
JBFW Автор
09.01.2025 15:12Ну и огромным нездоровым наследием ранних эпох развития инфотеха
Это называется понимание архитектуры, когда слова "указатель на память" означает адрес вон той ячейки памяти, а не просто некую абстракцию, именуемую "указатель"
Tony-Sol
09.01.2025 15:12на PHP кроме бэкэнда ничего особенно не напишешь
https://github.com/SerafimArts/opengl-demo
Но со всем остальным - полностью согласен
Vedomir
09.01.2025 15:12Могу ошибаться, но это все единичные эксперименты, и при попытке написать реальное приложение повторится та же ситуация с экосистемой, грубо говоря экосистема написания всего кроме бэкэнда на php ничтожна.
Собственно по ссылке Please note that this is only a demo and may contain non-optimal, crazy and completely unbelievable programming techniques (...) Oh yes, according to my information, nobody has ever done such things in pure PHP.
Тут ведь с одной стороны круто что чел делает то что никто никогда не делал на PHP с использованием безумных техник.
Но это полная противоположность тому, что надо использовать в реальном проекте нацеленном на какой-то практический результат.
Tony-Sol
09.01.2025 15:12Не, понятное дело, что это просто показательный пример того что можно написать на php и никто в здравом уме не будет делать игры на нем. Хотя код там довольно простой, без каких-то совсем уж эзотерических конструкций.
Это все я скорее к тому, что выражение "на PHP кроме бэкэнда ничего особенно не напишешь" можно по разному прочесть. Или как "PHP ни на что кроме бэкэнда не способен" и тогда это заблуждение, потому что можно написать практически что угодно, или как "на PHP нет смысла писать что-то кроме бэкэнда" - и вот с этим я уже согласен
Vedomir
09.01.2025 15:12Да я про то, что экосистема написания всего кроме бэкэнда на php ничтожна.
JBFW Автор
09.01.2025 15:12Ну так глупо лопатой пироги на столе резать и щетину брить.
Можно - если наточить - но для других задач есть другие инструменты.Vedomir
09.01.2025 15:12Не касаясь именно Perl - а почему нет то? На C# например можно и игры делать и десктопные приложения и мобильные и бэк для веба и фронт.
Плох он только на низкоуровневом системном программировании где царят C/C+ и Rust ну и в написании простых скриптов.
И почти везде он технически гораздо лучше лидеров в этих сферах - например PHP и TypeScript.
Но на практике он хуже по чисто политическим и историческим причинам.
Ну и по размеру той же экосистемы как следствие политики и истории.
Насчет того что лучше C# или Perl технически ничего сказать не могу. А вот и TypeScript и PHP и C# хорошо знакомы.
Но вот сама идея использования одного языка в разных сферах вполне здравая.
checkpoint
09.01.2025 15:12Не касаясь именно Perl - а почему нет то? На C# например можно и игры делать и десктопные приложения и мобильные и бэк для веба и фронт.
На Perl-е можно делать всё тоже самое. Я пишу простые GUI интерфейсы к разрабатываемым нами устройствам на Perl/Tk. Работает одинаково на Windows и FreeBSD.
Более того, у меня есть простой пример, perlix, демонстрирующий создание окна X11 без каких либо графических библиотек, чисто передача данных по TCP соединению.
JBFW Автор
09.01.2025 15:12Ну так-то это Tk, тот же самый что tcl/tk, python/tk - разницы особо нет.
Вот именно что простые интерфейсы, чисто "введите пароль - введите команду - спасибо, досвидос"
checkpoint
09.01.2025 15:12На Tk написаны многие САПР для электроники, так, к слову.
JBFW Автор
09.01.2025 15:12Не-модно, не-современно, - не-красиво, немедленно переписать! )
(а кстати, на Tk вроде можно скины натягивать? Где-то было упоминание об этом, очень давно. Ну и делали бы: хочешь - "телепузиков", хочешь - "стекло", или этот, как его, "material design")
Но наверняка мешает "неустранимый недостаток №1" - "это писали не мы!"
fiego
09.01.2025 15:12И только внимательный читатель (участник чата https://t.me/modernperl) заметил ошибку в оригинальном тексте:
my @array = [0,1,2,3,23,44,23,23453,5];JBFW Автор
09.01.2025 15:12да. Привычка: $x = [...] или $x = {} , но тут надо было именно @x от %x наглядно отделить, а тогда - (..)
bungu
Забыт он только среди javascript-макак (которые о нем возможно вообще не знали). А в реальности у Perl есть свое комьюнити и свой рынок труда
JBFW Автор
А тут как с PHP:
1 - студенты: мы учили PHP, на нем можно писать сайты!
2 - студенты: мы пишем "сайты на PHP", обращайтесь к нам!
3 - менеджер: хм, нашей конторе нужен сайт, "сайт на PHP" (хз что это такое, наверное то что надо)
4 - менеджер: ищем исполнителей, нам нужен сат на PHP?
5 - веб-контора: а на RoR пойдет? На J2EE? На Perl?
6 - менеджер: нам нужен сайт на PHP! Можете на Perl такой сделать?
7 - веб-контора: ок, вот ваш "сайт на PHP", на Perl, устроит? (pokerface)
8 - менеджер: да, то что надо! У нас теперь есть свой "сайт на PHP"!
anoneko
Сам-то на ассемблере кодишь поди, как труъ?
Tony-Sol
Технически - да, есть комьюнити и рынок, но как говорится «и что?». И у cobol тоже есть и комьюнити и рынок, делает ли это актуальным языком - уверен что нет.
Я понимаю теплое чувство ностальгии, но объективно в perl сейчас очень мало смысла. Его же использовали там, где полотна на bash совсем уже разрастались до невозможного и нужен был язык «который есть везде», а python как раз болел своей 2to3 болезнью - и тогда это было логично, но сейчас…нухз
Не призываю «закопать стюардессу», но и не согласен, с тем, что она еще жива
или хотя бы еще теплая