Pragmatic Perl

Выпуск 10. Декабрь 2013

Интервью с Marc Lehmann. Часть 2

Marc Lehmann — автор AnyEvent, Coro, common::sense, JSON::XS и многих других популярных модулей на CPAN. Продолжение интервью из предыдущего номера.

Где сейчас работаешь? Perl — основной язык?

Я работаю в nethype GmbH в Германии, в компании, которую я основал вместе со своим другом, когда мы вместе учились.

К счастью, Perl — это наш основной язык, который мы используем для всего, начиная от распределенного трейдинга, высокопроизводительных DHCP- или radius-серверов, и заканчивая обычными SMTP-пауками, веб-приложениями или даже онлайн-играми (например, Deliantra). Также повезло с тем, что мы можем часто публиковать свои модули, написанные по работе, как свободный софт.

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

Нравится ли посещать Perl-конференции?

Конечно! В основном из-за возможности пообщаться с другими Perl-чудаками (ну, и нормальными посетителями :).

Однако, заставить себя куда-то поехать это совершенно другая история — я очень ленивый, поэтому сейчас я посещаю гораздо меньше конференций, чем раньше. Все это планирование, перелет или переезд (и подготовка выступления)… слишком много усилий (также я стараюсь не ездить в США, из-за сложных политических причин).

Если я мог себя заставить, то никогда не жалел, но меня нужно сильно уговаривать.

Что думаешь о будущем Perl?

К 2050 году я и еще парочка людей все еще используем Perl, зарабатывая большие деньги на поддержке cobol^WPerl-программ, от которых из-за борьбы с глобальным потеплением зависит большинство населения планеты. Я становлюсь богатым, остальной мир же голодает и умирает до тех пор, пока электричество не пропадет и мои деньги не обесценятся, и тогда приходит всему трындец.

Простите, кажется, я приплел сюда свое будущее.

В реальности, я думаю, что Perl 6 продолжит свою медленную и необходимую смерть, давая Perl больше пространства для сущестования и, возможно, роста.

Не думаю, что какие-либо улучшения (если это улучшения) в ядре Perl сильно повлияют на будущее языка — Perl определенно достаточно хорош, также как и CPAN.

Но я все-таки считаю, что Perl уже не “моден”. Это и еще тот факт, что Perl уже не один в своей категории, сильно уменьшит важность языка, потому что меньше людей будут учить Perl или относиться к нему как к “основному языку”.

Для меня это не плохо и вполне естесственно. Я думаю, что сила Perl не в его инновационности, а в заслуженном доверии и надежности. Это не очень хорошо для роста, но Perl еще будет полезным, когда другие более модные языки будут забыты.

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

Лично я бы хотел, чтобы приоритет был у обратной совместимости и сохранении CPAN в рабочем состоянии, без постоянного ломания модулей.

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

Поэтому, я думаю, что Perl не умрет, а сохранит свое месте среди популярных языков, и, возможно, сможет расти, сохраняя написанные тонны кода рабочими.

Стоит ли сейчас советовать молодым людям изучать Perl?

Конечно — это великолепный и очень полезный язык. Некоторые могут поспорить, что Java лучше для Денежно-Ориентированного Программирования, а программистов C++ чаще ищут работодатели, но кроме немного сложного процесса поиска работы из-за своей экзотичности, нет ничего странного, когда Perl это первый или второй язык программирования, да и просто веселее писать на Perl, чем на Java, что очень полезно для здоровья.

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

Представьте только, что если бы я не попробовал VI потому что мне сказали, что он старый и немодный, я был бы вечно несчастлив с GNU Emacs. Ужас.

Есть, правда, небольшая проблема: иногда меня спрашивают, как выучить Perl, и я обычно здесь теряюсь, так как сам выучил этот язык, читая документацию и исходный код, что вероятно не самый простой способ. Если смотреть на книги, то многие из них не ориентированы на новичков, например в “Learning Perl” издательства O’Reilly четко сказано, что книга не научит вас программировать. Да и многие другие книги, на которые я смотрел, учат Perl в качестве второго языка (или вообще не очень хорошие). Но нашел одно исключение — это “Beginning Perl” от Simon Cozens (она также в сводобном доступе!).

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

Но у самого языка нет никаких проблем.

Вопросы от читателей

Почему до сих пор пользуешься CVS?

Короткий ответ: потому что работает.

Длинный ответ:

CVS до сих пор сносно справляется со всем, что мне требуется. Git, например, требует больше команд для выполнений тех же checkout/update/commit-действий в CVS, и со множеством сложностей при работе в небольшой команде (будучи больше ориентированной на распределенную разработку!). SVN в действительности еще хуже, чем CVS (те же самые команды, те же ограничения, но длиннее URL и эта странная модель “копирования” от которой пухнет голова). Если вдруг CVS перестанет мне походить, я, возможно, посмотрю на Mercurial, эта система видится мне не такой сумасшедшей как git.

Я совсем не религиозен по отношению к CVS (но удивительно, как много людей религиозны по отношению к git и постоянно достают меня, чтобы я перешел на эту систему) — мне ее достаточно. Зачем что-то менять, если оно вам подходит: сэкономленное время я могу потратить где-нибудь еще.

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

Ты широко известен за высказывание своего мнения в жесткой манере. Это происходит намеренно?

Да и нет — обычно у меня есть мнение насчет вещей или концепций, но не о людях, поэтому я не очень понимаю, почему мне стоит сдерживаться — я не могу обидеть чувства вещи или концепции. Я часто могу обосновать свою точку зрения (даже если я неправ, я стараюсь в разумных пределах пытаться быть правым, вместо того, чтобы навыдумывать безосновательного бреда). Это все помогает мне иметь и высказывать устойчивое мнение и редко бывать неправым. Также это помогает сдерживать себя в темах, о которых ты мало что знаешь.

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

Это подтверждается моим опытом в других “не-Perl сообществах”, где я совсем не известен таким поведением (у меня есть несколько популярных библиотек и программ, написаных не на Perl…).

Считаешь себя частью Perl-сообщества?

Это зависит от того, что понимать под “Perl-сообществом”.

На первом Perl-воркшопе в Германии я был потрясен, когда увидел такое разнообразие участников: менеджеры, гики, любители; у них не было ничего общего между собой, кроме Perl. Было ли это Perl-сообществом? Не знаю, но мне кажется, что нет.

Я выкладываю модули на CPAN и считаю себя частью этого “сообщества”. Я не считаю себя частью движения “modern perl” (если таковое даже существует).

Поэтому я не знаю, каким должно быть “Perl-сообщество”, и я подозреваю, что нет единого сообщества, а, скорее всего, несколько разных.

Одно я могу сказать точно: большинство моих проектов не имеют вокруг себя “сообщества”. Я разрабатываю софт для себя, и это часто означает, что я не буду добавлять новые возможности, которые сам не буду использовать (или поддерживать). По этой причине я разрабатываю таким образом, чтобы другие могли расширять функционал — это позволяет мне отклонять запросы на внесение изменений.

Изменилась ли ситуация с rt.cpan.org?

Все стало намного хуже. Были некоторые косметические изменения (например, уведомления на некоторых страницах), но основной эффект в том, что rt.cpan.org еще сложнее не использовать. В основе лежит та же проблема, что была вначале: этот сервис навязывается людям, и его нельзя отключить (последняя проверка: начало 2013).

Были попытки на стороне rt.cpan.org скрыть эту проблему, но никаких попыток для улучшения ситуации. Это похоже на игру, в которую я не хочу играть. Это сильно раздражает, похоже на принудительную подписку на рассылку microsoft или что-то в этом роде, только нельзя это игнорировать как спам, потому что есть другие люди, которые также являются жертвами этой системы.

Я хочу, чтобы была простая кнопка для отключения rt.cpan.org от моих модулей, или возможность заменить его на пересылку почты. Но есть те, кто в этом не заинтересован, и поэтому это невозможно.

Насколько стабильна обвязка OpenCL для Perl? Какие преимущества в использовании этой библиотеки из Perl по сравнению с C/C++?

За последние полтора года у меня не было необходимости в новом релизе, и эта библиотека продолжает надежно работать. Предполагаю, что много предстоит работы, когда NVidia будет наконец поддерживать OpenCL 1.2 (или даже 2.0), и я смогу улучшить поддержку этой версии (у меня до сих пор есть только один драйвер для тестирования версии 1.1).

И преимущества использования OpenCL из Perl, в отличие от C/C++, в том, что ее можно использовать из Perl, дурилка :->

Почему AnyEvent по-особенному обрабатывает IO::Async?

Короткий ответ: потому что другие бэкэнды не работают с IO::Async.

Длинный ответ: IO::Async использует свой собственный мультиплексор (вместо того, что быть фреймворком, который находится над ним). Для каждого несовместимого обработчика событий должен быть свой бэкэнд — также как и для EV или Event, должен быть и для IO::Async.

Если бы IO::Async использовал другие обработчики событий (например, через AnyEvent, или напрямую через EV), тогда такого бэкэнда не было бы нужно. AnyEvent использовал бы тот же бэкэнд, что и IO::Async, и они бы мирно сосуществовали.

(Для любителей технических подробностей: в обычной ситуации было бы достаточно интерфейса к IO::Async::Loop, который бы реализовывал обработчик событий IO::Async, но этот модуль — редкий пример библиотеки, которая не поддерживает разделение ресурсов между несколькими пользователями, поэтому, чтобы работать с IO::Async, AnyEvent, к сожалению, приходится использовать сам IO::Async (и все равно требуются дополнительные настройки — приходится сообщать AnyEvent, какой экземпляр стоит использовать)).

Кроме этого нет никаких особенных обработок IO::Async, модуль обрабатывается специфично, но в обычном режиме AnyEvent.

Есть один неоднозначный участок кода, который отключает себя, когда работает с модулем IO::Async::Loop::AnyEvent. Этот модуль не нужен, чтобы работать с IO::Async, также он не является частью IO::Async, скорее всего, именно из-за этого модуля и возник сам вопрос.

История этого модуля в том, что AnyEvent сидит сверху IO::Async как обработчике событий, но этот модуль пытается перевернуть все с ног на голову и быть сверху AnyEvent. Это вызывает бесконечную рекурсию и ведет к другим очевидным или неуловимым проблемам, и, в конечном счете, приводит к баг-репортам в моем почтовом ящике.

Я написал автору IO::Async об этой проблеме и объяснил, как IO::Async может правильно использовать AnyEvent, но так и не получил ответа (позже автор публично признал, что проигнорировал мое письмо, так ему было все равно).

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

Самая неприятная и болезненная деталь в этой истории состоит в том, что автор POE использовал данный факт для начала клеветнической кампании против меня, обманывая людей, которым не свойственно самостоятельно искать доказательства — ответственный за выпуск perl 5 даже попросил CPAN удалить мои модули (и позже извинился за то, что сам не разобрался). Я скажу четко и недвусмысленно: AnyEvent не обрабатывает и никогда не обрабатывал IO::Async как-то иначе по отношению к другим бэкэндам, вне случаев, когда это обуславливалось разницей в API.

Подытожим: несмотря на костыльность, AnyEvent продолжает поддерживать IO::Async насколько это возможно: два модуля, использующие IO::Async, не могут прозрачно сосуществовать без определенных предосторожностей, что приходится реализовавывать несчастному пользователю.

До тех пор, пока вы используете AnyEvent::Impl::IOAsync::set_loop, AnyEvent будет работать.

Какой вид “Спасибо” предпочитаешь? Литры или бутылки?

У меня есть проблема со всеми видами “Спасибо”, чем бы это ни было. Я это делал не для вас, поэтому мне сложно принимать благодарности (наверное, запущенный синдром Аспергера).

Если вам хочется поблагодарить меня за модуль (или за что угодно, в общем-то), не говорите мне, скажите другим об этом модуле — если модуль был каким-то образом полезен вам, расскажите и другим о нем. И наоборот, если вам не нравится мой код (не путайте, если вам не нравлюсь я лично), критикуйте и не советуйте.

Конечно, мне нравится слышать, что люди используют мои разработки (когда я выпустил JSON::XS 2.0, посыпалось много писем по типу “зачем ты изменил API такого широко используемого модуля”, когда на самом деле я и не думал, что им кто-то пользовался, так как никто мне об этом не говорил; может мне стоит добавить несколько багов, чтобы получить фидбэк?), так что черкните мне пару строчек, что именно вам пригодилось (можете сказать спасибо, если это действительно необходимо, но помните, что мне проще иметь дело к объективными вещами, чем с чувствами, поэтому не злитесь, если я проигнорирую часть, где вы меня благодарите — я просто не знаю, что сказать).

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

■ Вячеслав Тихановский