Мастер сельского афоризму
0,2
рейтинг
18 декабря 2014 в 00:32

Разработка → Perl. 27 лет спустя

Perl*
                              Обычный программист знает о Perl только то, что язык мертв, 
                              а код на нем нечитаем. Но программист на Perl часто не знает даже этого.

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

                              Дань стереотипам.

    Вопреки стереотипам Perl все еще существует. Он живет где-то на периферии сознания тех, кто не пишет на нем. Он вызывает у них сильное непонимание, когда они встречают тех, кто на нем пишет. Культура Perl настолько размазана по времени, настолько проникнута стабильностью языка, что человеку постороннему достаточно тяжело понять, что из себя представляет Perl сегодня. И как с ним нужно бороться.

    Несметное множество статей на просторах интернета описывают Perl тех времен, когда небо было зеленым, трава голубой, а Ельцин в пьяном угаре радовал страну зажигательными танцами перед телекамерами, задавая ритм рейверам, что танцевали на той голубой траве и под тем зеленым небом. И код из тех статей все еще компилируется. В результате у большинства программистов представление об этом языке представлено информацией 10-15… и даже 20 летней давности. Не следуют упускать из виду инерционность мышления тех, кто писал те статьи.

    Поэтому сегодня я попытаюсь пролить свет на то, что же происходит с языком на его начинающемся 28 году жизни. Ведь сегодня у Perl день рождения — ему 27 лет. 20 лет из которых существует его пятая версия. Заходите, будет весело.

Он еще используется?


    Да, он еще используется. Согласно данным webtech, Perl по распространенности все еще занимает почетное шестое место среди языков на веб-серверах, почему-то проигрывая ColdFusion, но зато выигрывая у Python. Тут главное разыграть карту хорошего маркетолога и умолчать о том, что общая доля 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. И эти люди тоже могут давать советы, и эти советы будут работать! Ну что поделаешь, если язык стабильный. А к советам перловиков из рунета(например к моим) надо относиться очень скептически — такой совет, будучи вовремя применен, может помочь не только решить проблему, но и вылететь с собеседования, после выполнения всех заданий.

    Есть еще perlmonks.org. Если по каким-то причинам stackoverflow будет заблокирован Роскомнадзором, то можно будет поискать ответ на свой вопрос там. Нет, это не плохой сайт, просто там обычно мало информации про веб-разработку.

    Сообщество Perl чем-то притягивает, хотя новичков тут все равно мало, но при этом много хороших людей. Хорошо налажена система слетов и конференций, множество их проводится по всему миру. У многих докладчиков хорошее чувство юмора, обычно незлого и неофисного(а офисный юмор — есть выхолощенная злостью и условно оприличенная пошлость), такого что во время выступления не хочется встать и выйти или выключить плеер. Иной, пусть даже технически неинтересный, доклад хорошо идет под тарелку макарон субботним вечером. В сообществе мало пустых споров и агрессии по отношению к сообществам других языков. Из-за того, что хороших перловиков мало, вы скоро увидите, что на всех конференциях в СНГ постоянно мелькают одни и те же лица, так например в августе в Украине был замечен даже сам Larry Wall.

Стоит ли учить Perl?


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

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

    Если вы хотите быстрых и легких денег, то Perl вам не нужен. Хотя в Москве могут и найтись люди, которые будут выкармливать джуниора. Если вы готовы потратить пару-тройку лет и хотите больших денег, то стоит попробовать. Количество legacy-кода на Perl огромно, особенно на западе.

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

    Если вы только начинаете учить программирование, то советую вам ознакомиться с Perl, как с языком, который сочетает в себе несколько парадигм. Даже если вас воротит от синтаксиса самого Perl, советую прочитать Programming Perl, пусть даже на русском: Программирование на Perl, 4-е издание. Просто потому что книга затрагивает кучу других вещей, вроде философии Unix, сетевого программирования, параллельного программирования, концепции регулярных выражений. Эта книга — введение во все то, с чем вы столкнетесь в будущем даже на других языках, причем написана она в том же стиле, что и эта статья.

    Если вы программист на компилируемом языке, или работаете с микроконтроллерами, но не планируете лезть в веб, то однозначно стоит изучить Perl — даже на минимальном уровне владения им у вас появится мощный инструмент для кодогенерации и всяких мелких сборочных скриптов. Генерация портянок if/switch для драйверов по таблицам из документации, таблиц конечных автоматов и т.д.

    Если вы планируете всерьез заниматься сетевым программированием, то Perl может быть вам полезен как минимум для прототипирования, создания тестового траффика и серверов-заглушек.

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

Так почему Perl а не что-то другое?


    Каждый решает для себя сам. Что же лично мне нравится в Perl, среди более-менее доказуемых вещей:

  • Отдельные операторы для сравнения и конкатенации как для строк, так и для чисел

  • Широкая трактовка false: "", 0, undef, () взаимозаменяемы в разумных пределах, без драконовских сравнений при помощи === как в Javascript и PHP

  • Строгий синтаксис, в реальных проектах он правда строгий, вы не найдете там тех ужасов, которые, как принято считать, имеют место в каждой Perl-программе.

  • Объявление переменных с указанием области видимости, а также локализация внешних переменных внутре блока.

  • Подход к документированию модулей CPAN — обычно для того, чтобы пользоваться модулем достаточно прочесть секцию Synopsis.

  • Удобное присваивание в списочном контексте.

  • Работа с юникодом — иногда мне кажется, что мейнтейнеры Perl в первую очередь вылизывают ее, а все остальное уже делают по остаточному принципу.

  • Неявная переменная $_, как this из Javascript, только удобнее. Потому что $_ в отличие от this можно не использовать.

  • Идеальная подборка функций, которые не надо импортировать, работа с файлами, регулярки, дата, рандом, обход каталогов, sleep, printf...

  • Простота языка — можно писать на небольшом подмножестве синтаксиса.

  • Можно писать в стилистике близкой к PHP и код будет соответствовать общепринятым на сегодняшний день представлениям о том, как должен выглядеть код.

  • Однострочники, запускаемые в командной строке. Да, эта возможность есть почти у всех интерпретаторов других языков, но тут все продумано и удобно.

  • POD, оно смотрится красиво, оно выглядит как документация. А не как аннотация типа Javadoc.

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

  • Отсутствие сигнатур аргументов позволяет не делать рефакторинг всех вызовов подпрограммы, а просто проверять в подпрограмме был ли передан аргумент.

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

  • Конференции, много конференций. Одна история удивительней другой.

  • У нас есть целый ежемесячный журнал на русском языке, посвященный Perl

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

  • Стабильность языка сравнима разве что с С и Java.

  • Простой деплой через копирование кода через проводник. Сложный деплой через свой CPAN репозиторий. Новомодный деплой через Carton. Старческий деплой через Makefile. И все приемлемо сообществом.

  • Приятные собеседования. Чаще всего предлагают тестовые задания или ведут общие разговоры. Никакой зубодробительной ботаники.

  • Среди коллег мало молодых и восторженных. В основном люди просто делают свою работу.

  • Культура, проповедующая множество способов сделать одну и ту же вещь, устраняет в команде многие конфликты.


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

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

В заключение


    Сколько кота в нос не целуй — он все равно пританцовывает.

@PerlPower
карма
167,0
рейтинг 0,2
Мастер сельского афоризму
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (150)

  • 0
    а что за проблема «Even your Mom handles strings better than your compiled language?
    • +1
      Это комплекс неудобств, заключающийся в необходимости контроля размеров буфферов, обязательным приведением типов, сложной работой с кодировками, а также маленькие проблемы вида необходимости использовать StringBuilder вместо String в Java, когда нужно прибегнуть к многократной конкатенации.
      • 0
        1)Из известных мне компилируемых языков контролировать размер буфера вручную приходится только в C. В том же C++ никто не заставляет работать с char* напрямую, когда есть хорошо обернутый std::string, например, разве что когда нужно выжать максимум производительности.
        2)В C/C++ тип char является числовым, там как раз приведение типов не нужно (что влечет некоторые ошибки в неумелых руках). Python имеет строгую типизацию, приведение типов обязательно. В то же время, типизация в Python динамическая, точно так же, как и в Perl.
        3)Четкое разделение пачки байт с бирочкой "<имя кодировки>" и массива сущностей вида «Greek Capital Letter Upsilon» в Python – это торжество абстракции «символ» над абстракцией «числовой код» и причина создания универсального вида кодеков, за что большое спасибо Гвидо.

        Во всех трех пунктах я так и не понял, почему виновата компилируемость языка, а не забывчивость разработчиков добавить нормальную поддержку кодировок.
        • 0
          ИМХО компилируемость языка тут не при чем, это именно «забывчивость». Но никто ж не будет спорить что быстрее и проще написать парсер на Перле / Питоне чем даже на С++?
          • 0
            Да, никто. Просто нехорошо подменять понятия.
            • 0
              Ну а где тут подмена? «Even your Mom handles strings better than ...» Что?
    • +2
      Намек на то, что среднестатистическая мама лучше носит стринги, нежели обрабатывает строки.
  • +8
    Какой слог, прям аж ностальгические слёзы наворачиваются :)

    Пойду покопаюсь в своих архивах, а то последний раз писал на перле чего-то 14 (боже!) лет назад, не знаю даже, смогу ли прочесть и понять, что это было.
  • +5
    Спасибо за интересную статью!

    Я начал (неожиданно для себя) программировать на Perl два месяца назад, когда вышел на работу в Booking.com. Вакансия называлась Software Developer – (Willing to learn Perl). Само название вакансии как бы намекает на то, что найти разработчика со знанием Perl не так легко. При этом условия работы чуть более чем отличные. В компании можно встретить людей с практически любым бэкграундом. Тем не менее, большая часть проекта написана на этом языке. Есть люди с огромным опытом разработки именно на перле (в том числе разработчики самого языка) и при этом открытые для общения. Это помогает.

    Естественно, все понимают и достоинства и недостатки перла (как и других языков). Но в результате побеждает прагматизм. Б`ольшая часть логики — это if-ы и циклы. Они в большинстве языков выглядят одинаково. В конце концов, мы решаем конкретные задачи, а не занимаемся каллиграфией. Меня больше увлекает не язык, а то, что с его помощью я делаю. Перл позволяет писать +- удобно модифицируемый код (хотя не все этим пользуются), и этого для меня достаточно.

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

    Почему-то вспомнилась «Книга пяти колец» Миямото Мусаси. В частности, «Книга четвёртая: Ветра». Рекомендую к прочтению.
    • –1
      Расскажите, а нафига они так за него держатся, у них вообще нет других языков в стеке технологий?
      С чисто прагматичной точки зрения всегда можно выделить сервисы, особенно новые, и написать их на чем угодно, в этом суть SOA. Или там монолитная архитектура, которую не разделить?
      • +1
        Я бывал на собеседовании на эту вакансию, но не позвали, к сожалению, после последнего этапа. ) Вопрос, почему держатся за перл я задавал. Ответ был, в принципе, ожидаемый — огромный действующий проект с миллионами посетителей, который работает уже десяток лет. И да, бОльшая часть их кода — это Перл. Переписывать его на какую-то другую технологию будет стоить очень дорого, займет очень много времени и смысла на данном этапе развития уже в этом нет.
      • +3
        В штате Booking есть разработчики языка Perl. Поэтому Booking имеет возможность развивать Perl в нужном им русле. Вносить оптимизации и улучшения критических для них функций. Это уже не говоря про ежегодные чеки для PerlFoundation и т.д. Это также положительно влияет на имидж компании среди perl-овиков. Так что Booking'у очень хорошо во всех смыслах: подпиливают язык под свои нужды, разработчики сами ломятся к ним работать. Зачем это всё ломать?
        • –3
          Автор же написал — потому, что трудно нанимать новых людей, мало людей на рынке, он сам не горел желанием его изучать, но пришлось.
          Получается, в компании образовалась такая секта старых маразматиков опытных девелоперов, которая вовлекает в свои ряды новых членов путем их покупки из менее благополучных мест и принуждения к Perl. Это грустно, на самом деле.
      • +2
        По той же причине, по которой Facebook держится за PHP. Архитектура не может быть монолитной в +- распределенном приложении. С точки зрения разработчика всегда веселее использовать новые технологии, но эта практика работает только в стартапах (часто с большим количеством риска, и то не всегда). Если начать думать об этом с точки зрения бизнеса, то первым делом встает вопрос «зачем?». И желательно иметь ответ на этот вопрос, выраженный в денежном эквиваленте.
        • +1
          Про разные технологии — это заблуждение. Наоборот, большие компании не любят vendor-lock, отсутствие шаринга знаний и техдолг в старых сервисах.
          Кстати, Facebook не держится за PHP, в FB настоящий зоопарк технологий.
          И уж точно там никому не взбредет в голову переучивать всех на PHP.
          • 0
            Я тоже думал, что не держится, пока Александреску не сказал, что PHP и правда хорош для их целей, и на нем то ли 75%, то ли 85% кода в FB написано. А Александреску, знаете, такой дядька, которому нет никакого смысла не верить.
    • 0
      Случайно не знаете, почему нельзя поменять пароль на admin.booking.com в партнёрке?
  • –1
    Список из живых (то есть поддерживаемых и развиваемых) проектов на Perl не помешал бы. Он заменит тысячу слов о востребованности языка.
    • +8
      Компании активно использующие Perl в инфаструктуре или имеющие сайты на нем: Amazon, DuckDuckGo, DigitalOcean, Buzzfeed, New York Times.

      Коробочных продуктов на Perl не так много, сходу в голову приходят только: Bugzilla, SpamAssassin, twiki.

      Куча банковского софта, например в JPMorgan Chase.

      Можете посмотреть, кто использует twiki в разделе Success Stories.

      Если у вас есть под рукой Debian-based дистрибутив, то сделайте:
      apt-cache rdepends perl | perl -ne 'print if (! /lib/)' | uniq | wc -l
      

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

      Проблема Perl в том, что он не на виду, но при этом повсюду. Скорее всего вы не знаете ни одной программы на Erlang кроме ejabberd, но это не значит, что Erlang мертв?
      • +1
        Отлично. Добавьте в топик.
    • +1
      ack is better than grep, пользуюсь.
  • 0
    .
  • +3
    С днем рождения, Perl! Я как раз язык изучаю и пишу клиент-серверное приложение на perl.
  • +1
    Perl вызывает у меня острую ностальгию.
    Хотя однострочники через perl -e или из vim пишу почти каждый день, за что-нибудь серьезное на нем уже врядли возьмусь.

    А как смотрят на Perl в области BigData? В свое время в обработке слабо структурированных текстовых файлов он произвел переворот, по сравнению с AWK. И лучше по моему до сих пор ни чего не придумали. А это значительная часть работы с большими данными.
    • 0
      Например www.nationmaster.com/ среди нескольких источников информации использует и википедию. В виде xml дампа в несколько десятков гигабайт.
    • 0
      Мы используем Perl (в связке с Oracle) для обработки логов сервиса обслуживающего 120М запросов в день. Сейчас я этот код переписываю под работу с AWS RedShift, так как бизнес хочет иметь возможность для более гибкой аналитики. Так что роль Perl кода уменьшится и вполне возможно что он вообще будет заменен на logstash.
      PS: Но простенькие Web Service-ы я все еще пишу на Perl :)
  • +1
    Все же при всем описанном не стоит забывать, что есть и свои минусы. Как минимум это
    • В 5 версии как-то что-то фиксить и выпускать более новые версии стали весьма и весьма недавно
    • В отличии от того же Python язык никак не способствует написанию читаемого кода. Даже я свой код на перл написанный буквально месяц назад даже с учетом того что я стараюсь писать читаемый код, читаю хуже чем на том же Python
    • Как не странно CPAN. Там да куча модулей, но модули часто заброшены и автора не найти. Вместо того чтобы позволять перевод управления заинтересованным лицам, предлагается создавать… свой модуль. В итоге внутри CPAN может быть 100500 модулей делающих одно и тоже от разных авторов. Это весьма затрудняет его использование. Я уж молчу, про то что часто софт на перле вообще не указывает какую версию модуля ему надо. И в итоге начинается игра в подбери модуль.

    • +4
      В 5 версии как-то что-то фиксить и выпускать более новые версии стали весьма и весьма недавно


      Ну причины я описывал, как раз до 2011 в основном сидели все на 5.8. Хорошо, что последнее время таки вышли на ежегодный цикл релизов.

      С CPAN есть тонкость. Когда я нахожу ошибку в модуле, то иду на Issues этого модуля в CPAN, а там уже оставляю ссылку на гитхаб, где все пофикшено. Многие делают также или прикрепляют патч, так что пофикшеную версию часто можно найти.

      А мне тяжело читать код на питоне :)
      • –1
        С CPAN есть тонкость. Когда я нахожу ошибку в модуле, то иду на Issues этого модуля в CPAN, а там уже оставляю ссылку на гитхаб, где все пофикшено.

        Я вообще патч в issues повесил. И толку? Модуль из CPAN при этом уже не поставишь. А добавишь свой, так надо знать какой брать. Это фактически ломает весь CPAN.

        А мне тяжело читать код на питоне :)

        На вкус и цвет фломастеры разные. Но вообще использование python как первого языка в дальнейшем, дает положительные результаты так-как вырабатывается привычка нормально форматировать код. В отличии от perl где это совсем не обязательно.
        • +1
          По моим наблюдениям использование python как первого, сильно мешает потом усвоить новые концепции, как функциональное и декларативное программирование, pattern matching, метапрограммирование.
          • +2
            Эм. Ничего что функциональное программирование в python есть? :) И для освоения указанных вами концепций, надо просто учить не только python.
            • 0
              Только в виде лямбд. При этом Гвидо все делает, что бы ими меньше пользовались. Это и неудобство создания одноразовых функций в несколько строк, и вынесение сверток в отдельную библиотеку из стандартной, и принципиальный отказ от ТСО.
    • 0
      В отличии от того же Python язык никак не способствует написанию читаемого кода. Даже я свой код на перл написанный буквально месяц назад даже с учетом того что я стараюсь писать читаемый код, читаю хуже чем на том же Python


      А должен ли язык заботиться о таких вещах? Пожалуйста, можно ведь писать как угодно: можно строить монструозные конструкции из $foo->{$bar->{baz}->[1]}->{baz}, щедро присыпая это все регулярками, которые могут почти все, что касается текстовых данных и оборачивая в однострочные foreach/unless с двадцатью упоминаниями $_ в одном выражении. Но зачем?

      Можно ведь писать и вполне себе читаемый код — с форматированием, учетом стандартов именования и прочего-прочего. Решать программисту.
      • –1
        А должен ли язык заботиться о таких вещах?

        Первый язык должен. Иначе если нет старших товарищей носителей культуры кода, программист будет писать так как ему удобно. И если он еще при этом не лентяй, то там такое может наблюдаться…
      • –1
        Можно ведь писать и вполне себе читаемый код — с форматированием, учетом стандартов именования и прочего-прочего. Решать программисту.

        Это идеология языка. Причем тут важно не написание нечитаемого кода, а скорее максимально короткого и эффективного.
    • +2
      Запомните: вы и только вы, как программист, отвечаете за читаемость кода и никакой язык не может вам в этом помочь или помешать. То же самое касается о ошибок.
      • 0
        Запомните: вы и только вы, как программист, отвечаете за читаемость кода и никакой язык не может вам в этом помочь или помешать

        Вы надеюсь помните что на любом тьюринг полном языке можно реализовать любую задачу. Но многие из таких задач проще делать на определенном языке. Тоже самое касается читаемости кода. У python код не читаемым сделать сложнее чем у perl.
        • +2
          Бред.
          Скажите, какой краской проще нарисовать красивую картину? Акварелью или масляной? Или карандашом?
          Вы сможете доказать ваше утверждение? Или хотя бы ввести формальное понятие «красивый код»?
          А знаете что: если вы привыкли всю жизнь писать на питоне, то любой код на другом не похожем языке будет вам казаться уродливым и непонятным.
          • 0
            Ну почему-то брейнфак не получил такого распространения, как C#, например.
            • +3
              В основном из-за ужасно малофункциональной стандартной библиотеки, я полагаю.
            • +1
              Он же изначально создавался быть наименее понятным для человека, как шутка. Вы же не станете утверждать, что Perl создавался с такой же целью?
          • 0
            Скажите, какой краской проще нарисовать красивую картину? Акварелью или масляной? Или карандашом?

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

            Инструмент имеет значение. Дырявые аналогии такие дырявые, да?
            • +1
              Речь шла о картинах. Не о подписях, не о лекциях, не об черновиках.
              Да, бывают разные картины: и красками написанные и карандашом и шариковой ручкой. Но всеми этими инструментами можно написать красивую картину, а можно и плохую. Все зависит от мастерства художника.
              А вообще, как называется прием в демагогии, когда оппоненту приписывается то, чего он не говорил, а потом это эффектно опровергается?
        • +4
          Ну это как сказать…
          list(zip_longest(*[iter(('0'+str(bin(int(time.time())))[2:]).replace('0', '_').replace('1', '*'))]*4))
          • +2
            Вот кстати да.
          • +1
            Дико плюсую.
      • 0
        никакой язык не может вам в этом помочь или помешать
        А вот, например, на счет помочь:
        gofmt ...
        gofmt.com
      • 0
        То есть вы можете привести пример читаемого кода, скажем, для «Hello, world!» на Brainfuck?
        • 0
          • 0
            Комментарии за код не считаются.
        • +1
          Нет, зато в комментариях ниже приводится пример ужасного кода на Python. И вообще, давайте не заниматься фигней и не сравнивать реальные языки программирования на которых люди пишет реальные программы с эзотерическим языком с минимальным синтаксисом, который придумали ради прикола.
          • 0
            я не сравниваю языки, я опровергаю ваш тезис. Языки могут как мешать, так и помогать делать код нечитаемым, особенно, когда создатели задаются подобной целью.

            Вы показали только то, что Python — не тот язык, который приспособлен помочь.
            • 0
              Да ладно. Я могу утверждать, что нечитаемость кода Brainfuck связана исключительно с его низкой распространенностью и вы никак не сможете это опровергнуть. Были же люди, которые читали hexdump'ы даже без дизасемблирования вполне себе спокойно.
              • 0
                Вы «читаемость» определяете как «можно натренироваться лет за 10-15»?

                Вы можете утверждать и что есть летающий макаронный монстр. Но «были же люди» не доказывает в лучшем случае ничего, а скорее и наоборот, что чтение дурных языков требует многих лет тренировок.
    • 0
      В отличии от того же Python язык никак не способствует написанию читаемого кода. Даже я свой код на перл написанный буквально месяц назад даже с учетом того что я стараюсь писать читаемый код, читаю хуже чем на том же Python

      Можно взглянуть на пример вашего кода, который вы сами прочитать не можете?

      Почему не используете форматирование кода?
      • +1
        Можно взглянуть на пример вашего кода, который вы сами прочитать не можете?

        Внимательно смотрим контекст. Код читается, но хуже чем в случае python. К примеру меня совершенно не радуют вот такие вот конструкции

        push @{$request->{$ref->{'id'}}->{$ref->{'attribute'}}}, $ref->{'value'};
        


        Почему не используете форматирование кода?

        Можно поинтересоваться, каким образом вы сделали вывод что я не использую форматирование кода? Особенно когда я тут много говорю от том что python в качестве первого языка как раз будет прививать форматирование кода а?

        • +3
          Форматирование по дефолтовым правилам Perl::Tidy тут помогло бы, кстати: для лучшей читаемости стоит добавлять пробелы в фигурных скобках, если там выражение. Можно убрать кавычки:

          push @{ $request->{ $ref->{id} }->{ $ref->{attribute} } }, $ref->{value};
          


          В Perl 5.20 ещё лучше

          push $request->{ $ref->{id} }->{ $ref->{attribute} }->@*, $ref->{value};
          
          • 0
            На самом деле ->@* не обязателен, если уж использовать новые фичи то сейчас push и прочие keys уже умеют принимать не только массивы/хеши но и ссылки на них (может потребоваться включить какой-нить use feature).
            • 0
              Да, так стало возможно, начиная с 5.14, но в 5.20 решили, что лучше отказываться от этого способа в пользу postfix dereferencing. Вот такие бесчеловечные эксперименты.
    • +3
      В отличии от того же Python язык никак не способствует написанию читаемого кода.

      Можно подумать указанный Вами язык творит особую уличную магию.
      • –4
        Мусора в синтаксисе меньше. Плюс форматирование является частью языка в отличии от perl.
  • +5
    Начало 2000х. Я — инженер по линукс-серверам (зеленый как трава по весне) у крупнейшего регионального провайдера на сегоднешний день, а тогда 10 человек в отделе, только-только DSL начали продавать по ценам годового бюджета какой нибудь африканской страны. Клиентов заводили руками, записывали всю инфу по ним в амбарную книгу, как подсчитывали съеденный клиентом трафик руками с интерфейсов даже рассказывать стыдно))).

    Решили, что нужно в электронный вид привести все дело. Программеров — никого, вызвался я, ибо стало интересно. Закупился литературой на ОЗОНе по Perl и Mysql и за неделю сваял таки и «движек» и Web-интерфейс разноцветный.
    Презентовал коллективу и непосредственному руководству, очень переживал… оценка: «Пацаны! Это — огонь!!!» )))) Работали с этим поделием года полтора, пока биллинг нормальный не появился.

    Вспоминая код я понимаю, что гореть мне в АДу за все что я там «написал». И даже Гитлер глядя с соседней сковородке будет плакать глядя на мои истязания...)
  • +6
    Я как системный администратор просто хочу сказать спасибо Perl и низкий ему поклон. У меня есть две админки, которые ооооочень старые и некому их переписать. Одна написана на PHP, а другая на Perl. Новые сервера с новыми версиями ЯП и… я вечно придумываю как обойти все deprecated function в PHP (например добавил обёртку, эмулирующую global variables) и просто работает Perl-админка.
    Вот за эту «совместимость» спасибо Perl от админа, который уже умер как программист.
  • –7
    Я очень долго был фанатом perl и не понимал, зачем нужен питон. Но недавно попытался написать кросс-платформенный скрипт (для мака и винды) на perl. Нужно было работать с путями, содержащими русские буквы. Это был настолько эпичный фейл… А потом я узнал, что в питоне такой проблемы просто нет. Выводы делайте какие хотите.
    • +1
      Ну конечно, особенно если имя пользователя на кириллице — " в питоне такой проблемы просто нет", угу…
      • 0
        Очень печально слышать, что и в питоне тоже подобные проблемы.
        • +1
          Я к тому что в случае с Win это системная проблема в большей степени, а не проблема языка.
          • 0
            Если развить мысль, то сам язык тут вообще не при чём. Проблема в конкретной реализации интерпретатора и стандартных модулей. Не согласен с тем, что эту проблему надо перекладывать на винду.
    • +2
      Я очень долго был фанатом русского языка и не понимал, зачем нужен английский. А недавно пришлось устраиваться на работу в Лондоне. Это был настолько эпичный фейл… А потом я узнал, что у моей жены, которая окончила ИнЯз, такой проблемы просто нет.

      Честно говоря, не очень понимаю, какие там проблемы у перла могут быть с русскими буквами в путях, но верю вам, что, наверняка, все очень плохо.
      • 0
        Не понял вашей аналогии, но с русскими буквами в путях всё действительно плохо. Стандартными средствами, без сторонних модулей не работает от слова «никак». Со сторонними модулями кое-как работает, но это настолько сторонние модули, что их нет в ppm в поставке Active Perl. А ставить модули не из ppm — это решение может сработать для себя лично, но не годится для предприятия.
        • 0
          А можете привести пару примеров?
          Я использую Strawberry Perl на винде и у меня есть русские пути в debian-dev-среде — проблем не замечал. Просто интересно, может не сталкивался с тем, что понадобилось Вам.
          • 0
            Пару примеров чего?
            Возможно Strawberry Perl в этом плане лучше, чем ActivePerl. Надо будет попробовать.
            Кстати, у вас русские пути в какой кодировке? (Если этот вопрос вообще имеет смысл для винды. Плохо разбираюсь в особенностях этой ОС.)
            • 0
              Вот хотел раньше написать, но передумал, а теперь вижу, вы на правильном пути)

              Вам надо разобраться, в каких кодировках хранятся имена файлов в основных файловых системах, и перл тут ни при чем.
              • 0
                Строго говоря, в 2014 году мы (я) от стандартных библиотек языка вообще-то ожидаем, что на широко используемой ОС мне для чтения списка файлов не нужно знать, в каких кодировках они там хранятся унутре.

                • +1
                  Очень зря, кстати. Окошки весьма коварны в вопросах кодировок.
                  По моим ощущениям (никогда подробно не исследовал этот вопрос), сама NTFS хранит имена объектов в utf-8/16, но при этом winapi, к примеру, пытается использовать ANSI. С FAT все может быть еще хуже.
                  • +1
                    И что? Почему я вдруг при использовании высокоуровневого языка должен об этом думать?

                    Тут важно отметить, что знать обо всем этом неплохо бы. Но я убежден, что вправе ожидать от ЯП, что все эти проблемы он разрулит уровнем ниже интерфейса, которым пользуюсь я.
                    • 0
                      Вы меня прямо заинтриговали. Как именно Perl не работал с русскими символами в именах файлов? Просто не понимаю как эта проблема не могла не всплыть у кого-то еще — ведь работа с файлами и каталогами для Perl — его хлеб.
                      • 0
                        Вы, мне кажется, веткой ошиблись :)

                        Я как раз прекрасно знаю, что никаких проблем нет. Я тут спорю с 3rd-party тезисами, а не утверждаю, будто есть какие-то проблемы.
                        • 0
                          Еще как ошибся!
                      • 0
                        use utf8;
                        opendir($dh, «Тест») or die $!;

                        Возвращает ошибку «No such file or directory».

                        Расскажите пожалуйста, как это нужно делать правильно, с вашей точки зрения. Все решения, которые я находил в интернете, какие-то стрёмные.
                        • 0
                          Мне кажется, что то, что Perl не пытается угадать кодировку это уже хорошо. В случае если ваш скрипт в кодировке UTF-8, а системная кодировка однобайтная, то как транслировать имена файлов не ясно. Также не ясно как вести себя если две файловые системы смонтированы с разными кодировкам, что для linux типично. Также если локаль системы имеет отличную кодировку от файловой системы, то эвристическое поведение навредит. Я говорю это просто чтобы вы понимали, почему это поведение неудобно, но все-таки наименьшее зло.

                          Наверное(у меня сейчас нет Windows под рукой) сработает такой код:
                          use Encode::Locale;
                          use Encode;
                          use utf8;
                          
                          opendir($dh, encode(locale, "Тест") ) or die $!;
                          


                          Если не сработает, то замените encode на decode — вечно их путаю.
                          • +1
                            Вот так всё заработало:
                            encode($Encode::Locale::ENCODING_LOCALE_FS, "Тест")
                            

                            Спасибо! =)
                            Вот честное слово, как ни гуглил, вообще ничего хорошего не находилось.

                            Плюс из документации Encode::Locale взял кусочек для вывода русского текста в виндовую консоль, вдруг кому пригодится:
                            if (-t) {
                              binmode(STDIN, ":encoding(console_in)");
                              binmode(STDOUT, ":encoding(console_out)");
                              binmode(STDERR, ":encoding(console_out)");
                            }
                            
  • –7
    Подскажите современную мощную IDE для Perl, чтобы можно было web-приложения дебажить.
    • 0
      Для тех, кто также не прочитал статью или просто не знаком с перлом: для перла нет IDE. Дебажить web-приложения можно в Google Chrome (на правах сарказма).
      • 0
        Komodo IDE был когда-то популярен. Был плагин под VS. Но мой вопрос был про то, что сейчас популярно.
        А отлаживать, я имею в виду, когда делаешь attach к процессу web-сервера.
        • 0
          Если говорить про обычные Perl-отладчики, которые включаются, когда вы используете опцию -d интерператора при запуске программы — их вагон и маленькая тележка и с веб-интерфейсом, и с ГУИ. Есть также отладчики, включающиеся при возникновении ошибки/предупреждения, но их надо специально добавлять в код приложения.

          Но, AFAIK, специального отладчика способного подцепиться к работающей Perl-программе, которая была запущена без возможности отладки — нет. Если очень надо, то для этих целей можно использовать обычный gdb и небольшой хак. Внедрив нужный отладчик, вы затем спокойно отлаживаете код на горячую. После чего можно отцепить отладчик и процесс продолжит работу как ни в чём не бывало… может быть ;)
          • 0
            А можно огласить список нормальных отладчииков? Из работающих я знаю только ptkdb и Eclipse, и оба пригодны очень условно.
            Насчёт прицепления к работающей программе — попробуйте так Mojolicious отладить в режиме hypnotoad. Логи только и спасают.
            • 0
              А что вы понимаете под нормальным отладчиком? По мне так и perl -d — вполне нормальный отладчик. Если вы хотите красочности, то попробуйте metacpan.org/pod/Devel::hdb. Но лучше все же понять чего вы от отладчика хотите.
              • 0
                «вагон и маленькая тележка и с веб-интерфейсом, и с ГУИ» — вот этот вагон я и просил.

                От отладчика я хочу установку и сохранение до следующего вызова точек остановки, желательно с условиями, вывод значений нужных мне переменных (зелви — есть, Eclipse — нет), работа в GUI интерфейсе (принцмпиально, без GUI я предпочитаю логи), удалённая отладка, независание в процессе отладки, отладка форкнутых процессов.
                • 0
                  Боюсь в таком случае Perl нечего вам предложить. Т.е. все задачи кроме GUI стандартным перловым отладчиком решаемы, но подчас некрасиво. А отладчиком, нормально поддерживающим форкнутые процессы, насколько мне известно, могут похвастаться только IDE для С++ и Java.
            • 0
              Есть относительно свежий обзор по отладке и отладчикам. Мне кажется самый перспективный и полнофункциональный — это отладчик Devel::Trepan.
    • 0
      Я юзаю PHPStorm + Textmate Bundles, не очень конечно, но сильно я привык к Idea
  • +1
    Каждой задаче свой инструмент! При всех недостатках Перла, для определенных задач он просто не заменим. А его скрытые фишки — $_ в map, grep, split, for, обратный if — это что-то! По идеологии разве что Ruby близок, только с типизацией и полноценным ООП.

    Кстати, PerlMonks — это не stackoverflow, а нечто большее — там и поэмы на Перле имеются!
    • +2
      А мне очень нравятся регулярные выражения. Если нужно какой-нибудь текст быстро отпарсить или сконвертировать: Perl — лучший кандидат.
      • 0
        К сожалению, только пока к вам не зайдет на вход символ из Supplementary Plane.
  • +2
    Прочитал, описано всё здорово, но с каким-то оттенком грусти. Язык Perl сейчас очень активно развивается. Каждый год выходит новый стабильный релиз и каждый раз он приносит какие-то новые фантастические фичи. Вот и для 5.22 припасено ускорении ООП на 50% и ускорение разыменования аж до 100%. Нет времени ностальгировать, надо активно опробовать всё новое в деле, и не важно веб-разработка, системные сервисы или парсеры.
    • 0
      Практически невозможно использовать новые версии перла.
      Во-первых, их нет в дистрибутиве, единственный выход задействовать perlbrew, но этот путь приводит к массе вторичных проблем — уже надо с проектом тянуть не только локальную библиотеку в perl5, а весь интерпретатор.
      Во-вторых, самые интересные и полезные нововведения помечены как экспериментальные, и их синтаксис действительно постоянно меняется.

      • 0
        Совсем новые — только в нестабильных дистрибутивах. Но, например, в Ubuntu 14.04.1 LTS — perl v5.18.2 (2013 год). Так что вполне смело можно начинать ориентироваться на фичи 18-ой версии.

        Нововведения синтаксиса всегда экспериментальные, но если вы используете 5.18 в продакшене и видите, что вышел 5.22, где сказано, что такая-то фича больше не экспериментальная, то это даёт моральное право начать использовать её в 5.18.
        • 0
          Но нельзя же привязываться к какой-то конкретной версии конкретного дистрибутива.

          Сразу напишу о второй проблеме. Недавно я попробовал установить Moose версии 1. Оказалось, это невозможно в современном перле — в зависимостях появляется Moose 2. Как это побороть я так и не придумал.
          • 0
            Moose 1 зависит от модуля Class::MOP, который стал частью Moose 2. Т.е. не получится использовать старый Moose и новые версии его зависимостей. Идеально иметь снапшот CPAN'а под проект и для этих целей хорошо походит: а) пакеты из вашего дистрибутива Linux/BSD, б) carton/Pinto/DarkPAN/
            • 0
              Снапшот cpan'а это хорошо, и из backpan его можно сделать, ограничив только теми версиями, которые появились до указанных в зависимостях. и теми, которые установлены на действующем сервере (если действующий сервер накрылся и нет его бэкапов, но, казалось бы, само приложение есть — установить его в общем случае почти нереально из-за того, что в процессе эксплуатации некоторые модули могли обновиться). Но это не метод совершенно. Для каждого скрипта иметь снапшот? Bот из-за таких проблем многие большие проекты не используют модули из CPAN вообще, что снижает ценность перла. С этим сталкиваться приходится редко, но если проект работает годы, то надо либо постоянно его переписывать с учётом изменений в модулях, либо столкнуться с тем, с чем столкнулся я…
              • 0
                В таких случаях стоит идти от меньше сложности и начинать например с Local lib или же Perl brew.
                • 0
                  Ни то, ни другое не решает проблему, пример которой с Moose я привёл. Решить, действительно, сможет только снапшот cpan'а.
      • 0
        Это относится к политике дистрибутива. Кроме перла вы не увидите последние версии любого софта.

        Поставить перл из исходников параллельно — не проблема. То-же самое приходится делать с питоном или пхп, и т.д.

        Я постоянно отслеживают все нововведения по синтаксису и сразу начинаю их использлвать. Ни разу ничего не менялось за много лет. Или приведите пример.
        • 0
          Имеются нововведения в перле или в конкретном модуле?
          • 0
            В перле.

            Модули — на усмотрение авторов.

            Используется семантическое версионирование, все по спецификации, как и в других языках, ничего своеобразного в этом плане в перле нет.
    • +2
      Я не хотел скатывать всю статью в заунывное «Perl еще не умер!». Вы же не думаете, что это бы кого-то убедило из тех, кто искренне убежден в этом? Да и мне честно говоря не казалось, что долгое сидение на 5.8.9 было чем-то плохим.
  • +1
    Странно, что не упомянут русскоязычный журнал о Perl, который пережил 22 выпуска. Или это слишком ломает стереотипы? )
    • 0
      Да, пожалуй добавлю в статью.
  • +2
    Блистательно, низкий вам поклон.
  • 0
    Ещё один недостаток. Может быть, он уже имеет решение, но. В Java есть Apache Tomcat. Какой аналог есть в Perl?
    • +1
      Так полно, любой PSGI-сервер: Starman, Twiggy,…
  • 0
    Долго статью писали, 15го декабря Ruby занял 5е место =) Уже полтора года пишу на перле(Mojo), единственное что реально напрягает — нет IDE от Idea, уж очень сильно я на них подсел, скорее всего это моя индивидуальная проблема, потому что большинство сидят в виме и не нужна им ни какая Idea.
    Еще один жуткий минус — это сообщения об ошибках, если PHP почти всегда по сообщению о ошибке можно понять где же реально накосячил, то Perl напишет такую ерунду, которая только сбивает с толку.
    • 0
      В perl, как и везде, есть возможность получить дамп стека вызовов. Что еще надо?
      • +1
        Вот пример, есть рабочий код, я в произвольном месте убираю символ ";" и что я получаю в ошибках? 2 раза ругнулся на Global symbol, syntax error near "}" и все эти ошибки обозначены строчек через 10 от того места где я убрал эту точку с запятой. Проверните такой же трюк в PHP.
        • +1
          Стандартно вы получаете ошибку компиляции с указанием файла и номера строки, где она произошла.

          Возможно, что убрав ";" вы изменили структуру блока, поэтому компилятор читает этот блок неправильно. Это может быть в любом языке, компилятор же не может на 100% правильно угадать, что вы хотели сказать, написав неправильный код.
        • 0
          Не удаётся вопроизвести. Где бы ни убирал первыми строками выдаётся примерно такое:
          Scalar found where operator expected at lib/Some/Module.pm line 468, near "$p"
          	(Missing semicolon on previous line?)
          ...
          


          Как бы недвусмысленно: потеряли семиколону на превиоус лайн?
          • 0
            Как видите, мы специально допустили одну и ту же ошибку, но ругается он по разному.
            • 0
              use diagnostics должен помочь.
        • +1
          Хороший пример. Он, кстати, указывает на еще один недостаток/преимущество перла. Он съест практически все, что ему попытаешься скормить. Кто-то называет это DWIM, хотя для новичка в перле после опыта работы с другими языками это часто вызывает лишь недоумение. Но если действительно хочешь разобраться, то ко всему привыкаешь, начинаешь лучше понимать и замечать то, что влияет на поведение интерпретатора.
          • 0
            Да я понимаю откуда ноги растут =) и уже понял как с этим жить, но все же проблема есть. Вообще в языке много всего что вызывает недоумение у новичков и гораздо проще перейти на другой язык, чем разобраться с этим.
            • 0
              Вторая часть сообщения была не для вас конкретно :)
    • 0
      Да, поправил ссылку. Но главное что это не Perl упал, а Ruby вырос.
  • 0
    Вспоминаю 2002-й год, ноутбук Pentium 133 с 16Мб памяти и ужасной TN матрицей. На нем Black Cat Linux без иксов, на котором я настраивал голдед и вообще разбирался в линуксе. Читал маны все подряд, пока случайно не наткнулся на man perl. Я, конечно, что-то слышал про этот язык и раньше, но не ожидал увидеть полноценную документацию с туториалом в манах.

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

    Сейчас трудно описать, сколько счастья я испытал, когда написал консольный клиент для виндового чата Talker, и мог общаться с друзьями по локальной сети. А потом свой файлэхопроцессор. И еще кучу всего — уже работая программистом.

    Закончил с перлом только в позапрошлом году :)
  • +2
    2500 $ не так сложно


    Ох уж эти сказочки, ох уж эти сказочники…
    • –1
      Мне ваша позиция понятна, в СНГ за удаленку так платят очень редко. Но при 40-часовой рабочей неделе это 15,6 $ в час. Это входит в диапазон самых ходовых ставок на oDesk.
      • +2
        Только там работа имеет непостоянный характер, и не факт что в среднем за год получится 2500*12
        • 0
          У кого на удаленке выходит в среднем такая среднегодовая зарплата или выше, плюсаните пожалуйста этот пост.
      • 0
        Если вы имели в виду работу фрилансера — то во-первых, это работа без гарантированного дохода, а во-вторых, язык не поворачивается назвать её «не такой сложной».
  • +2
    Mojolicious — великолепен
    • 0
      Да, хотя бы потому, что идет с сервером в стандартной поставке, несмотря на компактность.
      • 0
        Вообще-то его надо тащить вместе со своим приложением — чтобы работать с известной версией. Славится Mojo несовместимыми изменениями.
        • 0
          Последний примерно год проблем с обратной совместимосью не встречал.
          • 0
            И secret 29-го марта не удалился (secrets, кстати, появился как раз почти точно год назад)? Не нарваться на него просто невозможно. И вообще, год — это не срок.
            • 0
              Secret да, он умер. Но ситуация решилась настолько быстро, что про коммит с фиксом у меня даже нет тикета в багтрекере.
    • 0
      Кстати, скажу свои 5 копеек — после того, как я раскурил MS MVC, с нуля, без знания перл, mojo и PGSQL у меня за 5 дней фултайма был написан простенький бложик с Twitter Bootstrap + jQuery фронтендом.
      Так что да, он чертовски хорош. И Себастиан раньше писал тот самый Каталист
      • 0
        Пока не нагуглил ваш аккаунт на одеске не понял что на чем вы писали и при чем тут MS MVC.
        • 0
          Ну на odesk я есть, но пока ничего хорошего я там не сделал.
          Я говорил о том, что после реализации MS MVC разобраться с perl + mojo оказалось очень легко и просто. Dancer у меня такого «вау еффекта» не вызвал.
  • 0
    Perl был языком, с которого я начал свой путь программиста в 2000 году, с написания своего CMS (тогда с готовыми было туго, и изобретение своего велосипеда было нормой). И я до сих пор активно работаю с этим фреймворком, каждый день решаю достаточно сложные задачи для повседневной деятельности и развития фирмы. А самое прикольное, что проект уже 14 лет крутится на Perl5, переезжая на разные сервера и ОС, и за это время я не столкнулся с багами интерпретатора ни разу. Спасибо, Perl. Из главных плюсов языка отмечу то, что он прекрасно подходит для быстрого решения небольших задач. В этом ключе наверное и будет применяться в будущем. Из минусов — большие и сложные системы без нормального ООП и глубоко интегрированного с языком IDE, разрабатывать сложно.
  • 0
    Есть проблемка одна с Perl-ом ИМХО. Например.

    Надо написать какую-нибудь небольшую консольную утилитку строк так на 200-500. По привычке начинаешь писать на Perl, пишешь первые строк 100, стараешься… И потом смотришь на получившееся и думаешь: «а дай-ка я лучше это на Python напишу, пока еще не поздно и не так погряз в коде». И не хочется вроде это делать, потому что думаешь: ну разве я выиграю существенно от этого? Пишешь и вдруг с удивлением замечаешь, что получилось-то уже не 100 строк, а 50, и код стал гораздо, ГОРАЗДО аккуратнее, проще и читабельнее, и на написание его ушло меньше времени…

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

    Несколько раз такое уже происходило. Мне почему-то кажется, что это не только мой случай, это паттерн.
    • 0
      Пишешь и вдруг с удивлением замечаешь, что получилось-то уже не 100 строк, а 50

      Это потому что Python поддерживает только однострочные лямбды…

      Все-таки признайте, любите вы Perl, иначе как можно объяснить, что вы скрепя сердце раз за разом начинаете на нем писать, невзирая на то, что Python вам подходит больше.
      • +1
        Конечно, люблю. Когда у кого-то, не дай бог, родственник при смерти, это ж не значит, что перестаешь его любить или перестаешь его навещать.
        • 0
          И когда ждать некролога «Perl 5 в подлиннике»?
          • +1
            Может, это он и был выше. :-)
  • +1
    Спасибо от REG.RU за добрые слова. Мы, кстати, не только няшечки, но ещё и удалёнщиков до сих пор нанимаем, несмотря ни на что. Так что пишите на resume@reg.ru.
  • 0
    Perl же в этом плане выбрал несколько другой путь — пока вы пишите на любом языке, интерпретатор будет считать, что вы пишите на Perl.

    ПишИте — это приказ писать.
    ПИшете — это глагол в 3 лице мн. ч. настоящего времени.
    Не путайте.
  • 0
    Сетевым администрированием занимаюсь давно, но скрипты сам не писал.
    Все сводилось к логическому «ковырянию» найденных в интернете скриптов.

    Стоит ли начинать изучать Perl (печатная книга есть на руках) для изучения и самостоятельного написания скриптов для Linux систем или лучше изучить Advanced Bash-Scripting Guide?
    • 0
      Perl — полноценный и мощный язык программирования.
      Его надо изучать и потратить на это время.
      Если ваши задачи — простой скриптинг — делайте на баше.
      • 0
        Спасибо! Я понял вас.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.