Вакансия: Разработчик perl в Москве

2.Perl (fast CGI)

1.Интересная работа в молодом, стремительно развивающемся коллективе,

по-моему эти вещи несовместимы. Нужно быть ярым фанатиком, чтобы продолжать писать на Perl.

Знаете, надоели уже такие обобщения. Если вы знаете только PHP или Ruby, не надо пишущих на Perl объявлять стариками или фанатиками. Это выглядит, как минимум, глупо.

реч о том что perl легаси и поэтому знать perl очень полезно для своего бюджета.

Я писал на Perl лет 6 назад. В 2005 году кроме этого набора регэкспов и php особо выбора не было, а сейчас я даже не представляю как можно при таком разнообразии всяких Pyramid, RoR, Node.js использовать Perl. Это явно фанатизм или неумение учиться. Ну или то и другое вместе.

Я молод душой и телом. Я пишу на Perl.

Я молод душой и телом. Я пишу на Perl.

Галоперидолу пациенту. Следующий.

Лучше чашечку чая.

всегда улыбает баттхерт, возникающий у местной публики при виде вакансий перл-программиста

P.S. сам пишу на перле полтора года, правда не для веб

Требование высшего образования обоснуйте, пожалуйста.

Высшее образование - стандартное требование при приеме в относительно крупную компанию.

CPAN? mod_perl? PL/perl? Таких причин много.

1987 - н.в. Язык зрелый.

CPAN? mod_perl? PL/perl? Таких причин много.

не совсем понял при чем тут CPAN, mod_perl и PL/Perl. Единственный момент с которым согласен - perl_module для nginx. Делал кое что на нем, но это только из-за того, что Игорь выбрал Perl, можно так же реализовать python итд. PL/Perl свободно можно заменить на PL/Python, PgSQL его поддерживает.

CPAN это огромная экономия человеко-часов. Ни у одного другого скриптового языка нет библиотеки сопоставимой по объемам. Централизованное, хорошо проиндексированное хранилище программных решений позволяет perl разрабочику разрабатывать только новый код, код который еще никто не писал. Ибо если что-то было качественно сделано, то она обязательно есть в CPAN.

mod_perl, PL/Perl и пр. это намек, что perl скрипты стандартно поддерживается практически везде. В крупных проектах под них специально делается оптимизация.

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

Поэтому к черту новые языки, пусть они достигнут совершенолетия (18 лет) прежде, чем я пущу их в свой мозг.

Для меня: Perl, PostgreSQL, C++, Javascript — это инструменты в которых я целенаправленно прокачиваю свои знания (в указанном порядке). Основную массу задач я решаю с их помощью. Это не значит, что я другими не пользуюсь, но все сложное и большое я решать именно этими, если только нет ОЧЕНЬ веских причин использовать что-то другое.

CPAN это огромная экономия человеко-часов. Ни у одного другого скриптового языка нет библиотеки сопоставимой по объемам. Централизованное, хорошо проиндексированное хранилище программных решений позволяет perl разрабочику разрабатывать только новый код, код который еще никто не писал. Ибо если что-то было качественно сделано, то она обязательно есть в CPAN.

я пока не находил пакетов, которых не было бы для python, а вот наоборот уверен что есть такие вещи.

mod_perl, PL/Perl и пр. это намек, что perl скрипты стандартно поддерживается практически везде. В крупных проектах под них специально делается оптимизация.

mod_python, PL/Python и пр. это намек, что python скрипты стандартно поддерживается практически везде. В крупных проектах под них специально делается оптимизация.

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

Поэтому к черту новые языки, пусть они достигнут совершенолетия (18 лет) прежде, чем я пущу их в свой мозг.

умрут, сгниют и потом можно будет писать. Новую мажорную ветку не могут реализовать 10 лет. Работа с объектами, декораторами, иксепшонами как была через костыли, так и осталась. Я как-то не готов ждать 18 лет, когда в языке реализуют нормальные иксепшоны на уровне языка.

Пополним игнор-лист пересмешником.

Работа с объектами, декораторами, иксепшонами как была через костыли, так и осталась.

«костыльность» заключается в том, что это сделано не как в петоне?

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

чем они сейчас не нормальные и почему на уровне языка лучше?

«костыльность» заключается в том, что это сделано не как в петоне?

т.е. тебя устраивает как реализованы классы в Perl?

чем они сейчас не нормальные и почему на уровне языка лучше?

тем, что эти костыли не дают возможности получить полную информацию о том что произошло. Сделай open несуществующего файла в Perl и Python и попробуй эксепшонами отследить что произошло.

т.е. тебя устраивает как реализованы классы в Perl?

В какой из реализаций? Мне и на bless'ах нравится. ПРавда, есть своя реализация.

Сделай open несуществующего файла в Perl и Python и попробуй эксепшонами отследить что произошло.

eval { open F, $fileName or die };
say «Can't open $fileName ($@)» if $@;

Или Try::Tiny, по вкусу. Ещё что-то?

eval { open F, $fileName or die };
say «Can't open $fileName ($@)» if $@;

хороший регэкспс, но это не экспешен. Как открыть файл и в зависимости от причины, по которой его невозможно открыть производить дальнейшие действия?

что-то вроде try: blahblah except OSError as e: blahblah или IOError.

Таки где вы увидели регулярку?

что-то вроде try: blahblah except OSError as e: blahblah или IOError.

use TryCatch;

try
{
    open F, $fileName or die IOError->new(code => 200);
    # do smth
}
catch (IOError $e where { $_->code > 100 } )
{
    # do smth
}

т.е. тебя устраивает как реализованы классы в Perl?

Так что с ними не так? Классы как классы.

тем, что эти костыли не дают возможности получить полную информацию о том что произошло.

Да ну? А мужики то не знали.

> open F, $fileName or die IOError->new(code => 200);

ты так будешь писать везде? :)

        try:
            url = urllib2.urlopen(url)
            code = url.getcode()
        except (urllib2.URLError, httplib.InvalidURL, httplib.BadStatusLine, ValueError):
            return False

как с чем-то подобным быть?

как-то так

eval {
  wtf code
};

if ($@ && ref($@) eq 'WTF::Exception1' || ref($@) eq 'WTF::Exception2'
    ref($@) eq 'WTF::Exception2' || ref($@) eq 'WTF::ValueError')
{
   return failes;
}

Если exception'ы наследуются друг от друга и важно это учесть, то поможет UNIVERSAL::isa

я ж говорю, отличный набор регэкспов, но как сделать исключения? Тут нельзя перехватить эксепшон, который не был прописан тобой.

я ж говорю, отличный набор регэкспов, но как сделать исключения?

Где ты тут увидел регекспы?

Тут нельзя перехватить эксепшон, который не был прописан тобой.

А мужики то не знали.

if ($@ && ref($@) eq 'WTF::Exception1' || ref($@) eq 'WTF::Exception2'
    ref($@) eq 'WTF::Exception2' || ref($@) eq 'WTF::ValueError')
{
   return false;
}
elsif ($@) {
  // unknown exception here
  return false;
}

В общем, по делу претензии будут или так и будешь продолжать позориться своей неграмотностью?

В общем, по делу претензии будут или так и будешь продолжать позориться своей неграмотностью?

ну если это ты считаешь нормальной реализацией обработки исключений, то претензий нет. Я лучше продолжу пользоваться нормальным языком, в котором не нужно вызывать eval для того, чтобы поймать исключение и городить кучу костылей из if'ов :)

ну если это ты считаешь нормальной реализацией обработки исключений, то претензий нет.

Ты не смог объяснить в чем ненормальность.

Я лучше продолжу пользоваться нормальным языком, в котором не нужно вызывать eval для того, чтобы поймать исключение и городить кучу костылей из if'ов :)

Что в этом плохого и почему куча if'ов это костыли, а куча except'ов это не костыли?

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

О, перл ещё кто-то использует для новых проектов, надо же. Некроманты прям, колдуны вуду.

Кстати в перле в отличие от сраного питона есть не только убогий строковый eval, но и полноценный eval на вход которому подается корректное перловое выражение

На чёрта он сдался этот eval? ЕМНИП основной юзкейс для него в перле - отлов исключений (perl-way, да).

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

Ты не смог объяснить в чем ненормальность.

Что в этом плохого и почему куча if'ов это костыли, а куча except'ов это не костыли?

Я могу забыть обработать исключение, но я никогда не забуду его создать. Мне не нужно будет выяснять из-за чего не работает кусок кода, т.к. всегда есть исключения и я могу ими нормально управлять, могу создавать свои и уже в самом исключении закладывать часть логики. Весь мой код - 4 строчки и они все понятны. Любой человек, который знает синтаксис python открывает код и понимает что делает код, ему не нужно разбираться где ты там создал исключение, как ты его создал и какие параметры были переданы. Что будет с твоим кодом после 3х лет? Ты точно сможешь открыть его и понять что ты обрабатывал?

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

Само по себе использование eval - моветон. Как минимум это не безопасно. В функциональных языках может быть это и оправдано, но практических задач на LISP я никогда не решал и поэтому не знаю. Будем мериться у кого однострочник будет более запутанный?

Что-то аналогичное PyPy у Perl есть?

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

Ты не поверишь, но в перле всё точно также.

Любой человек, который знает синтаксис python открывает код и понимает что делает код, ему не нужно разбираться где ты там создал исключение, как ты его создал и какие параметры были переданы. Что будет с твоим кодом после 3х лет? Ты точно сможешь открыть его и понять что ты обрабатывал?

Ты не поверишь, но любой человек, который знает синтаксис perl откроет код через 3 года и тоже поймет что это всё значит. Да в перле некоторые вещи сделаны не так как в «традиционных» языках, но ничего плохого в этом нет и к этим нюансам привыкаешь через день работы с кодом.

Само по себе использование eval - моветон. Как минимум это не безопасно.

Подробнее можно?

Нет, а зачем? Кстати не видел, чтобы это где-то реально использовали. В перле для ускорения кода есть искоробочный XS, а не как в питоне куча разномастных кодогенераторов, написанных разнородными разработчиками.

Ты не поверишь, но в перле всё точно также.

что-то я не заметил. Я вижу, что у тебя вызывается eval и только в нем можно поймать исключение. В python я могу это делать в любом месте.

Ты не поверишь, но любой человек, который знает синтаксис perl откроет код через 3 года и тоже поймет что это всё значит. Да в перле некоторые вещи сделаны не так как в «традиционных» языках, но ничего плохого в этом нет и к этим нюансам привыкаешь через день работы с кодом.

Выше я уже писал, что у меня есть опыт работы с Perl и сейчас я абсолютно не понимают то, что писал 6 лет назад. Это просто набор рекэкспов.

Подробнее можно?

Изначально это не безопасно. Вот тебе прям ссылка на вики http://en.wikipedia.org/wiki/Eval#Security_risks

Eval ухудшает читаемость кода. Тут я думаю разъяснения не нужны.

Eval затрудняет дебаггинг. Ну вот я не представляю как ты будешь вызывать что-то подобное pdb в своем eval и какие результаты это принесет.

Может еще расскажешь мне про классы в Perl? Как они создаются, про передачу параметров и проверку их же. Про self в классах. Может быть про тонну кода, который нужно написать для наследования одного только класса. Может быть поговорим о том, что в Perl можно накосячить даже в Assert, просто забыв добавить пару ковычек. Ну и как дела у Perl обстоят с list, dict, итераторами? Как разворачивать списки. Даже просто аналог args,kwargs для Perl в классах/методах есть?

Нет, а зачем? Кстати не видел, чтобы это где-то реально использовали. В перле для ускорения кода есть искоробочный XS, а не как в питоне куча разномастных кодогенераторов, написанных разнородными разработчиками.

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

Ты не поверишь, но в перле всё точно также.

Да плохо всё в перле с исключениями. Есть несколько костыльных реализаций в CPAN + самопальные велосипеды + много модулей, где вообще исключения не используют. Такой зоопарк создаёт гемор на ровном месте. То же самое с объектными системами - каждый изголяется по-своему. Уж лучше бы совсем не было этих объектов разномастных. Хотя мне одно время нравилось на тикле свою объектную систему велосипедить. Вот уж где раздолье. А на перле уныло как то. Что там нынче в моде: Moose, InsideOut? Лучше бы было простенькое ОО из коробки с удобным синтаксисом, глядишь перл не слил бы так позорно web-нишу пых-пыху.

что-то я не заметил. Я вижу, что у тебя вызывается eval и только в нем можно поймать исключение. В python я могу это делать в любом месте.

Ты не поверишь, но в перле eval точно также можно вызвать в любом месте как и try/except в питоне.

Выше я уже писал, что у меня есть опыт работы с Perl и сейчас я абсолютно не понимают то, что писал 6 лет назад. Это просто набор рекэкспов.

Ага, опыта месяц от силы.

Изначально это не безопасно. Вот тебе прям ссылка на вики http://en.wikipedia.org/wiki/Eval#Security_risks

Верно только для строкового eval'а, а мы сейчас говорим не о нем.

Eval ухудшает читаемость кода. Тут я думаю разъяснения не нужны.

Каким образом?

Ну вот я не представляю как ты будешь вызывать что-то подобное pdb в своем eval и какие результаты это принесет.

А в чем проблема?

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

Где тут тонна кода?

use base qw(Base)

Может еще расскажешь мне про классы в Perl? Как они создаются, про передачу параметров и проверку их же.

Создаются не так как в питоне, но плохого ничего в этом не вижу.

Ну и как дела у Perl обстоят с list, dict, итераторами?

Хорошо обстоят.

Как разворачивать списки.

Всмысле?

Даже просто аналог args,kwargs для Perl в классах/методах есть?

В перле принято передавать ссылки на хеши.

пых-пых это упрощенный перл для бедных. никакого позора нет в этом «сливе»

Как у этого pypy обстоят дела с подключением модулей, написанных на Си ?

Ага, опыта месяц от силы.

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

Где тут тонна кода?

package Boss;
use Employee;        # :-)
@ISA = qw(Employee);  

просто пример из документации.

import bla

class new_bla(bla.bla):
    pass

есть разница?

В перле принято передавать ссылки на хеши.

и к спискам. http://www.python.org/dev/peps/pep-3102/

По поводу eval и чтения кода. Просто посмотри на мои примеры и на свои. Что проще читать и дебажить? :)

А давай про декораторы теперь еще? :)

Как у этого pypy обстоят дела с подключением модулей, написанных на Си ?

Эммм, ты на wiki зайди и почитай для чего нужен pypy и что там с модулями на Си :)

пых-пых это упрощенный перл для бедных. никакого позора нет в этом «сливе»

В том то и проблема перла - во всех его нишах появились языки попроще и поудобнее. А перлу крыть то нечем, никаких особых преимуществ у него нет. В общем, легаси, ничего с этим не поделаешь. Для админских скриптов в самый раз, а делать на нём новые большие проекты - это тупик.

есть разница?

Нет

По поводу eval и чтения кода. Просто посмотри на мои примеры и на свои. Что проще читать и дебажить? :)

Однохренственно.

А давай про декораторы теперь еще? :)

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

Я знаю что это jit для питона. Так как там с модулями на Си? Да или нет? swig мне сможет сгенерить модуль для pypy ? Да или нет? Мутные доки не хочу вкуривать, а особенно в субботу в 0:58.

просто пример из документации. есть разница?

Ты лучше конструктор на перле покажи - вот где жесть. Тыщи перловиков пишут тыщи раз одну и ту же хрень с блессом хэша, продвинутые берут какой-нибудь Class::Super, что на самом деле ещё хуже. Конечно, для того кто каждый день пишет эту тайнопись всё читается на раз-два. А со стороны посмотришь - мрак. Или вот ещё пляски с разыменованием ссылок - тут и на пых-пых захочешь свалить (что большинство перло-писателей и сделали в своё время).

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

опять костыли.

http://lemonnier.se/erwan/blog/item/45/ http://lemonnier.se/erwan/blog/item/47/

Of course, Python::Decorator is just a proof of concept. It shows that compile-time function composition (aka macros) can be done in Perl, at least in some restricted way. If such a feature makes it into the Perl core, it will have to have at least a more perlish syntax.

Still, Python::Decorator is fun for at least one more reason: it uses PPI, the Perl parsing module, to analyze and manipulate the source code of Perl programs. Now, that is cool and a lot like macros :)

это сильный аргумент, да :)

Я знаю что это jit для питона. Так как там с модулями на Си? Да или нет? swig мне сможет сгенерить модуль для pypy ? Да или нет? Мутные доки не хочу вкуривать, а особенно в субботу в 0:58.

Я тебя спросил про подобный JIT компилятор для Perl, ты мне про какие-то модули на Си. C API из CPython поддерживается, но рекомендовано для использования под нагрузкой. Про swig можешь спроси у разработчиков, если тебя это интересует.

опять костыли.

И опять потому что не встроено в язык, а реализовано библиотекой? Да, «сильный» аргумент, ничего не скажешь.

Я тебя спросил про подобный JIT компилятор для Perl, ты мне про какие-то модули на Си. C API из CPython поддерживается, но рекомендовано для использования под нагрузкой. Про swig можешь спроси у разработчиков, если тебя это интересует.

то есть под нагрузкой только python + модули на си, а pypy для «под нагрузкой» не годится? а на кой оно тогда?

И опять потому что не встроено в язык, а реализовано библиотекой? Да, «сильный» аргумент, ничего не скажешь.

там чувак сам написал _не_ _для_ _продакшена_ :)

то есть под нагрузкой только python + модули на си, а pypy для «под нагрузкой» не годится? а на кой оно тогда?

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

С одной стороны очевидное непонимание основ реализации ООП в Perl, постоянное упоминанеие каких-то регекспов, а с другой - явные eval'ы, си. Создается ощущение, что ни один из вас на перле не работает.