Pragmatic Perl

Выпуск 6. Август 2013

Интервью с брайаном ди фоем про будущее. Часть 2

25 и 26 мая в Варшаве прошел первый польский перл-воркшоп. На него приехал и брайан ди фой (brian d foy), который, по его словам, всегда старается побывать на мероприятии в городе, где он еще не был. Брайан уделил нашему журналу час и ответил на вопросы о том, каким он видит будущее: будущее книг, перла, его синтаксиса и сообщества. В этом номере — вторая и заключительная часть интервью (публикуется с сокращениями).

Perl 7

— Вы, разумеется, читали недавние обсуждения про Perl 7. Мы находимся в ситуации, когда Perl 5 развивается, но при этом люди, не знакомые близко с перлом, считают его устаревшим просто потому, что он был выпущен 20 лет назад, и у нас до сих пор пятая версия. Является ли это проблемой, и если да, как ее решить? Нужно ли выпустить Perl 7, пропустив версию 6, или надо сначала доделать и выпустить Perl 6? Проблема не столько в смене версии, а в том, чтобы убедить окружающих, что перл жив.

— Проблема с названиями действительно непростая. Итак, у нас есть Perl 5, и каждый знает, что это. Далее, мы думали, что будет что-то под названием Perl 6, и все, работающие с Perl 5, перейдут на Perl 6. Этого не случилось. Не важно, по какой причине.

Не думаю, что какое-либо название исправит это. Мне кажется, это введет в еще большее заблуждение. Если мы сделаем Perl 7, то придется сказать, что Perl 6 умер. Это не Perl 5, это какая-то следующая версия Perl 6. Остальные названия вроде Pumpkin Perl и другие, которые упоминались, на мой взгляд приведут к расщеплению, которое произошло со многими другими проектами, и никто не знает, что там использовать. То ли Perl 5, то ли perl5i, то ли Perl 6, то ли Perl 7. Никто в этом не разберется, если на это не обращать внимания, и вот это проблема.

Такие вещи могут работать, только если быть внимательным, но дело в том, что большинство как раз не такие. Поскольку те, кто в курсе, не спутают Perl 5 и Perl 6, они знают, что там происходит.

Проблема остается на месте, потому что мы продолжаем делать из этого проблему. На польском Perl-воркшопе был хороший доклад про бизнес и Perl. Суть в том, что никого не интересуют вещи, о которых мы беспокоимся. Желание у бизнеса только одно — чтобы работало. Например, люди пользуются Вордпрессом, потому что он решает задачу, а не потому что кто-то выбирает его из-за того, что он написан на PHP. Я сам пользуюсь Вордпрессом и понятия не имею, какая у меня версия PHP. Мне это неважно.

Если кому-то надо использовать Perl 5, чтобы запустить то, что написано на Perl 5, то им не важно, на какой версии это было создано. Это может быть 5i, Pumpkin, Strawberry или что-то другое.

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

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

У меня нет ответа, поэтому я и не участвовал в этой дискуссии.

— Как вы считаете, достаточно ли хорош нынешний Perl 5 (будь то 5.18 или 5.20 вместе с фичами, которые появились в 5.10), чтобы с него начинать?

— Мне кажется, что текущие версии перла так же хороши для начала, как и, например, 5.6. Потому что все зависит от того, что ты за программист и какой у тебя опыт с другими языками. Есть люди, которые могут легко освоить новый язык, и они знают, что хотят. Если же ты только начинающий программист, то не думаю, что есть какая-то разница, потому что сначала придется научиться самым основам перла. И здесь неважно, 5.8 ли это, 5.10 или 5.20, потому что это в основном скаляры, массивы и хеши, где все одинаково. Не исключено, что до сложных возможностей и не дойдет. Есть какие-то тонкие синтаксические улучшения, но вряд ли они сильно важны.

Будущее CPAN

— В прошлом CPAN был одним из главных преимуществ (killer feature) перла. А так ли это сейчас? Во-первых, там много устаревших и плохих модулей, а во-вторых, есть GitHub, который может посоревноваться со спаном.

— Да, CPAN был нашей киллер-фичей. Если что-то было написано, оно наверняка было на CPAN. CPAN предлагает простой способ установить модуль, но теперь это сложнее, а люди становятся разборчивыми по отношению к скриптам установки модулей. Мы тут немножечко переусердствовали, как и в зависимостях. Иногда вытягивается полспана. Вот сегодня я что-то загрузил и попробовал установить, но это заняло около часа. За это время я, наверное, мог бы решить задачу на чистом перле. Тут нам надо действовать всем вместе. Я бы с радостью посоветовал кому-то много разного привлекательного на CPAN, но я не хочу, чтобы они возились с установкой.

Хранить модули в разных местах — интересная идея. Например, иметь копию на CPAN для установщика типа cpanminus. Потом можно зайти на GitHub или в какой-нибудь частный репозиторий. Не знаю, правда, насколько это поможет. Иметь ссылки на GitHub интересно, но при этом надо быть готовым к возможным поломкам. CPAN мне нравится, потому что я могу с уверенностью сказать, что там лежит конкретный законченный релиз. Ну, на GitHub есть теги и все такое, можно и этим пользоваться, но все это начинает усложнять дело. Очень легко понять, что вот это — версия 1.23 на CPAN. Куда сложнее на гитхабе: «Ага, вот этот аккаунт, или, погоди, нет, кто-то форкнул, и мне нужна именно та версия, а если он ее замерджит обратно, то и я переключусь обратно». Хорошо, конечно, иметь такую гибкость, но, по-моему, ключевая особенность CPAN в том, что там все хранится в едином месте.

На наших глазах другие языки пытались делать нечто подобное. И если там нет чего-то, похожего на CPAN или какого-то центрального хранилища, то заканчивалось это разговорами: “Вот здесь я смогу взять что угодно, мне не придется помнить все детали, и я не хочу помнить, что тот парень покинул проект, и я не смогу больше загрузить из его аккаунта на гитхабе, а нужный модуль надо поискать где-то в другом месте”. А на CPAN сразу можно выяснить, кто это написал, когда оно было зарелизено, какая версия последняя и так далее.

— В гитхабе можно работать над одним проектом совместно. Можно сделать pull request, например. А на CPAN такое не получится.

— Это верно. Возможность совместной работы в GitHub просто замечательна. Я могу зайти в проект на GitHub, форкнуть его, посмотреть на файл, нажать кнопку «Редактировать», прямо в браузере сделать правку, сохранить ее и отправить pull request, ничего не загружая к себе. Наверняка, это принесет мне в десяток раз больше патчей по сравнению со сценарием, когда надо сначала загрузить все к себе, сделать изменение, подготовить патч, отправить его по электронной почте, а потом дергать-дергать-дергать меня. А если у меня есть перед глазами pull request и похоже, что он работает, то — бам! — готово, и я иду дальше.

Но в какой-то момент, когда будет понятно, что получилось что-то осмысленное, можно сказать: «Да, это пора показывать людям, положу-ка я его на CPAN».

Интересно было бы полностью заиметь CPAN на GitHub, храня только ссылки на дистрибутивы, которые уже есть на GitHub, и просто скачивать оттуда каталог, а не копию репозитория. Если кто-то это сделает, я готов это продвигать. Кстати, для Perl 6 ведь была идея указывать при подключении модуля имя автора, версию и источник. Так что, если мы могли бы сделать это с гитхабом для Perl 5, был бы успех.

Будущее Perl

— Кроме CPAN преимуществами считаются регулярные выражения и тот факт, что перл идет почти с любым юниксом. Что еще? Удобная работа со строками. Но все это уже в прошлом, оно уже есть и известно. А можем ли мы добавить в перл что-то эдакое очень хорошее и полезное, чего еще не было? Ведь другие скриптовые языки в каком-то смысле похожи на перл. Может ли Perl предложить что-то действительно новое?

— Важная киллер-фича, которая уже сейчас есть в перле, —– это поддержка юникода. Вроде в 5.18 добавили экспериментальную фичу, которую я еще не пробовал, — операции со множествами в символьных классах. Это означает, что можно сделать символьный класс, который содержит какой-то набор юникодных символов минус несколько других символов. Ну, сейчас это тоже можно делать с помощью юникодных свойств, но вот эта фича –— а Карл Вильямсон (Karl Williamson), по-моему, проделал фантастическую работу, чтобы добавить это в перл, —– последнее, чего не хватало для поддержки юникода на низком уровне, чтобы стать совместимым с рекомендациями консорциума Unicode. Я думаю, Perl может оказаться единственным языком, который совместим во всех деталях.

Проблема в том, что многие еще не программируют для юникода и по-прежнему пользуются Latin-1 или чем-то похожим. В США люди все еще думают в терминах ASCII и не слишком заботятся о юникоде. Мы должны всегда указывать, что вывод ведется в такой-то кодировке, а ввод происходит в такой-то. В США был ASCII, в большинстве стран Европе — Latin-1, в России — что в России?

— Да штук пять было.

— Вот, пять разных кодировок, ОК. Так что вы наверное уже делаете все правильно.

Это реальная мощь, и Perl может ее предоставить.

Мне очень хотелось бы видеть вот что. Когда мы собрались на первую встречу по Perl 6, мы сидели вместе в комнате и начинали думать о том, что нам надо сделать что-то новое, потому что Perl 5 умирает (и об этом постоянно говорят все то время, что я занимаюсь перлом, хотя я вполне себе зарабатываю, так что не понимаю, о чем это). Так вот, что новое надо сделать? Ну, я сказал что-то свое, другие тоже высказались, а Ларри —– я помню, он сидел за столом напротив — долго молчал и ничего не говорил. А потом сказал: «Распределенные вычисления». Вот это и было первым, что мы захотели сделать в Perl 6, а не какие-то интересные фичи или синтаксис. Он хотел, чтобы была возможность сказать: «Я хочу, чтобы эта задача разбилась на несколько маленьких, и язык сам должен решить, как это сделать».

В Perl 6 это, например, заложено в кросс-операторы, когда с одной стороны оператора набор данных и с другой стороны набор; оно все распараллеливается, а потом собирается и результат просто помещается на выход. Как это работает — неважно, оно просто работает. Мне бы такого очень хотелось. Это было бы по-настоящему круто.

Мне кажется, нам надо научиться чему-то из Erlang и Go, мы это вполне можем наверстать.

А еще было бы хорошо, наконец, разобраться с сообщениями об ошибках Can't locate. Это сообщение об ошибке должно выглядеть так: «Невозможно найти такой-то модуль, но если он вам нужен, то установить его можно так-то и так-то». Посмотрите на Stackoverflow, например. Думаю, вопрос номер один там — «Что значит сообщение об ошибке Can't locate?». В сообщении приводятся пути, которые не имеют никакого отношения к исходному коду. Люди видят большой фрагмент текста и не понимают, что с этим делать. Такой подход не решит задачу, но мне кажется, что перлом станут пользоваться чаще.

Будущее сообщества

— Есть еще одна вещь, связанная с перлом, — сообщество, которое, вроде как, непохоже на те, что есть у других языков. Когда-то давно вы основали PM-группы. Как вам кажется, нужны ли там какие-то организационные изменения? Работают ли группы сейчас?

— Это интересная тема. Давным-давно, году в 97-м или 98-м, мы вместе с Дейвом Адлером и Адамом Туроффым (Dave Adler, Adam Turoff) придумали нью-йоркских перл-монгеров. Мы возвращались с Оско… нет, тогда это, наверное, была The Perl Conference, потому что там был только перл. Возвратились оттуда в Нью-Йорк и немного позависали друг с другом. Я как раз туда перебрался, и мне хотелось там с кем-то познакомиться, а я понятия не имел, где. Я работал с перлом, они тоже; у нас были общие темы для обсуждения, так что мы могли вместе посидеть и поговорить. Фильмы там, Доктор Кто. Если мне что-то требовалось, я мог спросить у тех, кто меня знал, например, что мне нужна работа или попросить помочь решить какую-то задачу или еще что-то.

О чем-то можно спросить в онлайне. Но мне по-прежнему кажется, что социальный аспект — самое главное. Но в то же время я понимаю, что у разных групп разные интересы. Вот, к примеру, Тим Маер (Tim Maher) из Сиэтла. Когда он создал группу, он хотел сделать это образовательным коллективом (Educational Collective), по-моему он так это называл (На сайте seattleperl.org упоминается Educational Cooperative — А. Ш.), где он хотел обучать друг друга перлу. Он сделал так, чтобы были и презентации, и обучение, и оно там работало. Джим Кеннан (Jim Kennan) сделал что-то похожее в Нью-Йорке.

Мне нравится, что я могу поехать на конференцию почти куда угодно в мире и встретить там перловиков. Конференции делают те, кто создает пользовательские группы на местах. Вот, например, польский воркшоп организован Warsaw.pm. Если я еду в Лондон, могу выпить с London.pm. Если я оказался Амстердаме, то скорее всего появлюсь в пабе. Это возможно потому, что мы знаем друг друга. Мне не обязательно смотреть презентацию или делать технический доклад или что-то другое формальное. Я могу просто сказать: «Эй, мы знакомы, давай замутим что-нибудь». И мне кажется, что это действительно важно — знать друг друга. Если ты находишься внутри Perl-сообщества, то наверняка знаешь кого-то в каждой временной зоне.

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

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

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

■ Андрей Шитов