LINUX.ORG.RU

Чего мне не хватает в Perl?

 ,


1

12

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

Итак, претензии к Perl от человека, который его осилил и знает особенности языка не по наслышке:

1) Не хватает собственно скорости. Скорость исполнения кода, т.е. его непосредственной интерпретации - Ахиллесова пята не только Perl, но и Ruby, и Python, и PHP. Но если интерпретаторы PHP и Python становятся быстрее с каждым годом, то интерпретатор Perl застрял в своём развитии - и при этом язык не имеет LLVM-компиляторов, как тот же Crystal, реализующий очень быстрый диалект Ruby. Для Perl есть RPerl, который непонятно как работает и работает ли у кого-то, кроме самого Вина Бразвелла. Ну и да, RPerl - это всё-таки не вполне Perl, по сути это какой-то «perl'оподобный диалект языка Си»

2) Не хватает адекватной проверки входных параметров. Есть куча сторонних модулей для этого: MooseX::Method::Signatures, Params::Validate и ещё тысячи их, но все они добавляют дикий оверхед к и без того не быстрой работе интерпретатора

3) Отсутствует как класс нормальный параллелизм: без пула потоков работать с потоками невозможно (создание потока - крайне медленная операция), с пулом потоков в принципе удобно, но всё одно памяти они жрут как не в себя. На Perl в 100 раз всё лучше с процессами, в том числе есть неплохие модули для работы с shared memory (правда, Redis для того же самого намного удобнее).

4) CPAN конечно замечательный репозиторий пакетов, но выкладывать что-то туда - это лишняя трата времени, да и все эти инструкции по правильному выкладыванию немного бесят: мне что, заняться больше нечем? ИМХО подход того же Crystal'а с его shards'ами намного удобнее.

5) Отсутствие макрогенерации кода. Есть конечно eval, но это, мягко говоря, всё равно что бульдозером шпалы укладывать: неудобно, анахронично, работает в рантайме (что просто ппц на самом деле), чревато ошибками. Учитывая стоимость вызова процедур в Perl5 отсутствие макрогенерации негативно влияет на потенциальную производительность

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

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 2)

Скока строк в проектах? Если бы ушел с него, то куда?

anonymous
()

1) Скорости мне хватает почти всегда. Были случаи когда переключался на XS-версию модуля или выворачивал наизнанку код тяжелого модуля (писал оператор для постгреса на перле). С тем что развитие интерпретатора застряло согласен.

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

3) Хватает того что есть, но и задачи простые - обычно хватает пула процессов, внутри которых бегают воркеры.

4) Cpan помойка из мертвых модулей. Часть модулей без тестов и документации, с необоснованно тяжеленными зависимости (в виде Moose, например), русский и китайский в комментариях доставляют. Модули выкладываю, поддерживаю, с этим проблем нет, разве что перед деплоем гоняю тесты в TravisCI, чтобы cpan-testers не напрягать и для быстрого фидбека.

5) Да, это беда. Тут и комментировать нечего.

6) Мало интроспекции (лукс лайк намбер, пацанчики), строгости типизации, нет средств разработки эквивалентных PyCharm.

7) Нет работы: вакансий, нормальных проектов, достойных зарплат и условий труда. Есть горы говнокода, написанного «пишу на языке давно и успешно».

outtaspace ★★★
()

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

quester ★★
()
Ответ на: комментарий от outtaspace

То, что нет работы - во-первых не совсем правда: перловиков уже нанятых очень и очень дохрена. Проблема в том, что они прочно сидят и никуда не уходят. Хотя вот буквально в этом году был на собеседовании в Рамблере - вполне себе контора, где для LiveJournal'а perl+go во все поля.

Но честно говоря новые веб-проекты я бы уже делал на Crystal: от Python'а у меня реально рвотный рефлекс, да и смысл-то менять тёплое на мягкое (интерпретатор и там, и там, так в Python ещё и треды липовые по сути из-за GIL), а вот Ruby мне нравится куда больше, и существование под него быстрого интерпретатора - огромный плюс. Вот только, гм, Crystal тоже что-то стагнирует.

Самый спокойный путь разработчика - это писать на Java и забыть, что существует нечто более другое. Но вот не нравится мне Java, что делать :)

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

перловиков уже нанятых очень и очень дохрена

Очень мало если сравнивать с питонами/похапе/джавами.

они прочно сидят и никуда не уходят

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

outtaspace ★★★
()

Не смог пройти мимо).

Из объективных минусов перл'а:

1. Скорость интерпретатора - проблема большенства скриптовых языков с динамической типизацией. Скорость исполнения будет +- одна и таже: и у Perl 5.26, и y Python3 и у Ruby и даже у Lua (хотя он чутка быстрее из за компактности и минималистичности самого себя), и у PHP.

2. Вытекает из первого пункта - динамическая типизация: «проверяй нахрен сам, интерпретер тебе ничего не обязан».

3. С тредами беда - это да. И воядли когда-то станет луше. Форки пока наше все.

4. Metacpan хорошая соц.сеть для разрабов, cpan - не плохая инфраструктура дистрибьюции модулей. Но, архаичная немного это да. Но про кучу заброшенных/давно не обновляемых модулей дело обстоит так. Популярные модули, те, что у всех на слуху - обновляются регулярно, качество кода и документации - нормальное.

Про Mose и всякие сраные потуги сделать ООП-сахарок - идут лесом, ибо нахрен не нужны. Cтандартные ОПП-средства просты и хороши. По крайней мере мне их хватает полностью.

5. Макросы и динамические языки - ну-ну. Прекращайте мечтать.

6. Про IDE для перла. А оно, как правило, и не надо. Хотя это больше из-за сложностей парсинга перлового кода:). Обычный текстовый редактор, который умеет «perl -c» и perlcritic + perltidy - все, что нужно разработчику. Emacs это умеет отлично. Пользуюсь давно, всем доволен, рекомендую.

7. Про вакансии - да не густо. Но они есть. В основном в крупных города и крупных компаниях, у которых много perl-наследия.

Новый проект на perl'e стоит начинать только когда готов заботиться об инфраструктуре (perl[tidy|critic], pod, всевозможные девопс-штуки, скрипты развертки, сцениарии для docker-контейнеров, и проч.) также маньиокально, как и о коде. Когда скорость выполнениия не критична, когда от твоего кода не зависят напрямую жизни людей :)). В противном случае код очень быстро превратиться в трудно поддерживаемое дерьмо. Так что небольшой микросервис - можно.

Развесистую, сложную систему - Perl не советую (расно как и люьой другой скриптовый язычок). Лучше построить ифнраструктуру с использованием ЯП со строгой типизацией (это позволит сэкономить лишние пулевые отверстия на ногах): Java/Scala/Kotlin (что там еще живет в JVM?), GO, Расты, Плюсы.

anonymous
()

Это всё относится к Perl 5, но ведь Perl 6 уже есть.

Хотя мне Tcl норм. И там вроде этих недостатков нет.

Xenius ★★★★★
()
Ответ на: комментарий от Xenius

Perl6 - мало того, что вообще другой язык, куда более похожий на TypeScript, чем на Perl, так он ещё и медленнее Perl5, а его пакетная база на фоне CPAN выглядит примерно как муравей на фоне слона. Ну т.е. что-то есть, но масштабы просто несопоставимые.

DRVTiny ★★★★★
() автор топика

1) Не хватает собственно скорости.

А ведь когда-то перл был самым быстрым из мейнстримных интерпретаторов, всего лишь в полтора раза медленнее С, до него даже джаваскрипт с трудом достреливал на одинаковых задачах. Что случилось с ним?

E ★★★
()

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

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

Отсутствие макрогенерации кода. Есть конечно eval

Еще фильтры есть

работает в рантайме (что просто ппц на самом деле)

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

annulen ★★★★★
()

1. Для своих задач нормально. Это не си, но и писать сильно легче. Опыт показывает, что проще чем с другими скриптовыми языками. Perl легко и быстро позволяет писать и поддерживать код(да-да, сейчас прибегут толпы кричащих о нечитабельности, сразу предлагаю пройти им мимо, так они во-первых, не поддерживали в своей жизни ни одного проекта больше хелловорда, во-вторых не видели ни строчки кода на перле, кроме известного однострочника, выглядящего одинаково на всех ЯП).

В холиварах под пиво с товарищами я числодробилку с перебиранием кучи данных из файлов сделал быстрее, чем они на руби, питоне и яве. Как ни странно, по циферкам в тот раз победил нас всех пхп-программер в абсолютных числах(итоговое выполнение скрипта), но сделал он это за счёт алгоритма расчёта. Мой был тупее, файлы я перемалывал быстрее. Да, не показатель. Как и любое сравнение языков, имхо.

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

3. Форки. Есть разной степени удобства модули для управления ими, хотя в простых ситуациях и самому написать можно за полчаса. Но, да. С тредами всё плохо. Правда, где в простых интерпретируемых языках с этим хорошо?

4. Ничего тут не скажу. Меня устраивает. Если нет, складываю в ./lib/, допиливаю и подключаю через FindBin. Патчи почти не отсылаю, потому как или работает, или проект заброшен, а я сам сейчас не готов взяться за поддержку. Возможно, потом что-то и возьму.

5. А где оно хорошо? В перле можно это заменить хешами и ссылками на функции в большинстве случаев. В крайнем случае nostrict refs подключить(хотя это я не люблю делать).

Встроенного ООП более чем хватает.

В коментах про IDE сказали. Я использую vim с парочкой плагинов и уже упомянутые perl{tidy|critic}. Хватает с головой.

Про вакансии. Меня из провинции позвали на сеньёра по перлу(правда особо важны были навыки администрирования linux/unix/bsd помимо программирования). Сам не искал в том момент работу.

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

Я намеренно только про интерпретируемые языки говорю. Тут упомянули яву и там есть совсем другие проблемы, связанные больше с инфраструктурой(как мигрировать кучи легаси ява-кода с систем десятилетней давности до сих пор ещё не решили).

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 2)
Ответ на: комментарий от E

Интерпретатор Perl5 обрастал функционалом как снежный ком: функционал довольно пустой, но вес снежного кома увеличивал, и весьма серьёзно. Самое плохое - это даже не сам вес, а то, что рефакторинг кода этого интерпретатора даже сами отцы-основатели Perl'а делать ни в коем случае не станут, потому что здесь именно тот самый случай, когда либо бросить всё и переписать с чистого листа, либо оставить как есть. Вот по сути Perl5 пришёл к последнему варианту: громоздкий и неповоротливый интерпретатор стагнирует, а разработчкики по сути умывают руки, призывая писать XS, если уж очень надо быстрее. Изредка кто-то лезет глубоко в потроха - и тогда на свет появляются шедевры вроде «вычислений, которые ускорились на 25%». Но в целом это всё из разряда припарок. При современных объёмах требовательность интерпретатора к памяти и не очень быстрая его работа (при действительно фантастическом функционале, с чем никто не спорит) всё это приводит к чудесам вроде «кластерной» системы мониторинга PandoraFMS: она написана на Perl с активным использованием ithreads'ов - и официальное ограничение количества узлов на одну ноду там что-то 2500 штук, больше никак.

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)

3) Отсутствует как класс нормальный параллелизм: без пула потоков работать с потоками невозможно (создание потока - крайне медленная операция)

А Coro? С use threads не рекомендуют работать даже сами разработчики

anonymous
()

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

Очень удобно создавать и выкладывать модули с помощью Minilla

там всего несколько комманд и готово =)

ilux
()
Ответ на: комментарий от shell-script

У perl5, кстати, есть надежда на лучшее в виде cperl: он действительно ощутимо быстрее дефолта, и сами идеи в него здравые заложены. Но вот CBOR::XS с ним что-то не заводится...

DRVTiny ★★★★★
() автор топика

1) Зависит от задачи. Мне её и в С++ иногда не хватает. Для «нормального» веба или админства — вполне нормально.

2) Я так понимаю, речь о некоторых констрейнтах, чтобы они работали на уровне интерпретатора. Да, было бы полезно, но, в целом, не смертельно и без них. Попытка внести типизацию существующими средствами добавляет оверхед, бесспорно. Ошибки, связанные с несоответсвием типов, по статистике, не превышают 2% от числа возможных ошибок. Статистика команды разработчиков амазона. Вобщем, польза есть, но в безусловный профит она не превращается.

3) Тредов нет, есть процессы и кооперативные треды через коро. Было бы, конечно, лучше, если б они были, но выкручиваемся же как-то...

4) Выложить что-то на цпан нет проблемы вообще. Один раз написать мейкфайл, прописать версии, сделать дист и зааплоадить. Впоследстивии просто менять номера версий в мейкфайле и модуле и аплоадить. Всех дел меньше 1 минуты.

5) Да, макрогенерация была бы очень кстати. Ей, правда, в любом случае пришлось бы работать в рантайме. Пока что приходится обходиться фильтрами сорцов, когда что-то подобное необходимо и без него никак.

6) Интроспекции вполне хватает, надо сказать. Есть масса инструментов чтобы узнать что на стеке, что в переменной, что сколько места занимает и пр.

7) IDE для перла (из бесплатных) я знаю две: Eclipse+EPIC и IntelliJ IDEA (комьюнити эдишен) + Camelcade. Остальное больше просто «редакторы с подсветкой синтаксиса».

8) С вакансиями не просто, да... С одной стороны очень трудно найти хорошего перл-разработчика, с другой, очень трудно найти работу, где нужны перл-разработчики. Тут есть явная проблема коммуникации.

9) Если внимательно смотреть за перл-дельта и делать самостоятельные бенчмарки, то надо сказать, развитие в перл5 ещё не прекратилось. Глобальных прыжков нет, но локальные вполне чувствуются. На 5.27 (текущий дев) есть прямо заметное ускорение. Я написал свой бенчмарк https://gist.github.com/jef-sure/adcc2fbe9f498477d18d545eb8ffab7f — на основе быстродействия DBIC для разных версий перла я смотрю на комплексное изменение быстродействия различных подсистем перла разных версий.

Casus ★★★★★
()
Ответ на: комментарий от DRVTiny

Никакого ускорения от cperl я не заметил. Вообще. Вот потребление памяти не смотрел, но быстродействие у cperl в моём DBIC тесте просто никак не выглядело лучше, чем у обычного перла, кроме того, что более свежие перлы были быстрее.

Casus ★★★★★
()
Ответ на: комментарий от DRVTiny

рефакторинг кода этого интерпретатора даже сами отцы-основатели Perl'а делать ни в коем случае не станут,

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

громоздкий и неповоротливый интерпретатор стагнирует

Незадолго то релиза очередной версии, как правило, на каких-либо YAPC проходят доклады какие новые возможности ждать в новой версии. Бывает интересно.

на Perl с активным использованием ithreads'ов

ОМГ, это никогда не было стабильным, а в 5.20 было объявлено deprecated, насколько я помню. Тут вопрос к разработчикам/архитекторам, как они умудрились так вляпаться...

Casus ★★★★★
()
Ответ на: комментарий от Casus

Ошибки, связанные с несоответсвием типов, по статистике, не превышают 2% от числа возможных ошибок.

Я знаю об этом, и меня тоже удивляет, почему вся индустрия разработки так помешана на проверке типов, словно всё остальное работает просто идеально (особенно usability приложений, если они не дай Б-г должны как-либо общаться с пользователем).

Вопрос сугубо о том, что на вход приложения извне намеренно или чисто случайно могут прийти совсем не те данные, которые оно, приложение, может и должно обрабатывать. Условно: в рамках API в поле JSON'а вам прислали «Войну и мир» вместо булевой переменной. А вы пока осознали, что something went wrong - уже даже успели эту переменную пару раз скопировать, использовать как «флажок». Или вам прислали температуру по Цельсию даже ниже -273 градусов, и вы её честно попытались установить.

Проблема Perl'а в том, что все декларативные проверки для очистки taints-переменных (переменных, приезжающих извне и по умолчанию содержащих неведомый f*ng shit, пока не доказано обратное) - даются очень дорого. Хотелось бы для таких вещей хотя бы частично реализацию в коде самого интерпретатора или сторонних XS-модулей.

При этом заметьте, что если собственно забыть о taints'е, а все о нём и забывают как раз, то нет адекватных средств проверить на входе в функцию - а надо ли вообще чекать параметры или нет. А это приводит уже к полному кошмару, когда вызывается цепочка функций, в каждой из которых переменную так или иначе на что-нибудь тестируют. Или к ещё худшему кошмару, когда не тестируют нигде, и оно работает ровно до первой бажной системы на другой стороне обмена или до первого скриптикидиса (они нынче чаще не живые люди, кстати, а вполне себе AI).

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

Perl5 предлагает слабую альтернативу в виде очистки переменных (можно хотя бы один раз их проверять, а не бесконечное количество раз). Но кто вообще об этом помнит и кто этим пользуется?

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от Casus

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

Безусловно. Просто интерпретатор генерировал бы код для себя на основе макроопределений, а потом запускал сгенерированное.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

В ruby тоже GIL. И для python есть pypy.

Но это надуманная проблема. Сетевой код в моде асинхронный код, да и есть удобные способы использовать процессы. Писать многопоточные числодробилки на истерпретируемом языке как-то странно. Модулям на си/cython на gil не проблема.

Так что это просто вкусовщина.

pawnhearts ★★★★★
()
Ответ на: комментарий от anonymous

динамическая типизация: «проверяй нахрен сам

Есть аннотации типов, ide и всякие mypy могут проверять за тебя, если их укажешь.

А оно, как правило, и не надо
Интроспекции вполне хватает,

Надо.

pawnhearts ★★★★★
()
Последнее исправление: pawnhearts (всего исправлений: 1)
Ответ на: комментарий от pawnhearts

Какие числодробилки? Просто акцептить клиента на сокете и обслуживать его в отдельном потоке - это числа дробить?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от pawnhearts

Есть аннотации типов, ide и всякие mypy могут проверять за тебя, если их укажешь.

Ещё раз повторюсь: проблема с головотяпством разработчиков - это организационная проблема, которую пытаются решать техническими методами в силу того, что никаких иных не знают. А вот проблема работы с внешними данными - это действительно вполне себе проблема. Особенно на фоне всяких чудес типа docker, которые позволяют сколь угодно долго работать свеженькому приложению в давно протухшем с точки зрения безопасности окружении. Не проверил данные, засунул из в ssl-сокет - а там, внезапно, оказалось, что именно при таком payload'е в пару гигабайт переполняется буфер или некрасиво течёт память. Пустячок - а неприятно, однако.

Всё это на perl'е в большинстве случаев «решается» тысячей проверок одного и того же прогоном через регулярные выражения. Ну и как оно после этого должно работать?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

В такой ситуации задача завязана на IO и GIL не проблема. Но делать по треду на клиента? Асинхронный код лучше, благо есть асинхронные же дрова для бд и даже orm. Эффективней и можно больше клиентов обслуживать. Например

Треды это про вычисления и пляски с локами.

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

В ruby тоже GIL.

У ruby есть Crystal. Больше мне ничего о Ruby знать не хочется, хотя мне и нравится этот язык (и даже книжку «Путь Ruby» читаю с удовольствием, тем паче, что там много весьма универсальных вещей объясняется).

Python - есть люди, несовместимые с ним. Я, например. Т.е. есть у него PyPy или нет - глубоко плевать, сам язык омерзителен, и связываться с ним после perl'а - вообще не в радость.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от pawnhearts

В частности про такие «вычисления» как замена обхода полностью большой структуры данных на дробление структуры на N частей и обход каждой части в отдельном потоке. Для этого не нужны никакие локи, накладные расходы абсолютно минимальны (лишние переключения контекста), но... это только если не копировать целиком весь perl в каждый поток.

А вообще идея, реализованная в инфраструктуре MCE (http://search.cpan.org/~marioroy/MCE-1.832/lib/MCE.pod) мне очень нравится, вот только по-хорошему это не должно на процессах-то работать!

Ну и да, MCE с AnyEvent'ом совсем не дружит, убеждался в этом неоднократно.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от pawnhearts

Немного офтопик, но есть у меня вопрос по IO-асинхронщине, который я пока не видел, чтобы кто-то задавал хотя по мне он прямо на поверхности лежит: а ничего, что данные, запрошенные у того или иного устройства, будут считаны приложением далеко не сразу, а тогда, когда дойдёт очередь до соотв. обработчика? Ну т.е., положим, в не вполне корректно написанном приложении один поток/обработчик взял данные с диска и начал этак неспеша их перемалывать, а тем временем где-то уже давным давно пришли данные от сетевого устройства, но обработать их некому... Не приводит ли это к тому, что на задержки самих IO-устройств как-то неожиданно накладываются задержки, связанные с выстраиванием в цепочку async-обработчиков? И если раньше мы видели в общем-то реальную IO-задержку, то сейчас это может быть запросто вообще всё, что угодно...

Я понимаю, что и в случае параллельной обработки тоже данные читаются тоже в порядке приоритета, но там хотя бы сама ОС передаёт процессу управление тогда, когда его можно разблокировать по вводу-выводу - и это в рамках вытесняющей многозадачности (ОС никого не ждёт, просто переключает при следующем «тике» прерывания таймера).

А вот тормозящий всех IO-поток в рамках конкурентной модели - никто не «пнёт»....

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 2)
Ответ на: комментарий от DRVTiny

Ну в питоне есть такое из коробки. Например:

from multiprocessing import Pool

def f(x):
    return x*x

if __name__ == '__main__':
    p = Pool(5)
    print(p.map(f, [1, 2, 3, 4, 5, 6, 7]))

Создаст пул из 5-и процессов, в которых выполнит вычисления и соберет результаты в список. Для общения между такими процессами есть высокоуровневые механизмы типа очередей и пайпов и просто расшаренные объекты. Типа

from multiprocessing import Process, Value, Array, Queue

def f(q, n, a):
    q.put([42, None, 'hello'])
    n.value = 3.1415927
    for i in range(len(a)):
        a[i] = -a[i]

if __name__ == '__main__':
    q = Queue()
    num = Value('d', 0.0)
    arr = Array('i', range(10))

    p = Process(target=f, args=(q, num, arr))
    p.start()
    p.join()

    print q.get()
    print num.value
    print arr[:]
pawnhearts ★★★★★
()
Ответ на: комментарий от DRVTiny

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

pawnhearts ★★★★★
()
Ответ на: комментарий от DRVTiny

Условно: в рамках API в поле JSON'а вам прислали «Войну и мир» вместо булевой переменной.

У нас так: все, что пришло извне, не имеет типа в терминах принимающего приложения.Те, кто думает иначе, идут искать работу в другое место.

level1 ★★
()
Ответ на: комментарий от level1

Можно как-то пояснить эту безусловно умную мысль? Например, как и куда вы бы засунули эту нетиповую переменную в случае компилируемого языка? Так бы и таскали в строке?

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

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

обрастал функционалом как снежный ком

Имхо, идея доращивания его до языка общего назначения и привела к губящему теперь ожирению. Останься он в нише обработки текста и, возможно, некоторой вебни — не удалось бы так разжиреть. Но блин когда пишешь на перле, всё хочется писать на перле, ибо получается прям простыми английскими словами говоришь, что делать — и делается. Отсюда и снежный ком: вот это надо, а за ним вот это подтянулось... И да, рефакторить там уже, видимо, сложнее чем новый язык, а новый опять получается перлшесть, красивая неповоротливая гусеничка.
Оффтоп: DRV, как тебе удаётся создавать темы про перл без единого удалённого, без тыщи кричателей «однострочнеграйтонлиололо»? Делись рецептом или выложи на CPAN)))

massimus ★★★
()
Ответ на: комментарий от DRVTiny

как и куда вы бы засунули эту нетиповую переменную

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

level1 ★★
()
Ответ на: комментарий от level1

Спасибо, Капитан, да Вы меня прямо спасли в трудной ситуации!

Вот к чему было это всё? И что вы делаете в треде про Perl???

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от massimus

Сейчас большинство людей, знающих perl - не пишут на нём. Но это люди, которым нравится perl, и они просто были вынуждены уйти на всякие питоны и прочее go.

Это намного лучше ситуации 2007-2009-го годов, когда из perl'овиков уходили люди, озлобленные на язык за то, что он «слишком язык»: т.е. как только нужно было отойти от простых руководств «как наваять cgi-скриптец» - оказывалось, что perl - это целая идеология с довольно сильным уклоном в компьютерную филологию. Тогда perl был языком для быстрых скриптеров, сейчас это язык для тех, кто просто любит perl, любит выразительные языки и любит свободу творчества и самовыражения.

Поэтому не так просто найти чудаков которые свалили с перла на питон, поскольку питон выглядит и читается проще.

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

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Вот к чему было это всё? И что вы делаете в треде про Perl???

А к чему в треде про перл вы задаете вопросы про хранение байтов в компилируемых языках? Или какой ответ вы хотели услышать на свой заковыристый вопрос?

У вас вторым пуктом про разбор параметров. А дальше:

Условно: в рамках API в поле JSON'а вам прислали «Войну и мир» вместо булевой переменной. А вы пока осознали, что something went wrong - уже даже успели эту переменную пару раз скопировать, использовать как «флажок»

Вот не может быть такой ситуации в нормальном коде, хоть он дерись. И значит, да, надо перобразовывать в типы приложения через XS, разбор в классе, отдельный сервис или еще как. Но не надо приводить подобных примеров, они вас характеризуют не с лучшей стороны.

level1 ★★
()
Ответ на: комментарий от level1

Надеюсь, вы хотя бы сами понимаете, что пишете.

Типы приложения через XS - это особенно сильно. Какие там типы у приложения на Perl?

И вообще не попробуете ли изъясняться чуть конкретнее дельфийского оракула?

Пришли вам данные в JSON-формате, вы их распарсили тем же JSON::XS и положили в переменную $x. Что дальше? :)

Или предлагаете парсер JSON'а писать заодно, свой на XS? Чтоб секурно было?

Я бы просто ограничил размер посылки, исходя из суммы максимально разрешённых размеров полей. Потом распарсил бы и проверил значения в полях на соответствие неким правилам - и вот на этом чудесном этапе как раз получил бы некую проблему: нужно либо самому писать все возможные варианты проверок и вводить сбоку «типы данных», либо пользоваться готовыми вариантами от сторонниъх разработчиков типа Params::Validate

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

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от level1

Условно: в рамках API в поле JSON'а вам прислали «Войну и мир» вместо булевой переменной.

Вас пугает такая ситуация? Вы боитесь неизвестности и поэтому вам всегда приходят корректные данные? Не понимаю, что странного в том, что в JSON, который не подчиняется чудесным схемам, как это было в не к ночи будь помянутом XML (кстати, а положа руку на сердце - многие ли в действительности пользовались проверкой на соответствие схемам?) - так вот, в этом самом чудесном JSON на месте ожидаемой вами булевой переменной вам запросто может приехать «Война и мир»?

Что конкретно вас так сильно смущает?

Мне кажется, вам всё-таки было бы полезно взять у ребёнка учебник «Родная речь» и попробовать выполнить пару упражнений из него - глядись, научились бы связно и развёрнуто излагать свои мысли.

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Какие там типы у приложения на Perl?

Например, bool, id, Город, email, телефон, сообщение.

Пришли вам данные в JSON-формате, вы их распарсили тем же JSON::XS и положили в переменную $x

Не. У вас задекларированы типы. Пришли данные, вы их распарсили. И они сразу попадают в код, преобразующий их в ваши типы данных. Или вызывающий ошибку, в случае, если преобразование невозможно, когда, например, вместо {1,0} приходит «Война и мир». И только после преобразования в типы приложения переменая попадает в слой бизнес-логики.

самому писать все возможные варианты проверок и вводить сбоку «типы данных»

Когда вам требуется наследование членов класса, вы сами пишите. Когда вам нужны типы, вы сами их пишите. (хотите быстро, на XS).

level1 ★★
()

Здесь веет «русской тоской», и похоже Perl не причём, т.к.:

* Скорости достаточно, а если мало, то оптимизируй архитектуру приложения

* Валидируй как душе угодно

* Нагрузка прекрасно параллелится процессами и асинхронным io

* На CPAN-е множество добротных модулей

* Достойная работа есть - в рф и за её пределами

* То, что Perl 5.26 как-то медленее Perl 5.6 - булшит

anonymous
()
Ответ на: комментарий от level1

Вот прямо выцепил из кода модуля:

sub __get_timer_settings {
    my $r=ref($_[0]);
    my $dflt=$_[1];
    return unless 
        my @afterANDperiod =
        ($r eq 'ARRAY')
            ? @{$_[0]}
            : $r
                ? (return)
                : split /:/ => $_[0];
    return unless @afterANDperiod and +@afterANDperiod<=2;
    for my $c (0,1) {
        for ($afterANDperiod[$c]) {
            return if defined and $_ and (!looks_like_number($_) or $_<0);
            ( (!(defined and length) or ($c and !$_) ) and $_=$dflt->[$c] ) or $_+=0
        }
    }
    \@afterANDperiod;    
}

Это что-то из серии «за что мне Perl не нравится».

Хотя проверка достаточно сложная: на входе должен быть либо [AFTER, PERIOD], причём если PERIOD==0, то берётся default, либо «AFTER:PERIOD» (и если чего-то нет - тоже берётся default), но, гм, по-моему на perl это реализуется наихудшим образом из возможных.

P.S. И да, Mojo::IOLoop->recurring - полное овно, раз он не поддерживает After. Почему AnyEvent поддерживает, а recurring в типа прогрессивном Mojo - нет???

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 2)
Ответ на: комментарий от anonymous

Здесь веет «русской тоской», и похоже Perl не причём, т.к.:

НИ ПРИ ЧЁМ. Запомните раз и навсегда. Вот уж чего-чего, а русская тоска вам совершенно точно не грозит.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Кстати, нормально вообще приводить переменную к числовому типу таким залихватским способом: «$_+=0» ? Ни в одном языке, кроме Perl, я таких выкрутасов ещё не встречал.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

easy-easy :) лучше перепиши «__get_timer_settings» - твоя реализация, не Perl-а

anonymous
()
Ответ на: комментарий от anonymous

Согласен.

1) Пересобери без тредов и отключи дебаг . кроме того каждый релиз все шустрее и шустрее(я это почувствовал на том же mrtg)
2) посмотри perl signatures оно в коробке начиная с 5.16
3) Coro * anyevent *
Есть много новых годных модулей от тех же японцев на cpan . вообще я телеграмме в группу modernperl можешь задать , помогут

pinachet ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.