хоть и повторяюсь за другими, но ещё раз подчеркну, что главная киллер-фича перла - встроенный синтаксис для регулярных выражений

да нет же

это очень круто, удобно, лаконично и легко запоминается(чего не скажу про некоторые другие элементы синтаксиса перла)! даже в пайпах это юзаю (со следующими ключами perl -ne ...)

крутость, удобство, лакончиность - это все мимо

Просмотрел всю чушь которую понаписали в треде, но ни один из вас так и не раскрыл мощь perl5. Неужели никому из вас так и не раскрылся perl5 на деле?

Если вы хотите профессионально заниматься веб-скрейпингом, то выкиньте из головы все кроме Javascript и phantomjs. На дворе 2014 год и скачивание с последующим парсингом HTML уже не дает желаемого результата. Или используйте байндинги Perl к phantomjs.

Не знаю насколько это канает за «профессионально», но все мои исследования зиждятся на способности собрать эмпирические данные из онлайн-источников. И мне как-то перла хватает. Да что перла, часто можно голым bash-ем обойтись, используя дампинг elinks-а и обычные консольные утилиты для обработки текста.

Наверное, если бы данные пришлось собирать с вебдванольных ресурсов в кажду страницу которых бригаду разработчиков натошнило JS-ом и чёрт знает чем, я бы сел в калошу. Но, к счастью, пока что не приходится.

Неужели никому из вас так и не раскрылся perl5 на деле?

Нет. А где ты в комментах хоть одного перловщика увидел, всё сплошь любители? Давай, не томи, излагай.

Неужели никому из вас так и не раскрылся perl5 на деле?

Раскрылся, но не тем местом :) Могу много рассказать о том, почему не следует выбирать Perl и могу много рассказать в чем плюсы перла.

Просмотрел всю чушь которую понаписали в треде, но ни один из вас так и не раскрыл мощь perl5.

Все правильно пацаны раскрыли. Мощь перла в однострочниках с регулярками. Однако, перл не всегда «фонтан», потому что до него был и будет рулить awk.

Раскрылся, но не тем местом :) Могу много рассказать о том, почему не следует выбирать Perl и могу много рассказать в чем плюсы перла.

Все правильно пацаны раскрыли. Мощь перла в однострочниках с регулярками. Однако, перл не всегда «фонтан», потому что до него был и будет рулить awk.

Спасибо за предложение, но с таким уровнем понимания не уверен что вы можете что-то значимое рассказать. С такими рассказами вам наверное «к пацанам» надо.

Чем оно удобнее поддержки на уровне стандартной библиотеки?

Отсутствием многословности и быстрым результатом. Легко расширить сравнение по шаблону перл кодом, и сам код с помощью регулярных выражений. PCRE, CPAN.

в Python есть нормальнве модули, которые делают полное преобразование (в соответствии со стандартом HTML5) HTML-текста в дерево-объектов.

А если сайт не особо стандарт HTML5 соблюдает, то что? Всё встанет?

Мм. Ничего не имею против очередного Царя. Как вы изволите изложить что-то больше «я папка, знаю столькоооо, да я....», сообщите.

Вот тебе вопрос: как вы решили вопрос многопоточности (параллельное исполнение множества задач) в перле? Если вы пишите для веба, то какая у вас используется БД (это мне даст ответ на 95℅ других вопросов). Далее, как вы храните в перле массивы/хэши из миллиона однотипных данных ( скажем массив из 100 млн. чисел)? На каком железе вы запускаете перл? С более 256Гб ОЗУ?

Perl есть для квантовых компов
И самый важный момент Perl это патч Бирмана, все мы помним тему, перл и нистрочки кода

А если сайт не особо стандарт HTML5 соблюдает, то что? Всё встанет?

Не встанет. Построится дерево не совсем корректное (но вполне достаточное для его обхода и поиска нужных ветвей)

многословности

А потом удивляются, чего это скрипты на пердле прочитать невозможно, бгггг.

Мм. Ничего не имею против очередного Царя. Как вы изволите изложить что-то больше «я папка, знаю столькоооо, да я....», сообщите.

Царя? Уже XXI век на дворе ..

Вот тебе вопрос: как вы решили вопрос многопоточности (параллельное исполнение множества задач) в перле?

С «тебе» вам вероятно все же «к пацанам». Тем не менее отвечу.

0. MPI ?

1. Тривиальные задачи можно решить используя AnyEvent::Util::fork_call. Если fork_call «дороговат» (например когда множество вызовов), то можно организовать пул процессов с одним супервизором; AnyEvent::Util::portable_pipe + Storable вам поможет в обмене как кода так и данных.

3. Нетриваиальные задачи можно решить с использованием пула форков и группы IPC::* модулей (IPC::SysV, IPC::Msg, IPC::Shareable, IPC::ShareLite, ..). Но вы это знаете что это не проблема, верно?

Если вы пишите для веба, то какая у вас используется БД (это мне даст ответ на 95℅ других вопросов).

В зависимости от характера задачи: от redis до berkleydb, от levdb до oracle. Был даже опыт огранизации «cusom»-решения для хранения данных прямой на файловой системе; tie-интерфейс очень пригодился.

Далее, как вы храните в перле массивы/хэши из миллиона однотипных данных ( скажем массив из 100 млн. чисел)? На каком железе вы запускаете перл? С более 256Гб ОЗУ?

100 млн - это немного. Я думаю вы сами никогда с такими объемами данных дела не имели, поэтому взяли цифру «с потолка».

Попробуйте создать массив из 100 млн. чисел и оценить потребление памяти на 100 млн скаляров. Сегодня браузеры больше памяти потребляют. Вот если вести речь о 100 млрд. СТРУКТУРАХ - это уже другое дело. Столь «тяжелые» случаи решаются с использованием pack, Convert::Binary::C, PDL и, наконец, «прямым» XS. Для обработки и хранения 100 млрд. структур, вероятно, кроме оптимизации Си-структур вам даже придется использовать алгоритмы упаковки/сжатия. Но и это не проблема.

И все же, все ваши вопросы - это уровень решения типовых задач, которые элементарно решаются не только на perl, но даже чистом Си (если вы на самом деле программист). Но «сильная» сторона perl5 вовсе находится «не здесь». И похоже я оказался прав - вам perl5 так и «не открылся».

Perl - это очень мощный инструмент, но удержать в руках этот инструмент дано не каждому. И те кто так и не смог оседлать дикого верблюда уходят на python и php. Вот я только не понимаю, зачем они приходят в темы про perl и начинают мусорить снова и снова?

Многословность не гарантирует понятности кода.

Интересный журнал, но почему-то не могу его читать, пока не скопирую в vim и не сделаю ggVGJ.

Perl хороший яп, только не надо этих высокопарных слов про то, что если не смог удержать блаблабла. Если кепка соображает, то можно любую задачу, которая посильна перлу, реализовать на любом другом вменяемом яп. Вопрос только во времени и целесообразности.

иначе говоря, хотите сказать, что в перле достаточно средств (библиотек и тп) для того, чтобы писать что угодно?

охотно верю, кроме того, думаю, то же самое можно сказать про любой другой состоявшийся неспециализированный (общего назначения) язык

так что, когда спрашивают «чем же хорош?», как мне представляется, интересуются в первую очередь удобством киллер-фичами - какой-то язык хорош для быстрого старта, где-то синтаксис приятный, где-то код лаконичный выходит, где-то библиотек много и тп

чем же хорош перл? работой со строками - несомненно, тут он много кого уделает, поэтому этот пункт и вспомнили первым

может есть ещё что-то, что а перле лучше, чем у остальных? тогда просветите, всем будет интересно

и да, люди ж пишут не только энтерпрайз, иногда надо и что-то маленькое для себя набросать, чтобы облегчить ежедневную рутину, и это тоже оправдывает существования языка, даже если в нем нет набора фичей как у конкурента, зато позволяет свою маленькую задачу сделать легко и непринужденно

Perl хороший яп, только не надо этих высокопарных слов про то, что если не смог удержать блаблабла.

То есть лучше просто говорить о том что этот программист очень слаб и не смог научиться использовать эффективно столь мощный инструмент? Я не претендую на полноту, а мое заявление основано лишь на моем реальном опыте: я повстречал тех кто так и не смог удержать perl, да и среди тех кого повстречали были и те кто владел им довольно посредственно.

Если кепка соображает, то можно любую задачу, которая посильна перлу, реализовать на любом другом вменяемом яп. Вопрос только во времени и целесообразности.

Конечно решить можно, но есть ряд ситуации которые невероятно плохо решаются на Java и C++ (ну и они так же плохо решаются на Python, C#, ..). Кроме того, за годы программирования на perl5 я узнал о новых техниках программирования которые чрезмерно сложно и дорого использовать на других языках (некоторые я уже использую в perl5).

К слову, до perl я работал на Java и С++, и именно из-за невозможности нормального решения ряда задач я начал поиск более совершенного инструмента. Им оказался perl5. Я думаю есть более совершенные языки с той или с иной стороны (академические языки я не рассматривал), но я не нашел «не академический» язык «общего назначения» со столь ярко выраженной гармоничностью мультипарадигменности. Ну а все эти языки Java, ECMAScript, C#, Python, PHP, Ruby уступают моим требованям к ЯП.

В качестве завершения думаю будет уместно процитировать открывок из «Camel Book»:

The Pursuit of Happiness Perl is a language for getting your job done. Of course, if your job is programming, you can get your job done with any “com- plete” computer language, theoretically speaking. But we know from experience that computer languages differ not so much in what they make possible, but in what they make easy. At one extreme, the so-called “fourth generation languages” make it easy to do some things, but nearly impossible to do other things. At the other extreme, so-called “industrial-strength” languages make it equally difficult to do almost everything. Perl is different. In a nutshell, Perl is designed to make the easy jobs easy, without making the hard jobs impossible.

Мне просто повезло: мне попались на глаза эти строки когда я, озадаченный сложностью ситуации, искал более совершенный инструмент. Я очень быстро «впитал» примерно 3/4 книги что называется «на одном дыхании» (справочная часть книги менее интересна, хотя там тоже есть полезная информация).

Ладно, пора завершать эту малополезную дискуссию.

чем же хорош перл? работой со строками - несомненно, тут он много кого уделает, поэтому этот пункт и вспомнили первым

да, это несомненно отлично в perl

может есть ещё что-то, что а перле лучше, чем у остальных? тогда просветите, всем будет интересно

да, perl-многогранен, но то что самое значимое я выше сообщением рассказал в виде отрывка из Camel Book

и да, люди ж пишут не только энтерпрайз, иногда надо и что-то маленькое для себя набросать, чтобы облегчить ежедневную рутину, и это тоже оправдывает существования языка, даже если в нем нет набора фичей как у конкурента, зато позволяет свою маленькую задачу сделать легко и непринужденно

у меня в локальном репозитории (это только мной написанные файлы) всего накопилось 6883 *.pl + *.pm и 247 *.t файлов (много тестов включается в один файл)

у меня в локальном репозитории (это только мной написанные файлы) всего накопилось 6883 *.pl + *.pm и 247 *.t файлов (много тестов включается в один файл)

покажи ради интереса.

уступают моим требованям к ЯП.

эта фраза является ключевой. Каждый выбирает инструмент по возможностям и потребностям. А в коей степени эффективно использовать тот или иной инструмент - это личное дело каждого.

эта фраза является ключевой.

Нет, и вы снова упускаете главную мысль. Я сформулировал такие требования к ЯП что языки Java,C++,Python,Php,.. выпадают за негодностью. Поскольку perl5 удовлетворяет моим требованиям, то он более совершенен, чем те которые выпали.

Каждый выбирает инструмент по возможностям и потребностям.

Cлишком общее заявление ничего не проясняющее. Я, к примеру, знаю того кто выбрал какой язык изучать из-за потребности в деньгах и изучил php. А я, к примеру, выбрал язык конкретно по требованиям к языку.

А в коей степени эффективно использовать тот или иной инструмент - это личное дело каждого.

Я думаю что все желают использовать лучший инструмент наиболее эффективно если бы могли это делать, если только нет явных причин не делать этого (например в академических целях). Но практика показывает что не все способны на это. К примеру, пользователю postman perl5 явно не дался, тогда как мне совершенно не является проблемой разобраться в исходниках модулей из CPAN. Я думаю что эти пользователи просто не встречали масштабные проекты на C++, когда из-за полиморфизма и множественного наследия не так просто разобраться в коде проекта.

Понимаете, в чем дело, уважаемый адекватный аноним. Без пруфов вся ваша писанина воспринимается либо как продукт идейного последователя секты Perl, либо откровения диванного гуру о прописных истинах и тайных знаниях, то есть вообще никак.

Понимаете, в чем дело, уважаемый адекватный аноним. Без пруфов вся ваша писанина воспринимается либо как продукт идейного последователя секты Perl, либо откровения диванного гуру о прописных истинах и тайных знаниях, то есть вообще никак.

Так я вроде и не собирался переубеждать кого-то или доказывать что-то всем: будьте вольны думать как вам угодно и насколько вы способны. Я лишь немного повозмущался что мусорят в треде. Ну а вцелом интересует только узкий круг perl-хакеров которых найти не так просто (нескольких я уже нашел и среди них даже есть одна умная девушка). Ну и конечно, журнал Pragmatic Perl спасает положение. Спасибо авторам статей за труды.

Если я кого-то нечаянно обидел - прошу простить. Честно, я не хотел.

Я сформулировал такие требования к ЯП

И снова мы видим ключевую фразу.

удовлетворяет моим требованиям, то он более совершенен, чем те которые выпали

ВАШЕ решение по выбору ВАМИ инструмента, который ВЫ применяете в СВОЕЙ работе, имеет для МЕНЯ такую же ценность, как решение абстрактного Дяди Вани, который выбрал абстрактный инструмент для какой-то задачи и доволен своим выбором

Я сформулировал такие требования к ЯП что языки Java,C++,Python,Php,.. выпадают за негодностью

Это слишком высокопарно и пафосно. Все основные скриптовые ЯП общего назначения в нынешнее время имеют все ключевые\основные «фичи», которые есть в perl. А все не ключевые быть может и не реализованы т.к они не являются критичными\ключевыми.

Скорей всего, что perl - это для тех, кто прошёл школу asm-->c-->c++-->script_lang_x-->script_lang_y и не найдя функционала в cxx-->x-->y открывают для себя perl как идеальный инструмент разработки. Именно в этом-то и дело, что прийдя через c-->perl or script_lang_x-->perl и даже script_lang_x-->script_lang_y-->perl могут не понять его и сделать роллбэк на x or y или на cxx.

ВАШЕ решение по выбору ВАМИ инструмента, который ВЫ применяете в СВОЕЙ работе, имеет для МЕНЯ такую же ценность, как решение абстрактного Дяди Вани, который выбрал абстрактный инструмент для какой-то задачи и доволен своим выбором

Вот вы снова сводите на «мой/твой». Я вам объяснил 1 раз что сформулировал ряд требовании которые ЯСНО ПОКАЗАЛИ что языки вроде Java,C++,Python,... выпадают за непригодностью. Требования возникли не на пусом месте, а из-за проблем с которыми столкнулся при разработке крупного проекта. То есть поймите, есть ряд задач которые нормально не решаются на этих языках. Дело не в выборе а в том что эти языки хуже чем perl5.

Скорей всего, что perl - это для тех, кто прошёл школу asm-->c-->c++-->script_lang_x-->script_lang_y и не найдя функционала в cxx-->x-->y открывают для себя perl как идеальный инструмент разработки. Именно в этом-то и дело, что прийдя через c-->perl or script_lang_x-->perl и даже script_lang_x-->script_lang_y-->perl могут не понять его и сделать роллбэк на x or y или на cxx.

Не знаю, может и так, но не в моем случае. До perl я довольно сносно программировал на Java и C++. Хотя я и сейчас программирую как них (менее уверенно на С# и Python) так же как и разбираю код на этих языках, но новые проекты я делаю в крайнем случае на С++ лишь аккуратно используя ограниченное подмножество языка. Если есть любая возможность сделать на perl, то я делаю именно на нем, т.к. это наименее рискованно. Perl5 я «проверил» и убедился в том что у меня не будет проблем из-за ограниченности языка, а вот с perl6 похоже не все так радужно..

Я вам объяснил 1 раз что сформулировал ряд требовании которые ЯСНО ПОКАЗАЛИ что языки вроде Java,C++,Python,... выпадают за непригодностью

Да прекратите. Или вы решаете задачи, которые мало у кого появляются или вы не смогли с помощью вышеуказанных яп решить проблему. Иначе, если бы задачи, которые не решаются на других ЯП, окроме Perl'a появлялись массово, то Perl был бы гараздо выше в рейтинге используемых ЯП. Но почему-то он не на тех местах в рейтинге. Вопрос: почему ?

Как по мне, странно сравнивать интерпретируемый ЯП общего назначения(Perl) с CXX. Как минимум, CXX появился не для того, чтобы конкурировать с Perl или подобными ЯП, а для того, чтобы расширить функционал партабельного asm(c) и писать там, где цена решения вопроса не важна, а важна лишь скорость. И он там и применяется. И перлу или любому другому аналогичному ЯП там не место. Поэтому очень странно, что вы в один ряд ставите CXX и Perl и сравниваете их. Это то же самое, что сравнивать корову и страуса. Ага, вот посмотрите, страус какие яйца производит! А я отвечу: а корова молоко приносит. И кто тут из нас прав ? Тот, кто амлеты любит из страусинных яиц - скажет, что страус лучше, а тот, кто творожок любит - корова вне конкуренции. Как-то так.

А по основной теме: Я уверен, что Ruby умеет 90% того, что умеет perl. А того, что не умеет - массам не нужно. Иначе умел бы. %s/Ruby/любой_др_интерпретируемый_яп_общего_назначения/gc

А всё что не умеет, решается бОльшим кол-вом нанятых программистов. По крайней мере у меня создаётся впечатление, что так и происходит под те задачи, там где «дорого решать».

удержать в руках этот инструмент дано не каждому

Ага, Экскалибур прям. Я вижу, что опыт у Вас, ваше величество, есть. И вижу, что он недостаточно полный. Взять тот же DBI::Oracle, вы писали с его помощью многопоточные приложения? Думаю, нет, а стоило бы. Перейду к делу: весь DBI писался в то время, когда не было SMP, и только-только внедрялся. Поэтому единственный вариант работы с любым DBI для РСУБД в перле нормально и быстро работает только в (pre-)fork приложениях. При этом в критических случаях перерасход ОЗУ и ЦП зашкаливает любые альтернативы на Java, C/C++ и даже XS не спасёт. Но что уж говорить, я уже слышу ответ: 128Гб это мелочь нынче.

100 млн - это немного.

Назовите цифру, а я вам скажу сколько это должно весить. Вобщем, я ожидал услышать про Bit::Vector, чтобы продолжить дискуссию. Но раз для вас 1Гб ОЗУ вместо десятка Мб это нормально, то продолжайте болтологию о том, какой перл чудесный в своей уютном мирке.

Ничто не идеально. Многие модули на CPAN решают ряд задач, но также вносят массу других проблем. И да, я вижу, что вы не осилили AnyEvent::Fork::Pool, там всего в двух местах напильником подпилить :)

Ну и на последок. Если перл такой чудесный, то назовите приложения на Perl+Qt, Perl+Gtk2/3, Perl+Tk, Perl+Prima. Думаю их не шибко много лишь потому, что поддержка графических тулкитов (кроме Prima) в перле никакая. Лично я увидел столько багов, что лучше писать сразу на си/плюсах, чем испытать все муки ада.

Да прекратите. Или вы решаете задачи, которые мало у кого появляются или вы не смогли с помощью вышеуказанных яп решить проблему. Иначе, если бы задачи, которые не решаются на других ЯП, окроме Perl'a появлялись массово, то Perl был бы гараздо выше в рейтинге используемых ЯП. Но почему-то он не на тех местах в рейтинге. Вопрос: почему ?

Задача решалась в рамках ЯП если подстроиться под правила худшего ЯП. Я решил задачу другим путем - вместо того чтобы подстраиваться под худший ЯП, я сфокусировался на поиске лучшего инструмента. Обычный программист даже не задумывается о таких вещах - он сразу адаптирует проект под худший ЯП. Некоторые даже не понимают как можно сравнивать ЯП с позиции эффективности решения задач. Обычные программисты максимум что умеют - это сопоставлять на уровне компилируемый1 <=> компилируемый2 или интерпретируемый1 <=> интерпретируемый2. А для более комплесного анализа надо владеть теоретическими основами языков программирования. А в этим, чувствуется, у вас сильные пробелы. Поэтому мне очень неприятно продолжать разговор рассказывая материал уровня студента 1-ого курса.

Вот и вы пишете:

Как по мне, странно сравнивать интерпретируемый ЯП общего назначения(Perl) с CXX. Как минимум, CXX появился не для того, чтобы конкурировать с Perl или подобными ЯП, а для того, чтобы расширить функционал партабельного asm(c) и писать там, где цена решения вопроса не важна, а важна лишь скорость. И он там и применяется. И перлу или любому другому аналогичному ЯП там не место. Поэтому очень странно, что вы в один ряд ставите CXX и Perl и сравниваете их.

Любой ЯП - это лишь знаковая система которая обеспечивает возможность построения сценарии в рамках определенных правил. Интепретируемый или компилируемый - это, вообще говоря, не важно, но важна скорость исполнения сценария. Критерии по которому можно оценить ЯП можно сформулировать не только к скорости, но и к правилам знаковой системы. Вот так можно сравнить АБСОЛЮТНО ВСЕ ЯП, но вы сильно далеки от этого. Продолжать с вами беседу - зря тратить свое время. Напоследок скажу лишь что там где нужна скорость вводится Си-код (FFI). Таким образом мы получаем невероятно гибкое решение с эффективным исполнением который в runtime сопоставим с исполнением C++.

Взять тот же DBI::Oracle, вы писали с его помощью многопоточные приложения? Думаю, нет, а стоило бы. Перейду к делу: весь DBI писался в то время, когда не было SMP, и только-только внедрялся. Поэтому единственный вариант работы с любым DBI для РСУБД в перле нормально и быстро работает только в (pre-)fork приложениях. При этом в критических случаях перерасход ОЗУ и ЦП зашкаливает любые альтернативы на Java, C/C++ и даже XS не спасёт. Но что уж говорить, я уже слышу ответ: 128Гб это мелочь нынче.

Я прочел это как «я не умею эффективно использовать perl» поскольку perl позволяет легко связывать Си-код со всеми вытекающими.

Назовите цифру, а я вам скажу сколько это должно весить. Вобщем, я ожидал услышать про Bit::Vector, чтобы продолжить дискуссию. Но раз для вас 1Гб ОЗУ вместо десятка Мб это нормально, то продолжайте болтологию о том, какой перл чудесный в своей уютном мирке.

А вот очень кстати о болтологии: вы «пацанам» своим рассказывайте о том как у вас сто миллионов чисел занимают в памяти десяток Мб. У нас в реальном мире сто миллионов бит занимают больше. Все таки потрудитесь хотя бы немного рассчитать и оценить потребление памяти perl-процесса.

И да, я вижу, что вы не осилили AnyEvent::Fork::Pool, там всего в двух местах напильником подпилить :)

Было дело, просто не вспомнил сходу. Дело в том что у меня уже есть собственное решение, поэтому в Fork* модулях я не нуждаюсь, поэтому и не вспомнил. Но вы конечно подумали об этом.

Ну и на последок. Если перл такой чудесный, то назовите приложения на Perl+Qt, Perl+Gtk2/3, Perl+Tk, Perl+Prima. Думаю их не шибко много лишь потому, что поддержка графических тулкитов (кроме Prima) в перле никакая. Лично я увидел столько багов, что лучше писать сразу на си/плюсах, чем испытать все муки ада.

Вот попробуйте: http://sourceforge.net/projects/pacmanager Но вы сильно далеко ушли от темы разговора. Я все пытался сказать что правила в рамках которой идет разработка на perl более совершенны чем на обычных языках вроде Java,C++,... Очевидно же что это правило не распространяется на уровень поддежки определенных модулей или библиотек. А вы все смешали в кучу так и не разобравшись даже сколько у вас занимают памяти 100_000_000 чисел.. Это и есть болтология.

Я же говорил что обычные коментаторы лишь впустую отнимают время.

Я смотрю вы теоретик...

$ perl -v

This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
$ perl 1mio.pl 1000000
  RSS    VSZ
33828 161944
$ perl 1mio.pl 10000000
  RSS    VSZ
369816 497872
$ perl 1mio.pl 100000000
Out of memory!
$ uname -a
Linux localhost.localdomain 3.14.17-100.fc19.x86_64 #1 SMP Thu Aug 14 17:17:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
[tvv@localhost ~]$ free -m
             total       used       free     shared    buffers     cached
Mem:          1995        101       1893          0          0          5
-/+ buffers/cache:         95       1899
Swap:          511         54        457

#!/usr/bin/perl

use strict;

my @arry;
my $max = $ARGV[0] || 1_000_000;
my $idx = 0;

while ($idx < $max) {
    $arry[$idx] = $idx;
    $idx++;
}

print `ps -o rss,vsz $$`;

Задача решалась в рамках ЯП если подстроиться под правила худшего ЯП. Я решил задачу другим путем - вместо того чтобы подстраиваться под худший ЯП, я сфокусировался на поиске лучшего инструмента

Если учесть, что Ruby имеет 90+% функционала Perl, то смею предположить, что у вас не было достаточно скилла, чтобы применить Ruby. При этом %s/Ruby/любой_др_интерпретируемый_яп_общего_назначения

Любой ЯП - это лишь знаковая система которая обеспечивает возможность построения сценарии в рамках определенных правил. Интепретируемый или компилируемый - это, вообще говоря, не важно, но важна скорость исполнения сценария

в целом да, но всё же они разделяются на интерпретируемые и компилируемые. И у каждых яп свои приоритеты. И созданы они для того, чтобы решать разного рода задачи. Поэтому не стоит сравнивать цэ и perl, или скажем assembler и perl. Сравнить конечно можно страуса с коровой(в данном случае с верблюдом), вопрос только в том, насколько это уместно. Я вижу, чтобы вознести на пъедестал Perl вы готовы даже на это.

Еще раз: если существует задача, которую можно решить с помощью perl и только с помощью perl(имеется ввиду невозможность решения задачи в целом или стоимость решения задачи крайне высока), то возникает ряд логических вопросов:

1. Если такие задачи есть, то там должен применяться perl.

2. Если таких задач много - значит должно быть много вакансий perl. Если вакансий мало, то: а) либо задач на самом деле не много б) люди решают эти задачи без perl. В любом другом случае вакансий на perl было бы много.

Напоследок скажу лишь что там где нужна скорость вводится Си-код (FFI)

Любой иЯП_он умеет это. И что ? И кЯП умеет запускать скрипты на иЯП_он.

Подытожу: perl нормальный иЯП_он, который имеет столько же недостатков, сколько и приемуществ, как и любой другой иЯП_он. Текущее положение событий в мире IT говорит о том, что люди обходятся и без него т.е кол-во задач, которые можно решить минимальной ценой или очень мало, либо они таки решаются без perl. Иначе, я не могу объяснить причины того, что этот ЯП не на вершине пъедестала.

Я уже рассказал о принципах оценки которые позволяют оценить качество знаковой системы любого ЯП, а вы снова начинаете свои разговоры уровня студента 1 курса. Кроме того, вы очень неаккуратный собеседник: в процессе разговора вы упустили ряд деталей и (явно или нет) допустили несколько искажении обстоятельств, и даже не заметили это. Будьте вольны думать в меру своих способностей. Я не собираюсь вас обучать или переубежать. Не обижайтесь, но вам я больше не отвечу: мне не нравится впустую тратить свое время на людей.

а вы снова начинаете свои разговоры уровня студента 1 курса

Еще раз: вакансий на перл мало. Что это означает ?

1. Кол-во задач, с которые лучше всего решать с помощью перл - мало

2. Задачи, которые лучше решать на перл, решают без перл.

для number-crunching'a в Perl эффективно использовать PDL:

~$ /usr/bin/time -f '%M' perl -MPDL -e 'sequence(long,1e8)'
408928

Если учесть, что Ruby имеет 90+% функционала Perl,

то заколебёшься переписывать с каждой минорной версией свой код. Если конечно это не helloworld.

Я смотрю вы теоретик...

Ну это как посмотреть. С одной стороны, я в какой-то мере владею аналитическим аппаратом теоретических основ ЯП что позволяет мне анализировать и приводить доводы в пользу своей позиции (впротивовес - пользователь bryak старается свести уровень суждения на примитивное бездоказательное утверждение своей позиции). С другой стороны, я увидел демагогию в ваших суждениях.

Что должен ожидать программист? Среднестатистический случай: 100_000_000 * 4 байта ~~ 381МБайт. Итак, какими числами вы оперируете у себя на перле? Миллиардами? Ок, вывод инфы о железке (CPU, RAM) в студию, пожалуйста.

1. Начнем с того что 381 МБайт это не десятки мегабайт. Это к слову о болтовне.

2. Я оперирую ЛЮБЫМ диапазоном чисел и у меня нет проблем с управлением памяти. Я эффективно использую FFI и JIT в perl если этого требует задача. Но такие случаи - большая редкость.

3. К вопросу об эффективности perl: Выполните

$ h2xs -n MyTest; echo -e «\nvoid\ntest()\n\tCODE:\n\t\tprintf(\„SV size:%d\\\n\“,sizeof(SV));» >>MyTest/MyTest.xs

Соберите XS-модуль и выполните perl -MMyTest -E'MyTest::test()'

Выполните на 32- и на 64-битной платформах. Это я к тому что если вы хоть раз писали на XS вы бы знали разницу между потреблением памяти числа и скаляра. Тем не менее, perl дает в скаляре оперировать числом большим чем 2**32 даже на 32-битной платформе. Поэтому сравнивать 4-байта и скаляр немного некорректно. С позиции размерности корректнее говорить на 64-платформе и тогда мы увидим что скаляр потребляет ровно в три раза больше памяти. Сто миллионов чисел на 64-битах это уже ~762 Mb. Скаляр будет занимать минимум в три раза больше места.

Поэтому выполнив ваш код я получаю ожидаемые цифры*:

perl test1.pl 100000000 RSS VSZ 3212308 3228776

*еще раз напомню что корректно будет сравнить с ~762Mb на 100млн 64-битных чисел

А вы смотите что пишете:

При этом в критических случаях перерасход ОЗУ и ЦП зашкаливает любые альтернативы на Java, C/C++ и даже XS не спасёт. Но что уж говорить, я уже слышу ответ: 128Гб это мелочь нынче.

Демагогия..

//Продолжение в следующем сообщении.

Продолжение.

4. К вопросу об управлении памятью. Вообще говоря perl нет понятия, число хранится в скаляре и все операции в perl идут над скаляром. Очевидно что если мы избавимся от скаляра то потеряем все преимущества perl. С другой стороны, стоит задача - приблизиться по объему потребления памяти для хранения 100млн. чисел на заявленные в Си ~381 Mb (4 байта на число, с 8-ми байтовыми числами все делается по аналогии). Я покажу вариант решения задачи (а их множество) и тем самым докажу то что gh0stwizard не умеет эффективно использовать perl и утверждение «не каждому дано удержать в руках столь мощный инструмент perl» обретет силу.

Система:

$perl --version

This is perl 5, version 20, subversion 0 (v5.20.0) built for x86_64-linux

Код

#!perl -w

use strict;
package INT2STR;
use Config;

my @heap;
my $sz = ${Config::Config}{intsize};

sub TIEARRAY{
    my $size  = $_[1] || 100_000_000;

    return bless [
	(-1 + push @heap, "\x00" x ($size*$sz)),
	$size,
    ];
}

sub FETCHSIZE { $_[0]->[1] }
sub STORE     { substr($heap[ $_[0]->[0] ], $_[1]*$sz, $sz, pack 'i', $_[2]) }
sub FETCH     { unpack 'i', substr( $heap[ $_[0]->[0] ], $_[1] * $sz) }
sub DESTROY   { undef $heap[ $_[0]->[0] ] }

package main;
tie my @arr, 'INT2STR';
print $arr[100_000_000] = 2**32-1;

print `ps -o rss,vsz $$`;

<STDIN>;

Результат

$ perl test.pl

-1 RSS VSZ

393044 409276

Работаем в диапазоне 32-битных чисел с потеблением памяти сопоставимым на уровне Си и при этом не теряем мощь perl за счет того что мы сохранили число под скаляром.

Это все в рамках «базовых» свойств языка. А есть еще более «красивые» техники использования рассказывать о которых пользователям уровня gh0stwizard и bryak не вижу никакой смысл: сплошная демагогия и явное неумение пользоваться мощным инструментом.

Если перл такой чудесный, то назовите приложения на Perl+Qt, Perl+Gtk2/3, Perl+Tk, Perl+Prima.

Padre :)

-->> -->> А если сайт не особо стандарт HTML5 соблюдает, то что? Всё встанет?

-->> Не встанет. Построится дерево не совсем корректное (но вполне достаточное для его обхода и поиска нужных ветвей)

Уверены, что всё построится и часть не потеряет? и как оно будет обрабатывать такое:

<p>a<div>b</p>c</div>

а более серьезный бардак?

-->> Еще раз: вакансий на перл мало. Что это означает ?

-->> 1. Кол-во задач, с которые лучше всего решать с помощью перл - мало

-->> 2. Задачи, которые лучше решать на перл, решают без перл.

т.е. если вакансий на PHP много из этого следует что?

количество задач, которые следует решать только через PHP - много? это задачи, которые невозможно решить без PHP? Отнюдь.

Это лишь значит, что есть популярность определенного инструмента и его везде пихают. И это совершенно не значит, что это действительно лучшее решение.

Любую задачу в принципе можно решить разными инструментами. И выбор инструмента - это процесс весьма субъективный. И не стоит делать из субъективного процесса какие-то серьезные технологически выводы.

Просто большинство людей, пришедших в этот тред, или никогда не пользовались перлом, или попробовали, но не смогли понять, как его применять. Поэтому ты прав. Никого здесь убеждать не надо. Или ты используешь удобный инструмент в своих нуждах(как я использую perl), или ты пишешь на другом языке и вступаешь в споры по поводу отдельных моментов своего языка. В этом треде, как и во многих других, я вижу толпы человеков, пропагандирующих питон, смерть перла, великие языки будущего и прочие мифы и легенды. Но я как писал на перле, так и пишу. Как читал pragmatic perl, так и читаю. И я смотрю на этот тред и не могу понять, зачем здесь все эти люди? Ведь они всегда одни и те же(по сознанию), они всегда кричат о смерти/нечитабельности/ущербности/нелогичности перла, но сколько бы их не было, перл есть и он работает.

Ребята-недоброжелатели, вам такого же иммунитета, как у перла к вам.

Всегда любил сферических манагеров в вакууме, которые оценивают технологии по опросам. Вот только я не программист и мне не нужен ruby или s/ruby/любой язык прогаммиования/g. Мне нужен язык, который решит мою проблему быстро и стопроцентно. Я один такой знаю. Его не нужно изучать, он поддерживает простую и удобную модульность, у него гора готовых модулей на любой чих и любой из них я могу понять и если что подправить, если базовый функционал не устроит. Разве это не идеальный инструмент для работы? И работы лично моей, а не толпы каких-то левых погромистов, за которых мне нередко приходится писать патчи и перепиливать тысячи строк исходников, чтобы запустить их код на серваке?

Ты опять забываешь, что в отличие от кучи всяких новомодных языков перл - это инструмент. Это как гаечный ключ или плоскогубцы. Ни одному слесарю/монтажнику/электрику/etc не платят за владение этим инструментом. Но ни один из них не нужен, если этого инструмента не понимает. Во всяком случае я в своё время отправил «админов», не знавших перл искать работу дальше.

Если перл такой чудесный, то назовите приложения на Perl+Qt, Perl+Gtk2/3, Perl+Tk, Perl+Prima.

Дай название своего дистрибутива и список используемых программ.

Родной вернитесь! Ваш код работает очень хорошо, но я нифига не понял.

Я убогий кодер на C/C++, но нежно люблю perl.

Что значит:

return bless

Вы возвращаете инстанс класса? А я, глупый, всегда делал отдельный file.pm

А как эти господа пристегнуты к делу: sub FETCHSIZE

sub STORE

sub FETCH

sub DESTROY

это что, переопределение методов класса INT2STR?

И куда читать чтоб это познать? Не видел таких штук как return bless в учебниках.

куда читать чтоб это познать?

• perldoc -f package
• perldoc -f bless
• perldoc -f tie
• perldoc perlmod
• perldoc perltie

Спасибо Вам дорогой друг. Просматривал эти документы(perl хобби, не работа), но ни один из них не объясняет/советуте return bless. Даже гугл молчит.

perldoc -f bless

• bless REF,CLASSNAME
• bless REF
  This function tells the thingy referenced by REF that it is now an object in the CLASSNAME package. If CLASSNAME is omitted, the current package is used. Because a bless is often the last thing in a constructor, it returns the reference for convenience..

т.е. по сути вопроса: да, в приведенном выше коде, «TIEARRAY» возвращает объект класса «INT2STR»

Уверены, что всё построится и часть не потеряет? и как оно
будет обрабатывать такое:

<p>a<div>b</p>c</div>

думаю что если браузер примерно нормально показывает кривой HTML-код, то и распарсится он примерно правильно.

(а если HTML-код настолько кривой что даже браузер его не показывает — то значит вотздесь я уже не уверен за парсинговые модули))

вот твой пример — результат следующий:

[regular-user@localhost html-example]$ pyvenv venv
[regular-user@localhost html-example]$ . venv/bin/activate
(venv) [regular-user@localhost html-example]$ pip install html5lib
Downloading/unpacking html5lib
  Downloading html5lib-0.999.tar.gz (885kB): 885kB downloaded
  Running setup.py (path:/home/regular-user/Desktop/html-example/venv/build/html5lib/setup.py) egg_info for package html5lib
    
Downloading/unpacking six (from html5lib)
  Downloading six-1.9.0-py2.py3-none-any.whl
Installing collected packages: html5lib, six
  Running setup.py install for html5lib
    
Successfully installed html5lib six
Cleaning up...
(venv) [regular-user@localhost html-example]$ python
Python 3.4.2 (default, Oct  8 2014, 13:44:52) 
[GCC 4.9.1 20140903 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import html5lib
>>> tree = html5lib.parse('<p>a<div>b</p>c</div>')
>>> type(tree)
<class 'xml.etree.ElementTree.Element'>
>>> import xml.etree.ElementTree as ET
>>> ET.dump(tree)
<html:html xmlns:html="http://www.w3.org/1999/xhtml"><html:head /><html:body><html:p>a</html:p><html:div>b<html:p />c</html:div></html:body></html:html>