Представлен (http://pragmaticperl.com) тринадцатый выпуск Pragmatic Perl, русскоязычного электронного журнала о современном языке программирования Perl.В номере:
- От редактора: Год журналу- «Старые» современные возможности Perl- Сигнатура функции в Perl 5.20- Обзор CPAN за февраль 2014 г.- Интервью с Брено де Оливейра (Breno G. de Oliveira)
URL: http://pragmaticperl.com
Новость: http://www.opennet.me/opennews/art.shtml?num=39259
Прислали тут давеча скрипт на перле, из самой московии, чтобы выгрузку из бд на их ftp клал, а ему тьма либов перловых надобна, чтобы гребаный запрос к бд сделать, да запихнуть на серв через внешнюю команду, ну да ладно, надо так надо, через пару часов подвязок всяких репов и попыток установить правильную либу с неправильной версией на серв, перл таки рухнул в ошибку и запускаться отказался на отрез, а при перезагрузке запускаться оказался и сервер.Спрашивается, нахера плодить столько сущностей, если возня с ними начиста перекрывает, преимущество от использования скриптовых языков, не знаю есть ли реализация SOAP под Си, но затраченного времени вполне бы хватило. для написания проги на нем для пары SOAP запросов и запихивания результата в файл.
И на что ты жалуешься?
Люди у меня руки из жопы растут, я как есть сажусь и в руки вилку беру БЯДА прям - всё дузло в дырках и поесть не выходит и ущерб здоровью! Вывод - ВИЛКИ ЗЛО!
Для решения проблем с зависимостями в Perl создано несколько удобных инструментов под разные уровни.
1. cpanm + local::lib решает вопрос с собственно модулями
2. perlbrew обеспечивает нужную версию perl
3. PAR, Perl::Static и еще парочка позволяют вообще все упаковать в один бинарник, который на целевой системе надо просто запустить.Кто же виноват, что вы обо всем этом не знаете. Вот почитайте журнальчик, просветитесь, на эти темы материал в прошлых выпусках был.
При получении чужих скриптов достаточно сделать grep по use|require, получить из этого список модулей и скормить его cpanm. У опытного админа минут десять займет, не важно на bash или том же perl. Ну а дурак конечно может пару часов неведомо что творить и в конце концов угробить сервер.
Мораль: дуракам сервера доверять нельзя.
Я не работаю программистом перл шляпы, мне все ваши приблуды до звезды, у меня есть иструмент администрирования системы, и я им пользуюсь, и если он не работает, то виноваты, либо разрабы системы, либо разрабы той хрени, которая в обход всех ухищерений таки умудряется упасть, а ну конечно, руки у меня из жопы растут и я как-то не так набираю юм-инсталл.Кого-то в чем-то преубедить даже не расчитываю, но почему-то для запуска всех перл скриптов которые мне попадались, всегда нужно что-то доустанавливать, а вот скаченый лет 8 назад скрипт на пхп с реализацией xmpp клиента хоть и сыплет ворнингами, но работает на системах из каробки.
Отсюда я сделал простой и логичный вывод, благодаря чему, написаные мной скрипты живут и процветают в конторе откуда я срулил в 2008 и откуда имею дополнительный доход за обновление системы, которое происходит: установкой системы на виртуалке, копированием тех самых скриптов, заливкой свежей бд и сливом полученного образа на винт сервера.
Но вы конечно же можете продолжать писать новый код, а потом переписывать под новые версии и короче удаче вам в вашем бессмысленом занятии.
Меня откровенно пугает ваша абсолютная уверенность в своей непогрешимости.Вы написали скрипт на php для xmpp (который кстати чисто текстовый, и ни от чего не зависит) - и он обновляется без проблем. О чудо.
Вы написали скрипт на perl, который работает с базами и имеет много модулей в зависимостях. И при обновлении всплыли проблемы. О чудо.Может, Вы всё-таки плохо скрипт написали? Может, Вы задействовали из этих модулей функции, помеченные как deprecated, и удалённые из новых версий модулей? А не кажется ли Вам, что это в принципе проблема любых библиотек в любом языке программирования?
Я не понимаю, почему инструмент виноват в том, что у Вас всё плохо, если у большинства разработчиков всё хорошо.
Главный смысл коментария вот здесь:> имею дополнительный доход за обновление системы, которое происходит: установкой системы на виртуалке, копированием тех самых скриптов, заливкой свежей бд и сливом полученного образа на винт сервера
Т.е. человек не хочет напрягаться, а деньги получать хочет :D
Да я не хочу напрягаться на переписывание кода для сохранения имеющегося функционала, а вам не кажется глупым переписывать код просто ради того чтобы переписать под новую версию?> Я не понимаю, почему инструмент виноват в том, что у Вас всё плохо, если у большинства разработчиков всё хорошо.
У большенства? вы в какомто мире другом живете? я вам привел уже пример того как !скаченый с нета скрипт на пхп работает, а там несколько тысяч строк кода, ну пакажите мне скрипт на перле в котором несколько тысяч строк кода и который будет нормально работать, на системах как современных так и 10летней давности.
У меня периодически возникает необходимость сконвертировать 2-3-5 мег инфы, дабы не парится набираю в гугле что надо, получаю ссылку на перл скрипт, и сколько раз не пробовал столько раз обжигался на том, что блять пол системы надо переебсти чтобы он только запустился, а сконвертит или нет еще не факт.
> Может, Вы всё-таки плохо скрипт написали? Может, Вы задействовали из этих модулей функции, помеченные как deprecated, и удалённые из новых версий модулей? А не кажется ли Вам, что это в принципе проблема любых библиотек в любом языке программирования?
1) нет не кажется, 2) не я его писал, 3) если добавление/удалений функций происходит постоянно, то какой профит от написания чего-либо? оно через год два устареет и работать не будет, опять писать?
> Меня откровенно пугает ваша абсолютная уверенность в своей непогрешимости.
Я рад что вы уловили данный посыл, на заре своей карьеры я пытался понять перл, что-то писал, хоть меня и несколько раздражали особенности синтаксиса, но тем не менее последним гвозьдем в гроб стала именно переносимость, с одной машины на другую, как вы говорите 10 минут, зачем терять их если можно за 0.5 скопировать сам скрипт и даже не думать о каких-то там зависимостях. А если скриптов зоопарк, и все под разные версии, уу, тогда работа превращается в ад, но если вам нравится это ваще право.
Да, мы живем в другом мире. В нашем мире программисты знают что такое code reuse и библиотеки, а не гордятся велосипедами на 10к строк. В нашем мире программисты знают используемый язык, его среду и умеют правильно паковать перловые программы для переносимости и писать к ним простые инструкции. В нашем мире системными администраторами не называют обезьянок, чей потолок yum install. Наш мир - это мир умных людей.Хотите одним глазком заглянуть в наш мир? Тогда справьтесь с эмоциями и открытым текстом попросите прямо в этом топике рассказать вам, как следовало поступить в вашей ситуации.
>Да, мы живем в другом миреТут дело даже не совсем в мире. Одна из основных, а может быть и главная, проблема перла в том что под этим словом понимают как минимум две очень разные вещи - и нормальный полноценный язык программирования, и баш-на-стероидах-с-регэкспами. И всё бы было ничего, если бы в одном случае говорили что речь про, скажем, perl5, а в другом - про perl4.
А миры, в общем случае, могут быть и не такими уж разными - человек может вполне реюзать, тестить, знать и паковать, допустим, Python или Ruby, и в то же время на perl писать портянки, просто потому что для него perl - это баш-на-стероидах-с-регэкспами.
Ну да perl это не питон, на нем возможно писать однострочники. Я только не понимаю почему вы об этом говорите, как о чем-то плохом. Это преимущество, а не недостаток или проблема. На ruby кстати тоже легко пишутся однострочники, причем очень похожие на перловые. Ruby для вас теперь тоже станет бякой?
>На ruby кстати тоже легко пишутся однострочники, причем очень похожие на перловыеТолько этого делать как-то не принято. Поэтому обычно берут перл и делают это на нём, ругая его потом за нечитаемость этих однострочников. Люди вообще не так привержены логике как принято считать.
Я говорил о другом - о том что есть два (и между ними еще много полутонов) перла - тот что ругают и пишут на нём однострочники и портянки, и тот в котором есть Moose, AnyEvent, лучшая инфраструктура для тестирования ever и т.д. И было бы удобней если бы эти два перла обозначались какими-то разными словами, а не одним и тем же.
Первый раз не совсем правильно понял вашу мысль, мне показалось, что вам не нравится сама возможность писать на перле код типа "some black magic here". Теперь стало понятно.
На самом деле разные слова для этих двух типов использования уже есть. Различают Perl и Modern Perl. И отличие не в версии perl или наличии каких-то модулей, а в разных подходах к написанию программ. То есть в том, о чем вы говорили.
Так вот вопрос в том почему нет слова Modern Python и слова Modern Ruby.
Во-первых, авторы этих языков не дружат с такой концепцией как "обратная совместимость". Вот и получают устаревание версий быстрее, чем устаревание методов работы. В результате имеем python 2, python 3, ruby 1.8, ruby 1.9, ruby 2.0
Во-вторых, на одном из этих языков писать однострочники нельзя в принципе, а второй практически неизвестен среди тех, кто это мог бы делать.
> Да, мы живем в другом мире. В нашем мире программисты знают что
> такое code reuse и библиотекиа в перле вообще наследование объектов есть?
> строк. В нашем мире программисты знают используемый язык, его среду
а в вашем perl-мире что есть для написания сетевых сервисов на много тысяч tcp-соединений без лапши коллбэков и отладки всего этого в рантайме? ну т.е. green threads у вас там есть?
> Хотите одним глазком заглянуть в наш мир?
хочу. расскажите, как в вашем мире писать сишные расширения без обкуренного xs?
1. Да
2. Да
3. XS лишь один из способов, есть другие. Можно например глянуть доки по pdl на эту тему, там расширения на С вообще элементарно делаются.
>а в перле вообще наследование объектов есть?Нет, только регэкспы и онлайнеры.
>сервисов на много тысяч tcp-соединений
На много тысяч соединений на тредах не пишут. Ну, кроме индусов, не осиливших конечный автомат. Для них городят green threads и прочую сомнительную эквилибристику.
Того что есть для, например, Perlbal хватило, много лет назад, с LJ справлялся пока тому супец не настал.
А есть много чего, от POE и Coro до новомодного AnyEvent.>как в вашем мире писать сишные расширения без обкуренного xs
Ну так и пишите, без XS. Perlguts illustrated просмотрите и вперед.
С XS удобней, но раз вам не нравится - не пользуйтесь.
Если надо быстро и как-нибудь, можно тупо взять SWIG.
> На много тысяч соединений на тредах не пишут. Ну, кроме индусов, не
> осиливших конечный автомат. Для них городят green threads и прочую сомнительную
> эквилибристику.а что сомнительного в green threads и actor model?
> А есть много чего, от POE и Coro до новомодного AnyEvent.
беда всех таких фреймворков - это лапша коллбэков и невозможность использования чего-либо, не написанного с прицелом на event-driven, т.к. 1 блокирующая операция и приехали.
в некоторых языках(не буду показывать пальцем) для этого монкипатчат стандартную библиотеку и всё становится хорошо.отдельная история, если нам надо почитать с диска, а диски у нас нагружены и ждет нас d-state. нормальные люди для этого городят пул тредов и всё подобные операции скидывают туда.
и вот когда всё это мы написали и наш event loop работает, возникает необходимость разложиться по ядрам.
потому я и спрашиваю: а чего в перле есть из всего этого для решения таких задач?
чтобы без коллбэков, можно было использовать стандартные модули и был удобный пул тредов.> Ну так и пишите, без XS. Perlguts illustrated просмотрите и вперед.
> С XS удобней, но раз вам не нравится - не пользуйтесь.
> Если надо быстро и как-нибудь, можно тупо взять SWIG.cffi как-то более приятнее.
Для ниасиляторов state machine и callbacks(лапша именно у ниасиляторов, у других вполне понятный код) есть два вида threads в базовом варианте и Coro. Для разложения по ядрам есть старый добрый fork, который вполне можно сочетать с разными видами thread. Вообще вопросы вида "есть ли в perl такая хрень" всегда вызывают улыбку. Потому что ответ практически всегда такой: "да есть, несколько вариантов, выбирай на вкус".
> Для ниасиляторов state machine и callbacks(лапша именно у ниасиляторов, у других вполне
> понятный код)программировать fsm муторно => проще ошибиться и больше кода.
т.е. речь не о том, что человек не осилил.> есть два вида threads в базовом варианте и Coro.
и как там с передачей объектов между этими двумя видами? ну или хотя бы хешей.
> Для разложения по ядрам есть старый добрый fork, который вполне можно
> сочетать с разными видами thread.опять же, как с передачей объектов между раздными процессами и тредами внутри них?
> Вообще вопросы вида "есть ли в
> perl такая хрень" всегда вызывают улыбку. Потому что ответ практически всегда
> такой: "да есть, несколько вариантов, выбирай на вкус".только неудобно и сам по себе perl медленный.
> программировать fsm муторноТак вы веселья хотите? Тут согласен - отлаживать треды очень весело. И главное это можно делать бесконечно, когда вылезет очередной дедлок известно только высшим силам.
> только неудобно и сам по себе perl медленный.
Так этой фразой можно было и ограничиться. Ну добавить еще что нечитаемый.
>> программировать fsm муторно
> Так вы веселья хотите? Тут согласен - отлаживать треды очень весело. И
> главное это можно делать бесконечно, когда вылезет очередной дедлок известно только
> высшим силам.ну у меня как-то получается и без дедлоков. может, всё дело в языке, дающем удобные объекты для абстракции над примитивами синхронизации(давая возможность там где надо использовать локи напрямую)?
>> только неудобно и сам по себе perl медленный.
> Так этой фразой можно было и ограничиться. Ну добавить еще что нечитаемый.на черт с ним, с синтаксисом. просто у кого-то есть jit, а у кого-то - нет.
а c-extensions можно писать почти ко всему :)
>а что сомнительного в green threads и actor model?Вот именно это называется сектантство - когда вы не имеете представления о недостатках используемого вами подхода.
>беда всех таких фреймворков - это лапша коллбэков
В основе всё равно будут коллбэки, разница только в том сколькими слоями синтаксического сахара они покрыты. Причем стоит отдавать себе отчет в том что чем этих слоёв больше, тем больше ошибок и сложнее их найти.
>и невозможность использования чего-либо, не написанного с прицелом на event-driven
Сoro кажется довольно несложно обернуть legacy код.
>в некоторых языках(не буду показывать пальцем)
Покажите, кого нам стесняться.
>для этого монкипатчат стандартную библиотеку и всё становится хорошо
До тех пор пока не станет плохо?
>отдельная история, если нам надо почитать с диска, а диски у нас нагружены и ждет нас d-state. нормальные люди для этого городят пул тредов и всё подобные операции скидывают туда
Для этого много чего придумали, только хорошо пока никому не стало. Если говорить о Линуксе, то и с AIO плохо, и с O_DIRECT отвратительно. Треды ли там поверх этого и какого именно цвета, или другие абстракции, проблему решает не особенно.
>cffi как-то более приятнее
Ну если вы в смысле накодить glue вообще не просыпаясь, то есть еще всякие Inline::C и FFI::Raw.
>>а что сомнительного в green threads и actor model?
> Вот именно это называется сектантство - когда вы не имеете представления о
> недостатках используемого вами подхода.с чего такие выводы о моей персоне? кроме того, этот подход хорошо масштабируется.
>>беда всех таких фреймворков - это лапша коллбэков
> В основе всё равно будут коллбэки, разница только в том сколькими слоями
> синтаксического сахара они покрыты.да, только размазывать более-менее сложную логику по коллбэкам муторно.
человек - не машина и яркий пример callback-hell - это nodejs.
и чтобы хоть как-то облегчить жизнь рождаются всякие node-fibers/node-sync и попытки втащить в язык yield.> Причем стоит отдавать себе отчет в том
> что чем этих слоёв больше, тем больше ошибок и сложнее их
> найти.у кого-то короутины есть прямо в языке. в некоторых вариантах еще и с вытесняющей многозадачностью.
>>в некоторых языках(не буду показывать пальцем)
> Покажите, кого нам стесняться.ruby/python
>>для этого монкипатчат стандартную библиотеку и всё становится хорошо
> До тех пор пока не станет плохо?ну вот у меня пара процессов уже где-то полгода болтаются. не текут по памяти и дескрипторам. за это время скачали/раздали под сотню терабайт.
в каждый из них могу зайти телнетом, получить интерактивную консоль интерпретатора, посмотреть/поменять значения переменных, можно и код налету апдейтить.
>>отдельная история, если нам надо почитать с диска, а диски у нас нагружены и ждет нас d-state. нормальные люди для этого городят пул тредов и всё подобные операции скидывают туда
> Для этого много чего придумали, только хорошо пока никому не стало. Если
> говорить о Линуксе, то и с AIO плохо, и с O_DIRECT
> отвратительно.AIO не нужен. в том виде, который он где-либо есть из распространенных *nix.
единственный, кто его "использует" - это nginx. и весьма своебразно.> Треды ли там поверх этого и какого именно цвета, или
> другие абстракции, проблему решает не особенно.вы, мягко говоря, не правы. если данных нет в кеше и за ними надо лезть на диск, то в случае реального треда "залипнет" только он. в случае всяких green threads и coro - залипнет всё.
потому posix_fadvise/fincore(на linux).
1) не горжусь, а ставлю в пример. 2) не велосипед, а единственная в своем роде разработка наиболее полно реализующая возможности. 3) нормальные языки не надо паковать и писать к ним инструкции по запуску. 4) я не работаю в конторке на 5 чел, где всегда можно договориться, я уверен, что можно писать на перле нормально, так же как и на любом другом языке, но идеальные условия, потому и называются идеальными, что отличаются от средне статистических, и если вшивый московский студентик накропал 50 строк кода которые роняют серв, то пусть роняют мне не платят за подтерание его задницы; а если (я надеюсь) начальству это надоест, то они всегда могут нанять квалифицированного специалиста, может быть они наймут вас, вот тогда и получим конструктивный диалог.А до тех пор, вы будите мне рассказывать как марсиане кодют на перле терраформационные устройства, а я вам про том как студентики, индусы и прочая лажают при использовании встроенных функций.
В сущности я лишь поведал способ положить серв - использовать жутко кастомную библиотечку превередливую до зависимостей. И спросил - вас - перловодов, как вам живется в этом бардаке, и тут началось руки из жопы, обезьяна не грамотная, бла-бла-бла. У меня все работает, все сервера зарезервированы, если упадет, то в полуавтоматическом режиме поднимится, мои "личные" сервера бродят по сети и докладываю о любых аномалиях, еще чуть-чуть и они начнут "разговаривать", слать смски монтанжникам - куда пойти и че поменять/проверит/перезагрузить, я работаю в построенном мною раю, чтобы сделать лучше нужно пинать разрабов для реализации моих дополнительных хотелок, и вы хотите меня научить запускать перл скрипты? знакомы с выражением - не учи отца еб..а
>я работаю в построенном мною раю, чтобы сделать лучше нужно пинать разрабов для реализации моих дополнительных хотелок, и вы хотите меня научить запускать перл скрипты?Ну раз вы не умеете этого делать, почему бы и не поучиться?
>знакомы с выражением - не учи отца еб..а
Не хотите - воля ваша, не умейте дальше.
> Ну раз вы не умеете этого делать, почему бы и не поучиться?Потому что это вопрос веры, ваш бог не лучше моего, разве что мой сервера еще ни разу не ронял)), а раз так, то и профита нет, может быть гугель родит что-нибудь, последние годы они активно сточат языки, хотя от богомерзкой явы в андроиде уходить не спешат, тем не менее, да же вы согласитесь, наверняка, что не перл займет место на олимпе.
Какая вера, какие олимпы?Если у вас достаточно часто возникают ситуации когда нужно установить программу, написанную на перле, логично было бы потратить час времени и научиться правильно это делать. Если нет, то и нет.
недостаточно
> ну пакажите мне скрипт на перле в котором несколько тысяч строк кода и который будет
> нормально работать, на системах как современных так и 10летней давности.легко - http://www.webmin.com
Еще на наг.ру был интересный скрипт dhcp сервера с базой mysql, самое то для билинга.
Перл это как музыкальное направление, его не все понимают, но кто понимает, тот восхищается добезумия. Типо как с с++
Говорят, автор Perl - лингвист, а у вас похоже с языками туго, даже с русским. Может не стоит на зеркало пенять, если с рожей не вышло?
Такое ощущение, что писал google translate))
>Я не работаю программистом перл шляпы, мне все ваши приблуды до звезды,Ты забыл самое главное - ВИЛКИ ЗЛО! :)
Очень хороший журнал. Удачи авторам.
> Очень хороший журнал. Удачи авторам.Спасибо.
>Что такое ООП в случае Perl? Это, так называемый, blessed hashrefДа что ж такое-то опять, да почему ж обязательно hashref, если блессить можно любой тип данных?
И про Tie было б неплохо уж заодно упомянуть, как вообще уникальный вариант ООП, причем в самом хорошем смысле этого слова.
Не последняя статья автора про "фишки" перла, думаю, напишет еще про tie. А про blessed хорошее замечание.
Ну тогда, надеюсь, в третьей части будет про самое вкусное - bless и tie вместе (оба очевидных варианта) и обсуждение стоит ли tie-ить и bless-ить to the same package (по русски это звучит как-то по-дурацки, извините), несмотря на то что это возможно. Хотя Conway это детально разобрал - с понятными картинками - еще 14 лет назад, как-то никто его особо не читал, есть такое ощущение. Так что многим будет интересно.Ну и неплохо бы лишний раз повторять при каждом удобном случае "Though bless indeed requires a reference as argument it actually tells _the thingy referenced by REF that it is now an object_, so it blesses the thingy, and not the reference".
А почему бы вам и не написать такую статью для этого журнала?Еще интересно было бы посмотреть на примеры классов, где оправдано использование не хешей. За все время я только раз такое создавал, там были операции с полиномами и list для bless подходил лучше чем hash.
> А почему бы вам и не написать такую статью для этого журнала?Потому что Conway еще в 2000 все об этом уже написал, и лучше чем кто-либо сможет в будущем? Книжка доступна, бери да читай.
> Еще интересно было бы посмотреть на примеры классов, где оправдано использование не
> хешей. За все время я только раз такое создавал, там были
> операции с полиномами и list для bless подходил лучше чем hash.Мне кажется что здесь полезно было бы посмотреть на ООП немного проще чем это принято в мэйнстриме. Вот есть у нас нечто, например filehandle, хотим мы его научить некоему дополнительному нужному нам кунштюку. Не нужно нам писать класс файлхэндл-с-кунштюком, хранить в нём fh и так далее и тому подобное - привет Бучу, Фаулеру и компании. Мы просто хотим добавить ему один-два метода, и чтобы перл знал что он вот такой у нас особенный, достаточно поставить ему флажок "magic" и указатель на пакет где эти методы брать.
И в примерах недостатка не окажется, если посмотреть вот так, ясным взглядом, без догматизма.
Какой-то дико извращенный вариант. Натянуть класс только ради натягивания класса. Зачем ограничивать функции работы с filehandle требованием принадлежности filehandle классу? Если никакой дополнительной информации не хранится в объекте, то с точки зрения кода метода/функции нет разницы принадлежит ли какой-то filehandle классу или нет, это все-равно просто тупой filehandle. В общем практической пользы ноль.