Perl. 27 лет спустя
Обычный программист знает о Perl только то, что язык мертв, , а код на нем нечитаем. Но программист на Perl часто не знает даже этого.
В каждой начинающей рок-группе должен быть Perl-программист, который бы демонстрацией своего кривого нечитаемого кода со сцены взывал к низменным инстинктам толпы, разогревая ее.
Дань стереотипам. Вопреки стереотипам Perl все еще существует. Он живет где-то на периферии сознания тех, кто не пишет на нем. Он вызывает у них сильное непонимание, когда они встречают тех, кто на нем пишет. Культура Perl настолько размазана по времени, настолько проникнута стабильностью языка, что человеку постороннему достаточно тяжело понять, что из себя представляет Perl сегодня. И как с ним нужно бороться. Несметное множество статей на просторах интернета описывают Perl тех времен, когда небо было зеленым, трава голубой, а Ельцин в пьяном угаре радовал страну зажигательными танцами перед телекамерами, задавая ритм рейверам, что танцевали на той голубой траве и под тем зеленым небом. И код из тех статей все еще компилируется. В результате у большинства программистов представление об этом языке представлено информацией 10–15… и даже 20 летней давности. Не следуют упускать из виду инерционность мышления тех, кто писал те статьи.
Поэтому сегодня я попытаюсь пролить свет на то, что же происходит с языком на его начинающемся 28 году жизни. Ведь сегодня у Perl день рождения — ему 27 лет. 20 лет из которых существует его пятая версия. Заходите, будет весело.
Он еще используется? Да, он еще используется. Согласно данным webtech, Perl по распространенности все еще занимает почетное пятое место среди языков на веб-серверах. Тут главное разыграть карту хорошего маркетолога и умолчать о том, что общая доля Perl всего 0.5%. Заметьте, питон в первую пятерку не вошел, а тем не менее считается языком гораздо более живым и распространенным. Все, больше никакого маркетинга. А что вообще создается и работает на Perl? Множество программного обеспечения, и простого, и сложного, и в том числе. используемого в веб. Perl в конце концов язык довольно широкого назначения и на нем можно встретить все — начиная от десктопных программ и серверов в телекомах, и заканчивая опостылевшими веб-сайтами. На перле написан Buzzfeed, сайт Комсомольской Правды, значительная часть кода сайта самого крупного регистратора доменных имен в СНГ Reg.ru, операторы отдела холодных звонков европейского отдела Vodafone выбирают очередную жертву навязчивой рекламы при помощи программы написанной на Perl… конечно же стоит упомянуть еще и DuckDuckGo, как известный многим сервис. К сожалению всего не упомянуть, столь много было создано на Perl, и веб — это лишь одна из областей его применения. Свободная лицензия Perl привела к тому, что он часто попадает в прошивки маршрутизаторов, и бог знает еще в какие коммерческие продукты. Трудно сказать насколько сильны позиции Perl в биоинформатике, учитывая сильную экспансию питона в эту область в течение последнего десятилетия, но он определенно активно используется и там.
Perl — это также огромное количество клея между инструментами, написанных на разных языках, нет, просто чудовищное количество этого клея. Это на нем так часто пишутся скрипты для импорта новых данных в старые программы на компилируемых языках, кода которых уже не найти. Для них же создаются скрипты-обертки и вообще графические интерфейсы, которые в свое время предусмотрены не были. В 2011 мне попадалась вакансия перловика для поддержки системы сборки крупного Java-проекта. Что может говорить нам как о полезности Perl, так и о том, что экосистема Java настолько переусложнена, что иногда проще держать в штате одного чернокнижника с Perl, чем двух специалистов по Maven…
Это на Perl часто пишутся скрипты для автоматизации, когда терпеть sh уже нет мочи, или же powershell кажется сомнительным вариантом. Количество однострочников, которые каждый день пишут на Perl системные администраторы всего мира, компенсируя несовершенство применяемых ими инструментов, просто не поддается исчислению. Несомненно, Perl вносит свою важную лепту в развитие такой отрасли как дорвеестроение, являясь важным инструментом черных сеошников. Считайте, что это была спаленая тема.
Глядя на вакансии, связанные с веб-разработкой, и особенно те, что появляются на фриланс-сайтах, может показаться, будто на Perl пишутся одни лишь грабберы с парсерами. Несколько более полное представление о том, что и кем пишется на Perl в сфере веб-разработки, можно получить тут и тут, и немного тут. Но никак не на фриланс-бирже.
Многие мелкие проекты пишутся на Perl в основном энтузиастами. Если бы им во время творческой горячки подсунули ноду — поверьте, они бы написали проект и на ноде. Так что такие проекты можно в расчет не принимать. А средние и крупные проекты существуют (и даже создаются!) на Perl по нескольким причинам, и энтузиасты тут ни при чем:
так исторически сложилось. Года до 2005 альтернативы у Perl не было, особенно в нише, когда PHP уже не хватало, а Java была уже перебором. при определенной сложности веб-проект разрастается до таких размеров, что выходит за рамки простого запроса-ответа. Появляется сложный запутанный бэкенд, где могут быть разные схемы кэширования, прегенерации контента, интеграции с системными инструментами. И на бэкенде появляется разные демоны, которые все это делают. А при всей демонизации PHP программистами на других языках, демоны на нем писать можно не все и далеко не всем. Подобная причина объясняет почему при гораздо более лучших веб-фреймворках некоторые проекты таки пишутся на Perl и Python. у вас есть тонны бизнес логики, корни которой уходят в шальные 90-е. Вы выдираете куски кода из старой программы на Tk, лепите их REST-серверу, и перлокод получает второе рождение. Прелесть такого подхода в том, что, ввиду высокой стабильности языка, изменения в коде обычно настолько минимальны, что вам самому может показаться, что Perl уже умер. подвид предыдущего пункта — Perl слишком хороший язык для прототипирования, не только за счет самого языка, но и за счет кучи модулей в CPAN. Поэтому с определенного момента прототип написанный на нем может тяжело вздохнуть и со скрипом полезть в серверную стойку ближайшего датацентра. заказчик потратил половину бюджета проекта на валидол после того услышал, сколько за указанный проект возьмут джависты. Не знаю почему, но у зарубежных заказчиков какое-то непонятное благоговение перед этим языком, и они часто готовы рассматривать его как альтернативу Java. Не с точки зрения функционала, в котором они по понятным причинам не разбираются, а с точки зрения репутации. в конце концов Perl полноценный язык программирования, в который постоянно привносится все лучшее из других языков, и в котором есть все необходимое для реализации почти любых насущных задач. Реанимация Perl долго терял свои позиции в области веб-разработки, не в последнюю очередь под давлением PHP. Ниша была немалой, но проигрыш языку, который намеренно создавался для веб-разрботки (во всяком случае той, какой она была в те дни), был довольно логичным. В конце концов Perl создавался несколько для другого. Но, несмотря на это в языке накапливались проблемы — нестандартное ООП все так же отпугивало многих, фреймворки для веб-разработки объективно проигрывали конкурентам в других языках, IDE сравнимого уровня просто не было (да и сейчас в принципе нет), стоимость программистов на Perl часто была выше, чем PHP-шников при сравнимой сложности проектов. Тогда я сам, признаться, верил, что Perl не смог адаптироваться и будет со временем вытеснен отовсюду, и вернется на свое историческое место инструмента для системного администрирования. Такая ситуация была примерно до 2008 года, хотя это и моя субъективная оценка. Затем пошел хайп на Python. Данный язык мог полностью заменить Perl в нише биоинформатики, сложных веб-систем, системного программирования для юниксов (для меня кстати всегда было загадкой, почему под термином «системное программирование» в мире Windows понимается сношения с ядром и написание драйверов, а в мире юникс под этим обычно подразумеваются всякие сервисные скрипты). И с той мощной поддержкой и энтузиазмом возникшими вокруг питона, будь на его месте Cobol, и попадись он столь же вовремя под руку Google — результат был бы тот же. Также эта отмашка от гугла дала добро на использование скриптовых языков всем фанатам языков компилируемых, считавших доселе, что трогать скрипты выше их достоинства (по другим источникам — разумения). И тут выяснилось, что Python решает важную проблему из Computer Science, которая формулируется как «Even your Mom handles strings better than your compiled language». Важность этой проблемы тяжело переоценить, а потому не стоит обвинять в излишнем восторге тех, кто открыл для себя Python, и пытался всячески его навязать другим.
Но по иронии именно Python и дал Perl шанс на развитие. Кроме Django в питоне не было full-stack фреймворков, а Django настолько хорошо подходил для создания новостных сайтов, что скоро новостных сайтов, написанных не нем, стало больше, чем значимых новостей происходящих в мире ежедневно. Тут-то и выяснилось, что далеко не все сайты должны быть новостными и написаны с использованием Django. Сказано — сделано. Появился тренд на микрофреймворки вроде Flask, Pyrmaid, Bottle.py (да простят мне питонщики столь вольную трактовку термина «микрофреймворк»). Возможно дело тут было так же в том, что росла популярность REST сервисов, а питон тут и вовсе не при чем, но микрофреймворки пошли в оборот.
В Perl помимо Catalyst появились фреймворки второй волны: Mojolicious, Dancer и Jifty. По фулстэковости они все еще не дотягивали до полновесных PHP-шных Zend или CodeIgniter, но на фоне питоновских микрофреймворков смотрелись вполне пристойно. А главное это был показатель того, что сообщество таки реагирует на вызовы современности.
При этом часть сообщества активно металась между Perl, Ruby и Python, таская фичи оттуда. И не только фичи, а вообще стилистику и хорошие практики. В тот период особенно четко обозначился раскол Perl-сообщества на 2 группы — собственно тех, кто хочет вытянуть Perl из этого болота, и тех, кто привык писать в лучших традиция Perl 5(Perl 5.0 вышел в октябре 1994). И последних даже нельзя упрекнуть — среди них достаточно много системных администраторов, для которых Perl был идеальным в том виде, в каком он существовал в 1994. Такое расслоение частенько видно на конференциях, где вслед за докладом о том как кто-то написал на Perl удобный скрипт, который отсылает ему на SMS новые лоты с eBay, идет доклад о проблемах сложной инфраструктуры с использованием Corona, очередей сообщений, собственного CPAN-репозитория и прочих страшных вещей.
Но в целом ситуация улучшается, и Perl уже преодолел ту точку, когда был возможен окончательный срыв в стагнацию. Сообщество таки признает свои проблемы и видны пути их решения. Конечно, ресурсов не хватает — в прошлогоднем докладе на одном из YAPC проскакивала информация о том, что весь С-шный код интерпретатора понимают буквально пара человек, а еще 15 могут разбираться в своих подсистемах. Не надо драматизировать эти цифры — они занимаются этим практически бесплатно, а много ли желающих копаться в старом С-коде, а особенно в кишках интерпретатора целого здорового языка, когда одно из ключевых требований — не ломать совместимость?
Конечно, в Perl не будет такой хорошей IDE как для PHP или Python, потому что нет такой большой коммерческой поддержки с одной стороны, и нет той простоты синтаксиса, которая бы легко позволила создавать парсеры Perl, которые необходимы в каждой сколько-то серьезной IDE. Да и даже будь они, нагонять придется долго — фактически IDEA и Microsoft являются монополистами на рынке IDE, они задали такой стандарт качества поддержки языка, что даже Eclipse, обладающий огромным сообществом сдает позиции. Также ввиду того, что Perl не является сугубо веб-ориентированным языком, та концентрация усилий на веб-фреймворках, которая имеет место в случае PHP, просто невозможна. Но с учетом того, что повсеместно набирает популярность толстый фронтенд, это не так страшно.
Что касается Perl6, то он может как дать второе дыхание языку, так и сыграть с ним злую шутку, как в свое время третья ветка питона, длительное время игнорируемая сообществом ввиду нежелания многих авторов переписывать питоновские библиотеки под новую версию. С другой стороны Perl6 решает важную проблему пятой ветки — наконец появилась спецификация языка, по которой кем угодно может быть написан компилятор, что, во-первых, упростит жизнь разработчикам IDE, во-вторых, позволяет уже сегодня запускать программы Perl6 на нескольких бэкендах, в т.ч. JVM.
Сейчас прогноз для Perl стабильно-положительный. Не забывайте, что до Perl взлеты переживали и Python и Ruby, и в итоге шум спадал, а языки прочно занимали ту нишу, в которой они правда применимы. Осталось дождаться пока тоже самое произойдет с Javascript…
Мифология Perl еще долго будет рассматриваться посторонними не с точки зрения текущей ситуации, а с точки зрения мифов о нем, которые гуляют в сети. Как правило эти мифы затрагивают нечитаемость кода, важность регулярных выражений, моральное устаревание языка, CPAN, Perl6, который очевидно будет нулевым всадником апокалипсиса. Ну и конечно самый главный — о том, что язык мертв.Его величество нечитаемость По заявлением тех, кто жаловался на нечитаемость Perl можно выделить несколько основных проблем: Непонимание зачем нужен unless, этот if с инвертированным условием. Непонимание регулярных выражений. К сожалению те, кто ленятся разобраться как же именно работают регулярные выражение, будут не рады им в любом языке. Двойные сигилы вида $,@,% в конструкциях вида %{$self→{'posts'}} или же @$posts, в которых жалующиеся видят нечто большее нежели простое приведение типов. Вот этот код: echo «test… test… test…» | perl -e '$? s:; s: s;;$?:: s;;=]=>%-{<-|}<&|\`{;;y;-/:-@\-`{-};\`-{/" -;;s;;$_;see' Но зачем жаловаться на обфусцированный код, когда иные языки возводят обфускацию кода в ранг полезной, а то и обязательной к применению технологии? Отсутствие документации в коде. Дело в том, что часто не принято писать документацию функций в стиле Javadoc — перед каждой функцией. В итоге вся красиво оформленная портянка, документирующая модуль, выносится либо в начало либо в конец модуля. Perl дает такую свободу. Некоторые программисты чувствуют себя настолько свободными, что не пишут документацию вовсе. Куча специальных кавычек и неявных переменных. Тут есть тонкость: вместо таблицы значений переменных следует составить таблицу имен переменных, и тогда все встанет на своих места. Несмотря на непривычность синтаксиса относительно многих других языков, мне кажется что главная причина неприятия к нему скрывается в тех темных временах, когда Perl был популярен, а вот правила хорошего тона в написании кода популярны не были. В те времена много на каких языках создавался такой код, что чтению поддается с трудом. Но на Perl этого кода создавалось больше. Вдумайтесь в этот абзац, это не «на любом языке можно писать плохой код». Задайте себе вопрос, а могла ли отрасль удовлетворить потребности в хороших веб-программистах в 1990-х годах или в начале 2000-х? Или же может быть тогда в веб(и как следствие в Perl) за деньгами лезли все, как сейчас лезут в мобильную разработку, загаживая мусором AppStore и PlayMarket? Ruby позволяет создавать на базе себя новый язык(DSL), который будет работать. Perl же в этом плане выбрал несколько другой путь — пока вы пишите на любом языке, интерпретатор будет считать, что вы пишите на Perl. С одной стороны вам не нужно как в случае Ruby описывать свой DSL, с другой — интерпретатор может уловить в вашем коде больше смысла, чем другие программисты, обреченные в будущем поддерживать этот код. Чтобы бороться с этим существуют код-стандарты, призванные всячески угнетать творческий потенциал пишущих на Perl. И, как бы тяжело мне ни было это признавать, но они работают, правда работают по большей части в коммерческих компаниях. Это удивительно, но код среднего Perl-проекта на гитхабе выглядит хуже, чем код какого-нибудь коммерческого проекта с закрытым кодом.
То, насколько сильна в языке обратная совместимость, заставляет думать, что однажды код написанный в 2004 перестанет работать году так в 2024 и выплывет таки наружу. На радость археологам и перло-ненавистникам.
ООП В Perl есть 3 проблемы связанные с ООП: отсутствие в стандартной поставке привычного для многих синтаксиса ООП отсутствие понимания какой выбрать модуль для поддержки привычного для многих синтаксиса ООП отсутствие общепринятой методички (как в случае Javascript) с алгоритмом объяснения оппонентам почему первые 2 проблемы — и не проблемы вовсе Но в этом году наконец наметился некоторый прогресс — сообщество согласилось с необходимостью наличия в стандартной поставке языка унифицированной системы ООП, которая бы во-первых не вгоняла в ступор новичков, а во-вторых была бы совместима со всеми существующими реализациями ООП. Подробнее почитать можно здесь. Чем-то ситуация сходна с Javascript — только в его случае мы лепим костыли к прототипу функции, чтобы изобразить объект. А в случае Perl мы лепим конструктор к пакету (или модулю, если вам привычней), превращая его в класс. Финал один — сторонники традиционного ООП не наблюдают стандартной инкапсуляции и полиморфизма, зато мы наблюдаем прострацию и фалломорфизм сторонников. Но не легче от этого никому. У Perl в отличие от Javascript сегодня нет той востребованности, чтобы ему прощали мелкие огрехи. Но мы прощаем — почти во всех крупных проектах, что мне попадались, используется стандартное для Perl ООП на базе пакетов, а не одна из библиотек.
Вообще ООП в Perl стандартное — и именно поэтому делать реализацию с привычным синтаксисом многие мейнтейнеры интерпретатора не видят смысла. Чтобы вы представляли разницу с Javascript — мы не обвешиваем несчастную функцию другими функциями, чтобы получить видимость класса. Мы не патчим прототип функции другой функцией, чтобы получить наследование. В Perl мы создаем пакет (модуль), а дальше у нас есть выбор — импортировать функции из него как из модуля, или добавить в модуль конструктор и использовать его как класс. Ну, а если нам нужно наследование, то для этого есть встроенные средства языка, предназначенные именно для этого. С другой стороны объявление классов в Perl самое многословное среди всех языков, с третьей стороны найти в 2014 году редактор без сниппетов становится все сложнее и сложнее.
Кстати об объектах — Perl один (если вы считаете, что PHP тоже язык общего назначения, то не один, но бог вам судья) из немногих оставшихся скриптовых языков общего назначения, где простые типы данных вроде строк, чисел, массивов и хэшей сделаны не в виде стандартных объектов, а в виде встроенных типов. И это с одной стороны нравится тем, кто любит простоту, с другой стороны затрудняет цепочечные вызовы функций.
CPAN Когда-то важнейшее преимущество Perl, а теперь всего лишь необходимый атрибут, чтобы быть не хуже других языков. Но атрибут не самый плохой из имеющихся. По сравнению с Python, Ruby, Javascript, здесь меньше… хипстеров. Да, да, тех самых ребят столь жаждущих прославить себя на гитхабе. А потом закрепить свою славу в репозиториях пакетов выбранного ими языка. В CPAN таких намного меньше, ведь какой смысл пиариться и набивать строчки в резюме для непопулярного языка. Может быть я не прав, но вы правда верите, что все 110 000 пакетов в npm для веб-ориентированного языка являются полезными и качественными? Даже если предположить, что из-за ноды Javascript стал использоваться не только в вебе, и все эти модули правда полезные вещи или на худой конец байндинги к имеющимся библиотекам, то это же просто минное поле. Физически невозможно вылизать такое большое количество кода от разных людей за столь короткий срок. Конкретные цифры по статистике количества модулей для разных языков приводятся в http://www.modulecounts.com/. И видя, что Perl находится в самом низу среди остальных языков, я, как заинтересованное лицо, попробую придумать утешительные объяснения на этот счет. Во-первых, если глянуть на сам CPAN, то модулей там все-таки, больше 140 000. А вот дистрибутивов (коллекция модулей часто, но не всегда, зависящих друг от друга) и правда около 30 000. Т.е. по количеству модулей CPAN все еще лидирует. Модулей в смысле единиц кода, который могут быть подключены и использованы сам по себе. Например есть 2 модуля LWP и LWP: Simple — оба входят в дистрибутив libwww-perl. При этом каждый модуль может быть использован сам по себе и предоставляет разный интерфейс для работы с ним. Хотя модули могут иметь общие зависимости или зависеть один от другого. Но допустим считать именно модули вне дистрибутивов плохая идея (хотя каким образом производится подсчет в репозиториях других языков я могу только догадываться, и у меня есть подозрения, что там могут считаться даже форки), и рассмотрим другие языки.
С Javascript мы вроде разобрались. С Go ситуация такова, что там попадаются может быть несколько версий одного пакета, судя по индексу, а также *-dev версии. В Python часто принято оформлять как пакет не только библиотеки, но и многие приложения, скрипты. Да, такое есть во всех репозиториях, но в питоне такое попадается мне чаще. Но все же, думаю, что цифры для питона близки к реальности, особенно учитывая, что питон — язык общего назначения да еще и с хорошей репутацией. Хотя не понятен момент как считаются пакеты для 2-ой и 3-ей версий. Что касается Ruby, то все уже расписано. Также данный сайт не показывает количество правок и обновлений к уже имеющимся пакетам. Даже не глядя на ситуацию у других языков, в случае CPAN обновлений много, часто больше сотни в день. За 5 декабря — 194 обновленных модуля в сутки. Мертвые языки так себя не ведут.
В общем CPAN все еще хорош. Он настолько хорош, что это единственный из репозиториев, при установке пакетов из которого я не начинаю нервничать, думая, что что-то сломается в процессе.
Вакансии Хотя принято считать, что все Perl-программисты сидят без работы, работа на нем есть. Однако есть 2 «но»: во-первых, перловики-джуниоры мало кому нужны, во-вторых, большая часть работы на Perl подразумевает работу в офисе. Т.е. на фрилансе проектов мало и обычно (особенно в рунете) это низкооплачиваемая параша. Да-да именно так, под словом «низкооплачиваемая» я понимаю редкие сдельные проекты стоимостью от 10 до 200 долларов. Под словом «параша» я имею ввиду, что работать вам придется по большей части с людьми, которые хотят либо парсер чужих сайтов, при этом обычно парсер выходит в итоге интеллектуальней заказчика, либо же вы будете делать правки к кастомной CMS (или веб-магазину), которая годами и десятилетиями играет в прятки. И поверьте, лучше бы она в этой игре и с вами вышла победителем. Есть некоторые компании, готовые платить вам за перлокод удаленно. Как минимум это oDesk и Buzzfeed. Но вообще их мало. И почасовые ставки там не самые высокие — в основном 15–20$/час. Проекты же выше 30$/час найти тяжело — вас будут силой тащить в офис или отказываться от ваших услуг. При этом продавать себя за 50$/час на том же oDesk реально, но это будет эпизодическая работа. Очень эпизодическая. Наверное этот абзац справедлив для почти любого языка… Найти удаленную работу с оплатой до 2500 $ не так сложно, сложности возникнут когда вы захотите больше. В СНГ мне не удавалось получать удаленную работу с оплатой более 1500 $, может быть получится у вас.
Но не все так печально, если оторвать задницу от любимого кресла, чтобы обменять его на кресло офисное. Оффлайн-работа на Perl есть как у нас, так и за границей. За границей ее, к слову, особенно много, но не надейтесь, что вас расцелуют в десна и побегут оформлять визу H1-B. Хотя и такие работодатели встречаются. В общем смотрите сами. Будет интересно, если кто-то из читателей в комментариях расскажет, если у него все удачно сложилось и с зарубежными компаниями и с Perl одновременно.
Если загнивающий запад вам противен, у нас тоже можно поработать перловиком. Порою даже в регионах. Помните CMS, которые играют в прятки? Так вот вы сможете узнать не только когда она спряталась, но и где ее логово, а может быть даже перекинетесь словцом с ее раскаявшимся создателем. И, конечно же, в регионах есть бодишопы, в которых порой нужны перловики.
В столицах находится наше вечное все — mail.ru, yandex, reg.ru. Наша надежда и опора, живое напоминание того, что Perl все еще нужен. Если вы увидите кого-то на YAPC или Perl Workshop и он разговаривает на русском, то с 90% вероятностью этот докладчик работает где-то в этой тройке. От себя рекомендую reg.ru — приятное собеседование, программисты — профессионалы, каких мало, а также вместо богохульного Skype используется SIP.
Безусловно, сейчас Perl — это не потолок зарплат, но, по сравнению с другими языками, зарплаты на нем начинаются со среднего уровня. Т.е. вы можете устроиться джуниором PHP-шником или RoR-овцем за 500$(москвичи, молчать!), а для Perl такой вакансии скорее всего не найдется с одной стороны, а с другой требования к миддлу-перловику будут ниже, чем для упомянутых языков. Резюмируя, на Perl работы меньше, чем на многих других языках, но работа это ищется в условиях меньшей нервотрепки — у вас сразу будут нормальные вакансии. И делать на Perl ставку как, но основной инструмент удаленного заработка пожалуй не стоит, во всяком случае поначалу.
Веб-разработка Писать в наше время веб-сайты на Perl если не грешно, то несуразно уж точно. Так думают многие. И отчасти это верно: даже вся красота Perl не способна компенсировать то несметное множество человеко-часов, которое нужно вложить в веб-фреймворк, чтобы получить нечто, с чем было бы продуктивно работать. И, замечу, все языки маргинальнее PHP, а именно Ruby и Python имеют всего по одному такому монстру. Mojolicious, Dancer (?) и Catalyst — вот 3 кита на которых держится современная веб-разработка на Perl. Еще в темных глубинах океана скрываются монстры вроде Maypole и Mason, но на них нарваться можно редко. И, работая с ними, есть риск озолотиться или потерять рассудок. А часто — и то и другое. Но все это немного не то, к чему вы привыкли в других языках, снискавших себе расположение божка веб-программирования.
В Perl нет интегрированных решений такого уровня как Django, Symfony, RoR. Есть либо микрофреймворки, которые в принципе одинаковы во всех языках, либо Catalyst — тяжелый фреймворк, который более менее соответствует представлениям о том, каким должен быть типовой fullstack MVC-фреймворк для веба. Но вы сами выбираете способ отправки почты, ORM, тестовый фреймворк и т.п. Пусть даже в случае Catalyst у вас будет рекомендуемый ORM, движок шаблонов, но скорее всего в итоге вы обвешаете его кучей всяких вещей, создавая нечто свое. Не существует двух похожих проектов в разных компаниях, которые были бы написаны на Catalyst. И у вас не будет того количества гемов или бандлов, которое есть для RoR и Symfony.
Интеграция с клиентским кодом, работа с ассетами — в мире Perl все это тоже не подвержено модным веяниям. Вы делаете это как вам заблагорассудится — бывают и такие, кто использует rake с нужными гемами в проектах на Mojolicious. Другое дело, что если вы будете дергать yui-compressor через make-файл, то в Perl мире это будет нормой, а в случае какого-нибудь RoR за такое можно и получить по рукам.
С одной стороны это все дает полное право говорить об отсталости Perl. С другой стороны, после 3-х лет работы с Symfony и ее прокрустовыми гайдами, я уже не уверен, какой подход к веб-разработке есть меньшее зло. Хороший фреймворк рано или поздно встанет вам поперек работы. У него есть целых два способа сделать это: быть слишком негибким, чтобы вы возопили в попытках вписаться в него, либо же быть достаточно гибким, чтобы вы взвыли от слабой связанности и размазанности алгоритмов по коду.
Для тех, кто привык к фреймворкам PHP, главная проблема веб-разработки на Perl заключается в том, что вы не можете скачать архив с фреймворком, распаковать, и пихать свой код в папочку src. Вы должны выбрать как вы будете работать с базой — через ORM или запросами, как генерировать формы — руками или используя FormFu, и уже от этого будет определяться на что станет похоже ваше веб-приложение. Это не так страшно — разобраться в чужих проектах на том же Catalyst или Mojolicious несложно, независимо от того, какие модули туда напиханы. Но для программистов на других языках такой подход будет непривычным.
Сегодня большая часть веб-разработки — это конструктор. Прикрутить регистрацию через соцсети (желательно через все сразу), добавить кнопочки лайков этих же соц. сетей, приделать интеграцию с платежными системами, добавить веб-чат, и т.п. Конечно тут важен даже не язык, а наличие готовых SDK, модулей, рецептов. Perl тут однозначно проигрывает, и делать многие типы сайтов на нем не всегда целесообразно. Еще раз, что бы вы прочувствовали — Perl отстает от PHP в том же плане как фреймворк отстает от CMS. Фреймворк может быть безопаснее, быстрее, приятнее для программирования, но в CMS часть работы уже реализована, это сэкономленные человеко-часы. Но если в проекте присутствует хоть какая-то сложная логика и вы не планируете на каждый вызов производительности отвечать горизонтальным масштабированием, то Perl все еще хорошо себя показывает.
Правда набивать деньги массовостью можно и на Perl — в рунете полно умельцев, которые имеют свои фреймворки (обычно уровня FatFree), и которые готовы выдавать типовые сайты на них пачками, и в автоматическом режиме деплоить их на самый прощелыжный shared-хостинг, который и сам себя не всегда поддерживает, не то что сайт, расположенный на нем.
Perl 6 Создатель языка Larry Wall любит будоражить народ скорым выходом шестой версии языка. Практически каждый год. А началось это около 2000-ного года. Perl6 выйдет к рождеству, любил говорить он, но по прошествии рождества он ссылается на то, что конкретный год им указан не был. Однако в этот раз он превзошел себя и осмелился сказать больше обычного. Так что может быть в новом году все будет по новому. И учитывая степень покрытия спецификаций языка реализацией, может быть в 2015 мы правда увидим Perl6. В пользу этого также говорит тот факт, что кроме Parrot долгое время Perl6 не поддерживал других бакендов, а в последние несколько лет появились C# и JVM бэкенды. И более того, появился бэкенд на базе MoarVM, которая вроде как учитывает недостатки виртуальной машины Parrot. И с большой долей вероятности именно бэкенд на MoarVM станет стандартным для Perl6.
Perl6 не совместим с Perl5. Синтаксис во многом похож, идеи тоже, но это другой язык. И даже если он будет выпущен в продакшн в следующем году, и даже если удастся добиться производительности уровня пятой версии, обрастание модулями будет долгим. Тем не менее есть надежда, что можно будет использовать модули Perl5 из Perl6. Вернее делать это можно уже сейчас: https://github.com/niner/Inline-Perl5/. Но массово эта технология еще не испытывалась, поэтому тяжело говорить о ее применимости в реальных условиях.
С точки зрения массового программиста Perl6 правда лучше предыдущей версии — не нужно будет лепить %,@ перед разными типами переменных, появится привычное ООП, станут наконец доступными вызовы методов у простых типов. Правда для того же массового программиста в случае выхода Perl6 мало что изменится — пятая ветка никуда не денется, как и код на ней.
Сообщество У Perl большое сообщество. Слишком большое, непростительно большое для мертвого языка сообщество. Более того у отдельных крупных библиотек есть свои группы поддержки, не говоря уже о фреймворках. Обычно помощь можно получить через списки рассылки или же на irc сервере irc.Perl.org, конечно это не отменяет наличие каналов посвященных Perl на Freenode. Да, в наш век irc и списки рассылки выглядят довольно устаревшими, но нет, это замечательные способы организовывать массы людей. Благодаря спискам рассылки легко находить решения проблем, которые были решены еще 10 лет назад, а благодаря IRC можно пообщаться с людьми, которые писали на Perl еще 20 лет назад. Просто смиритесь, что львиная доля активных членов Open Source сообществ все еще сидит в IRC. Людей в сообществе Perl настолько много, что поневоле задумываешься, где же они все трудоустроены, если на Perl нет работы. Спишем это на опущение, что Perl настолько хороший язык, что множество людей пишет на нем для души. Или от безысходности — в виду его наличия во многих legacy-программах и компонентах UNIX-систем. Есть особый слой людей, которые больше тяготеют к культуре Perl, чем к программированию на самом языке. Да, у нас тоже есть фанбои. Но назвать их мальчиками язык уже не повернется.
Кстати найти программистов на Perl довольно просто. Найти хороших программистов на Perl (как и на всяком другом языке) не так-то просто. Найти хороших Perl-программистов на irc.perl.org и получить от них помощь — проще простого. У нас все еще существует (во всяком случае в СНГ) достаточно большой процент людей, которые таки начинали с Perl 10 лет назад и таки используют его до сих пор, а также таки пишут на нем так, как было принято 10 лет назад. Как правило они сидят на фрилансе и пишут те самые грабберы и парсеры или сайты с использованием старого доброго CGI. И эти люди тоже могут давать советы, и эти советы будут работать! Ну что поделаешь, если язык стабильный. А к советам перловиков из рунета (например к моим) надо относиться очень скептически — такой совет, будучи вовремя применен, может помочь не только решить проблему, но и вылететь с собеседования, после выполнения всех заданий.
Есть еще perlmon
