После двух с половиной лет разработки состоялся релиз компилятора для языка программирования Perl - RPerl 1.0 (http://rperl.org/). RPerl получает (https://metacpan.org/pod/release/WBRASWELL/RPerl-1/script/rp... на входе perl5-код (скрипт или модуль), транслирует его в представление на языке С++, которое следом конвертируется в XS-код (https://en.wikipedia.org/wiki/XS_%28Perl%29) силами модуля Inline::CPP. Полученный код может использоваться в высокоуровневом Perl5-коде как обычный модуль с XS-реализацией. В конечном счете XS-код транслируется в машинный код С++-компилятором. Исходные тексты проекта распространяются (https://github.com/wbraswell/rperl/) под лицензиями Artistic и GPL, т.е. RPerl распространяется на тех же условиях, что и интерпретатор Perl5.В отличие от предыдущих попыток создания копилятора Perl (perlcc, pp, perlito (http://www.perlito.org/), B::C (https://code.google.com/p/perl-compiler/), B::CC, B::Bytecode), которые не были доведены до рабочего вида или сводились у упаковке байткода в исполняемый файл, что позволяло скрыть исходные тексты, но существенно не влияло на производительность, в RPerl предпринята попытка предоставления возможности использования (https://github.com/wbraswell/rperl/tree/master/t) статических типов C++ для существенного повышения производительности. Автор проекта заявил (http://rperl.org/performance_benchmarks.html), что подобная компиляция в среднем позволяет добиться семикратного увеличения скорости исполнения программ при использовании Perl5-структур данных и 200-кратного ускорения при использовании С++-структур. В будущем ожидается ещё большее увеличение производительности, так как на данный момент компилятор RPerl не включает в себя какие-либо особые оптимизации кода, которые потенциально могут ускорить исполнение кода.
URL: http://rperl.org/
Новость: http://www.opennet.me/opennews/art.shtml?num=42567
Вот бы книгу по эффективному использованию данного инструмента.
Книга по компилятору это несколько излишне, но хотя бы минимальная дока не помешала бы, а то даже синопсиса никакого за пять минут не нашел. Пока нет доки, оно нужно только авторам.
А нет - тут не все так просто. Да и вообще, с Perl же не бывает просто :).
CLI-интерфейс к компилятору как бы вот: http://search.cpan.org/~wbraswell/RPerl-1.000001/script/rperlВы наверное в гугле ищете? :)
По прочтению могу лишь повторить: "Пока нет доки, оно нужно только авторам.". Ибо назвать это документацией сложно.
Я не автор, но мне тоже нужно. Описании CLI-опции вполне хватает чтобы уже работать RPerl. А так - да, нужна книга.
что-то perl в последнее время перестали закапывать и стали развивать. Вот только почему-то только у нас в Рашке и странах СНГ к нему какое-то общее пренебрежение.
У нас Pascal в универах. И не говорите преподам всякие страшные слова типа C++, Perl и т.д.
> У нас Pascal в универах. И не говорите преподам всякие страшные слова
> типа C++, Perl и т.д.Им религия не позволяет уверовать во что-то новое. Ибор в священном писании написано молиться на Pascal.
характернейший пример в комментариях: http://habrahabr.ru/post/258391/
Вы во многом заблуждаетесь.
> Вот только почему-то только у нас в РашкеВ Рашке -- может быть, не знаю как там, я в Сербии не был,
зато в России -- все крупные инет-компании весьма активно используют перл.
Не несите чушь, юзают его админы и то последнее время все меньше.
Про YAPC::Russia погуглите.
> Не несите чушь, юзают его админы и то последнее время все меньше.А Вы не допускаете возможности что чушь несёте Вы, а я знаю как обстоят дела потому что работаю в одной из этих фирм, а с другими доводится общаться?
Ну так говори где работаешь yandex, mail.ru, vkontakte что то я не припомню чтоб там активно перл юзали.
> Ну так говори где работаешь yandex, mail.ru, vkontakte что то я не
> припомню чтоб там активно перл юзали.Не знать, да ещё и забыть -- понимаю как тяжело Вам.
PS Вам уже сказали где смотреть, с последнего yapc видео есть -- посмотрите, может быть вспомните часть того, чего Вы ниикогда не знали.
снобизм прямо из монитора хлынул.
Ну а как идилотам объяснить чтоб поняли?! Так что - жри :)
А если спросить у MSSQL-пользователей и форточка-админов, то они скажут что Linux в мире используют от силы человек двадцать.
На самом деле проделана большая работа, амбиций у ребят много. Я думал после появления стольких инструментов необходимость в этом языке отпала, но походу он скоро пойдет по стопам питона - пропихивание везде, во все области.
У этого ЯП хорошо раскрытый высокий потенциал.
А раскрыт он тем, что для всех отраслей безделия существуют модули и документация.
> амбицийВам бы язык мылом помысть. Амбиция - это манера, "почерк" быDлообразных. А эти ребята мастера своего дела и дело не в амбициях. Рассмотрите анонсы той же FireFox данно проекта RPerl или Perl11 и вы поймете разницу. Надеюсь больше вы не будете позволять подобные заявления.
А ребята по-настоящему крутые. Проект релизнулся в День Независимости США по рассчету несомтря даже на то что "March 13th, 2014: It's Offical. RPerl At GSoC 2014! Canceled...".
Дальше - лучше:
> What is Perl 11?
> A: Perl 11 is the philosophy that Perl should be made modular ("pluggable") on the 3 primary levels of source code lexer/parser, compiler/AST, and runtime/interpreter/VM. Perl 11 is not an actual version number Perl release like Perl 4, Perl 5, and Perl 6. One of the goals of Perl 11 is to work toward unification of Perl 5 and Perl 6, thus 5 + 6 = 11. There are multiple independent projects under the Perl 11 umbrella, one of which is RPerl. RPerl is an implementation of the Perl 11 philosophy. Perl 11 was created by Ingy dötNet, Reini Urban, and Will Braswell on September 18th, 2012 in Austin, TX.
лучше perl чем питон.. ибо перл есть Основа
Молодцы всё-таки американцы. Работают хорошо, теперь наши программисты могут ещё лучше пользоваться результатом их труда.
Ну зачем же так во всеуслышание заявлять о том, что ты паразит. Хоть бы постеснялся, что ли...
Стеснительные все стали...
> Ну зачем же так во всеуслышание заявлять о том, что ты паразит.
> Хоть бы постеснялся, что ли...Бывает и хуже :). Некоторые вон еще и недовольны что другие кодят не так как надо им, следуя всяким там американским законодательствам.
+1024
Не понял посыла. Во всех других странах что ли плохо программисты работают?
Ну представьте аналогичные сообщения из России. Про другие страны можно не представлять, они мне интересны. А про российские проекты - интересны. Что у нас такого делается, что вызывает интерес во всём мире, чем пользуются во всём мире. И количество этого всего в процентах относительно мирового уровня.
> Ну представьте аналогичные сообщения из России. Про другие страны можно не представлять,
> они мне интересны. А про российские проекты - интересны. Что у
> нас такого делается, что вызывает интерес во всём мире, чем пользуются
> во всём мире. И количество этого всего в процентах относительно мирового
> уровня.ReactOS?
Основные разработчики nginx и openvz русские, хоть и работающие на иностранные компании. Надо ли пояснять где находятся эти два проекта и где rperl?
> Основные разработчики nginx и openvz русские, хоть и работающие на иностранные компании.
> Надо ли пояснять где находятся эти два проекта и где rperl?Внимательно читаем мой вопрос!
Внимательно читайте на что вы сами отвечали, а именно : "Во всех других странах что ли плохо программисты работают?". Русские программисты работают хорошо. Не их вина в том, что работать выгоднее на иностранные компании. Это уже вопрос к политикам.
Ну и тот же nginx заграницей называли русским вебсервером и известность он получил задолго до 2011 года, когда был создан NGINX Inc.
> Внимательно читайте на что вы сами отвечали, а именно : "Во всехВы удивительно самодостаточный человек. Сами что-то придумали, с этим и спорите.
> Русские программисты работают хорошо. Не их вина в том, что работать выгоднее на иностранные компании.angra - ты женился чтоли и ребятёнка завёл?
А то в последнее время - как подменили человека, бреда всё меньше и меньше :)
> Внимательно читайте на что вы сами отвечали,
> а именно : "Во всех других странах что ли плохо программисты работают?".
> Русские программисты работают хорошо.
> Не их вина в том, что работать выгоднее на иностранные компании.Да что же ты так издеваешься. Ведь мозг сломать можно!
В Штатах и русские работают хорошо, и узбекские хорошо.
А в других странах работают плохо, потому что из других стран подобных новостей нет.Предложении про "выгоднее" я вообще не понял с чем связано.
Оно для другого поста предназначалось?
Здесь есть кто-нибудь, кто по собственному желанию хорошо освоил перл ну скажем на промежутке последних 5-ти лет? Просто интересна причина. Теории чем он хорош и диванные аналитики могут нагнать, а вот на практике что-то таких не встречал, т.е. по моему он жив только потому что еще есть работающий код на нем, а всё новое реализовывается на других языках и инструментах
Ну я, например. За хорошо/плохо не скажу, не мне судить, но освоил по собственному желанию и предварительно посмотрев похапе и питон.
Причины просты:
* Интересный язык, написанный лингвистом. Куча конструкций и удобств которые не встречаются в других языках. Т.д. и т.п., вообщем язык интересный. Да и девиз у него говорящий о многом: "Есть множество способов сделать это".
* Порог вхождения довольно высок. Совсем студентов вы на нем не встретите, как в том же пыхе.
* Зарплата перловика высокая. Отчасти от того что и их мало, отчасти из за предыдущего пункта. Вообще перловиков в небольших конторах встретить трудно, с рынка сгребаются большими конторами (зарплатами) и там оседают.
* Язык постоянно развивается. Регулярно выходят новые релизы, проходят конференции. Так что про "закапывание" это все невежды кричат. Просто контингент небольшой, а потому новости не на слуху.
* Действительно перл используется во многих крупных конторах. Яндекс, Мейл.ру, Мастерхост, Рамблер и т.д. Конечно такие конторы состоят из множества проектов написанных на разных языках. На перле: "Мой Круг" яндексовый, почта и "мой мир" мейловый. Напомню что в nginx встроен перл =)
Кроме nginx, ещё exim. Ну и к slapd прикручивается при необходимости (из того, чем занимался). Кто больше?
pl/perl в postgresql
емнип, из ещё крупных сайтов на перле написана жэжэшечка. ну, и спамассассин, конечно.
> из ещё крупных сайтов на перле написана жэжэшечкаIMDB. Lenta.ru.
Форум ixbt (основной сайт не знаю на чем).
false. ruby
https://en.wikipedia.org/wiki/Internet_Movie_Database :> The website is Perl-based.[5] As of May 2011, the site has been filtered in China for more than one year, although many users address it through proxy server or by VPN.[6]
DuckDuckGo написан Perl
CPAN. как говорится, на CPAN - пакет, для php/python/etc - стартап.
Регулярки -- знаешь Perl владеешь регулярками.
Я освоил его по собственному желанию, правда начал лет 7 назад. Начиналось от нечего делать, а сейчас в местячковом провайдере получаю за него хорошие деньги и развиваю старые и разрабатываю новые проекты с помощью Perl.
Я самостоятельно освоил. Причина - нужен был лучший инструмент удовлетворящий определенным критериям продиктованными суровыми условиями реальности. Пишу как приложения на Perl, так и занимаюсь встраиванием. В Perl нашлись те преимущества которых нет в обычных языках (c++, python, java, php и т.д.). До знакомства с Perl писал ынтерпрайз-код на Java и C++.
Примкну к подписавшимся. Сам начал осваивать год-полтора назад. В начале стал рассматривать как и питон, тикль, руби, однако постепенно втянулся. Перл удивил. Не ожидал от "очередного скриптового" такой гибкости и производительности начиная от синтаксиса, заканчивая экосистемой.
Освоил и очень доволен.
Прекрасный инструмент для быстрого прототипирования, мелких и не очень скриптов.
На сипане куча модулей под все. А еще такие прекрасные вещи как AnyEvent, Coro, EV- можно писать асинхронные сетевые проги, призводительность очень хорошая, тысячи конектов и запросов в секунду - легко, покажите мне другой скриптовый язык с такими возможностями. Что-то я не видел подобного на питон какой-нибудь, везде плодят сотни форков отжирающих память по штучке на конект, ноют о gil. Да, есть нода,но синтаксисы перла и жс несравнимы, перл намного лаконичней и мощнее, корутины позволяют не писать лапшу из колбеков, промисов и прочих костылей. Регулярки встроены в синтаксис, идеальный язык для написания парсеров и автоматизации сетевых действий.
асинхронность != многопоточность.в этом смысле perl ничем не лучше и не хуже python.
Если честно, то не интересовался что там в питоне локается. Да, асинхронность не многопоточность, но я часто вижу в дрыгих языках как пыются сетевое io делать потоками и это тормозит и жрет ресурсы, а все потому что нет удобных асинхронных либ.
Для многопоточности в перле есть модуль forks например, и еще десяток разных форкменеджеров. Да, с настоящими потоками проблема(threads перловые это жуткий костыль для эмуляции форков на офтопике, они деприкейтед), но в каком мейнстримовом скриптовом языке с ними все ок? Потоки лучше форков когда нужно много комуникации между потоками, а зачем это с криптовом языке? Для вычислений есть сишка и плюсы, io, особенно сетевое нужно делать асинхронным, а чтоб запустить в несколько потоков какую-нибудь апликуху хороши и форки, там межпотоковые взаимодействия не требуются.
В perl две разные модели: 5005threads который deprecated и ithreads. Если вы понимаете внутреннюю работу perl, то должны понимать как и почему работает ithreads.
В теории в принципе можно ввести в perl те же pthreads, но объясните мне в чем смысл этого и для чего оно нужно? Я думал над этим вопросом и что-то не увидел нужности, т.к. проблем и сложностей возникает гораздо больше чем решается.
Про то что две модели я знаю. Я имел ввиду ithreads, но они тоже уже почти деприкейтед, т.к. костыль для венды делающий полную копию интерпретатора.
>The use of interpreter-based threads in perl is officially discouraged.Шаред структуры копирующие все данные рекурсивно это вообще смех, мало того, запаковать структуру в жсон, положить ее в шаред скаляр и распаковать в другом потоке быстрей, нежели просто сделать все шаредным. В общем быстрей бы удалили это убожество, на операционных системах с нормальными форками нe нужно.
>В теории в принципе можно ввести в perl те же pthreads, но объясните мне в чем смысл этого и для чего оно нужно?
Согласен, не нужно. Когда нужно что-то многопоточно делать легко подключается Inline::C с pthreads.
А вот в язык встроить не так просто. Я как-то пробовал запустить два интерпретатора в одном процессе, так вот чтоб это сделать надо собирать интерпретатор с поддежкой этих ithreads. У перла проблема я так понял в том, что он юзает глобальные переменные. А если с поддержкой ithreads интерпретатор собирать, то он более тормозной, наверно блокировки юзает при доступе к этим переменным. Им бы лучше сделать весь стейт интерпретатора в отдельной структуре как в lua, тогда написать нормальные потоки можно будет без проблем.
А я смотрю вы тот еще дилетант.> Про то что две модели я знаю. Я имел ввиду ithreads, но они тоже уже почти деприкейтед, т.к. костыль для венды делающий полную копию интерпретатора.
Они discouraged потому что их интерфейс ужасен. А под виндой никак не получится кроме создания полной копии интерпретатора. Такова уж кривость винды.
> Шаред структуры копирующие все данные рекурсивно это вообще смех, мало того, запаковать структуру в жсон, положить ее в шаред скаляр и распаковать в другом потоке быстрей, нежели просто сделать все шаредным. В общем быстрей бы удалили это убожество, на операционных системах с нормальными форками нe нужно.
Не зря сделали рекурсивную копию. В JSON в отдельных случаях можно, но смысла совсем нет, т.к. Data::Dumper + eval отработают быстрее, да так возможны случаи когда кроме рекурсивного копирования не обойтись. Если бы вы сталкивались с подобным, то не писали бы подобное (вот я сталкивался когда работал с ithreads на уровне си и знаю почему нужно рекурсивное клонирование)
> Согласен, не нужно. Когда нужно что-то многопоточно делать легко подключается Inline::C с pthreads.не рекомендуют работать с perl-threads с perl-кода из-за
> А вот в язык встроить не так просто. Я как-то пробовал запустить два интерпретатора в одном процессе, так вот чтоб это сделать надо собирать интерпретатор с поддежкой этих ithreads.
Ничего сложного. Все очень просто и практически все готово для встраивания. Но это все обычный программист не разбирающися во внутренностях организации perl не сможет.
> У перла проблема я так понял в том, что он юзает глобальные переменные.Не выдумывайте - нет там проблемы и использование глобальных переменных зависит от режима сборки. Там все ровно сделано.
> А если с поддержкой ithreads интерпретатор собирать, то он более тормозной, наверно блокировки юзает при доступе к этим переменным.
Нет там блокировок, там сделано так чтобы у не подготовленного программиста не было проблем. Не используйте threads если не нужно. Да и вообще, по логике организации там не нужны блокировки, т.к. управление отдано на программиста. Именно из-за этого интерфейс работы с потоками "очень необычный".
> Им бы лучше сделать весь стейт интерпретатора в отдельной структуре как в lua, тогда написать нормальные потоки можно будет без проблем.
Не знаю как в lua, но в perl все уже давным-давно сделано нормально (покопайте perl.h). Потоки можно ввести без проблем хоть сейчас, но я еще раз спрашиваю - для чего?
> В perl две разные модели: 5005threads который deprecated и ithreads.Coro - the only real threads in perl
На самом деле perl легко ложится на pthread - там все уже есть для этого. Если нужен пример, то смотрите код modperl2 для httpd:> $ ldd /usr/lib/apache2/modules/mod_perl.so
...
libpthread.so.0 =>
...
Чем это лучше PHP?
<petrosyan>
Чем PHP.
</pertosyan>
Много вы читали здесь новостей о релизах перла с исправлением критических уязвимостей? А вот для пыха такие приходится выпускать каждые несколько месяцев. В этом вопросе он даже жабу обгоняет.
shellcode 0day By Design
> Чем это лучше PHP?Всем
Примерно тем же, чем мерседес лучше жигулей. Выполнить они могут примерно одинаковые задачи, вот только комфорт и безопасность различаются в разы. Аналогия распространяется и на стоимость обоих решений. Perl требует куда больших затрат, в отличии от пыха за 24 часа его не выучишь, но результат того стоит.