Три товарища — Дейв Кросс, Грег Маккарол и Джозетт Гарсия — встретились прошлым летом на YAPC::Europe в Лиссабоне и решили поведать миру о том, что сейчас происходит с перлом. Поскольку Дамиан Конвей, один из ключевых дизайнеров Perl 6, делал на конференции доклад, они подумали, что могли бы задать ему несколько вопросов. Чтобы собрать вместе все вопросы и ответы и закончить интервью потребовался — в духе разработки Perl 6 — почти год, но на прошлой неделе все, наконец, было готово.
Оригинальный текст под заголовком «Damian Conway on Perl and its future» опубликован на сайте O’Reilly GMT 25 мая 2010 г.
Перевод Андрея Шитова.
Perl мертв
Дэйв: Мы часто слышим, как говорят: «Perl — мертв». Я полагаю, что вы не согласны, но что вы отвечаете людям, которые говорят вам это?
Обычно я отвечаю: «Я согласен. Жаль, не так ли?». После этого сумасшедшие тихо сливаются, а я могу опять загрузить новый или улучшенный перл-модуль, увеличивая нынешние семь гигабайт открытого кода на спане (как это каждый месяц делают более 700 других разработчиков), или поехать на десятки перл-конференций и воркшопов, которые ежегодно проводятся во всем мире, или посетить одну из 250 PM-групп в 58 странах, или пообщаться с тысячами единомышленников, помогающих друг другу на главном сайте про изучение перла perlmonks.org, или принять участие в онлайновой социальной и образовательной деятельности (например, в соревновании Perl Iron Man), или обновиться до нового релиза Perl 5 и Perl 6 (оба они теперь выходят ежемесячно), или внести вклад в активный процесс разработки либо одной из двух реализаций Perl 5, либо в одну из четырех — Perl 6, или обучить десяткам новых возможностей, которые добавлены в Perl 5.10 и Perl 5.12 за последние три года, или заняться разной деятельностью по омоложению перла (enlightenedperl.org и modernperlbooks.com) или просто почитать замечательный обзор Тима Банса о том, насколько, на самом деле, мертвый перл жив, как никогда.
Я могу только надеяться, что когда сам умру, то буду таким же энергичным и активным, и стану так же быстро расти, как перл сейчас.
Грег: Многие сталкиваются с руководителями, которые считают перл умирающим языком, не говоря уже о переходе на новую работу, какой совет вы бы дали им, чтобы поддержать язык?
Ну, прежде всего, см. выше.
Кроме того, им нужно посмотреть на дело глазами руководителя. Многие перл-разработчики видят цель в разработке на перле; их руководитель же видит свои задачи в дешевой, надежной, устойчивой, поддерживаемой и быстрой разработке и с минимально возможным риском. На каком бы языке это не достигалось.
Так что защитники перла должны направить свои аргументы в его использовании на эти нужды вместо своего собственного желания использовать перл. Другими словами, им нужно показать бизнес-сторону перла, а не только техническую.
Такая бизнес-составляющая может включать в себя большое число великолепных программистов, которые пишут на перле, их знакомство и умения в существующих командах, огромные ресурсы свободного ПО на спане, большое число зрелых, мощных и масштабируемых фреймворков, которые сейчас доступны для перла, скорость, с которой на перле удается создавать и разворачивать системы, то, как высокоуровневая сущность перла упрощает частые низкоуровневые задачи, число больших организаций, которые на перле успешно сделали критически важные системы (например: www.perltraining.com.au/whyperl.html#who, www.perlfoundation.org/perl5/index.cgi?companies_using_perl, www.london.pm.org/advocacy, www.proudtouseperl.com или blog.listcentral.me/2009/05/22/companies-that-use-perl).
Продать перл руководству — значит объяснить перл теми понятиями, о которых оно заботится: стабильность, надежность, мощь, эффективность, дешевизна, обслуживаемость, хорошая поддерживаемость и ориентированность на будущее.
Джозетт: Недавно Мартин Драшков написал статью «Why Perl lost it». Что вы думаете о заключительном утверждении: «Будет ли перл продолжать движение вниз, сказать трудно, но я сильно сомневаюсь, что он когда-либо вернет себе прежнюю славу — похоже, что и Perl 5, и Perl 6 не много могут предложить тем, кто перл уже не любит»?
При уважении к Мартину, чьей другой работой я восхищаюсь, я думаю, что его изначальное утверждение (о том, что перл двигается вниз) весьма сомнительно, и его последнее наблюдение сильно противоречит той реакции, которую я вижу, когда рассказываю людям о Perl 6.
Мне кажется, что последние версии и Perl 5, и Perl 6 на самом деле предлагают много того, что нравится тем, кто уже любит перл, но я думаю, что у Perl 6, по крайней мере, огромный объем того, что привлечет тех, кто прежде считал Perl 5 неудовлетворительным. От крайне передовой ОО-модели до невероятно мощных встроенных грамматик, до легкого в использовании встроенного параллелелизма, до весьма удобной множественной диспетчеризации, до хорошо интегрированным первоклассным макровозможностям, до невероятной поддержке для создания предметно-ориентированных языков, мне кажется, что Perl 6 может предложить много чего для всех разработчиков. Мы потратили десятилетие, заимствуя лучшие идеи из лучших языков программирования, и сделали их простыми и практичными для рядовых разработчиков. Я думаю, результат должен привлечь многих.
Кстати, процитированную статью все равно стоит прочесть, особенно комментарии к ней, которые более или менее развенчивают каждое утверждение, сделанное Мартином.
Грег: Многие перл-программисты сталкиваются со старой кодовой базой, полной разных стилей кодирования, часто для нее сложно написать юнит-тесты, а есть ли у вас какая-нибудь идея — серебряная пуля или хотя бы просто мысли о том, как понимать и работать с этим устаревающим кодом?
Никаких серебряных пуль, а один простой и сбивающий с толку принцип: «Начинайте изменяться... сегодня!»
Рефакторинг большого объема неоднородного кода обычно невыполним и даже не полезен (хочется сказать, что он привносит баги), но, по крайней мере, можно перестать добавлять проблемы при добавлении кода.
Простейший подход — чтобы команда согласовала стандарт кодирования и процесс тестирования и затем начала применять эти ограничения ко всякой новой (или часто затрагиваемой) части кода. Как минимум, это не усугубит проблему с ростом программы, а процент грязного кода неприменно уменьшится.
Никакого волшебства, но это работает. Изменение стиля кодирования и привлечение фреймворков для тестирования при поддержке фокусирует усилия на частях кода, где улучшения дают команде больше всего пользы; а именно, тем, кто чаще всего взаимодействуют с кодом. И если они последовательно используют новый стиль кодирования и тестирование в новых разработках, то при переделке существующиего кода будет легко применить их верным способом.
Наконец, из-за того, что они делают рефакторинг и изменяют стиль кода, который наиболее активно поддерживают, более вероятно, что заново они напишут его правильно.
Задержка Perl 6
Дэйв: На YAPC в Лиссабоне Патрик сообщил, что первая версия Perl 6 (названная Rakudo Star) будет выпущена весной 2010. Чего вы ждете больше всего от выхода Perl 6?
Все просто: я больше всего жду, что меня перестанут спрашивать, когда выйдет Perl 6.
А серьезно, я действительно жду, что на Perl 6 будет возможно писать промышленные системы. На этом языке одно удовольствие кодировать, и очень обидно вот уже несколько лет иметь возможность программировать на нем лишь в голове. Теперь, когда Ракудо можно использовать, я переключу большую часть своей разработки на Perl 6, это как выход из заключения, о котором я даже не подозревал, что нахожусь в нем (точно так же, как это было, когда я впервые переключился с Паскаля на C, а затем с C на перл).
Еще я очень ожидаю увидеть то, что большое перл-сообщество будет делать с новым инструментом. У меня обширные планы на собственные новые проекты, но еще более я буду рад увидеть восхитительные, блистательные и самые неожиданные чудеса, которые наше сообщество создаст на основе Perl 6.
Грег: Как вы думаете, в каком году Perl 6 станет использоваться в серьезных приложениях в бизнесе, скажем в десяти крупных (с оборотом больше пяти миллионов евро) компаниях, и будут ли это разработки с нуля или на основе существующего кода на перле?
Когда бы это ни случилось, почти определенно это будет свежий код (хотя возможно просто новой реализацией существующих приложений на Perl 5, яве или питоне). Я думаю, большинство работы с Perl 6 будет связано с созданием нового кода, а не миграцией существующего на Perl 5. Просто потому, что Perl 5 по-прежнему продолжит существовать, так что не возникнет нужды в переделывании существующих программ.
Что касается даты, я бы сказал, что, вероятно, для достижения нужного уровня проникновения, принятия и доверия, Perl 6 понадобится от трех до пяти лет.
Грег: Какая, по-вашему, лучшая возможность, которую получил Perl 5.x при работе над Perl 6?
Трудный вопрос. Лично мне больше всего нравится самая простая: функция say, вошедшая в Perl 5.10. Она решает то, что в Perl 5 раздражает чаще всего: непрекращающуюся нужду добавлять перевод строки в конце большинства вызовов print. Не то чтобы очень, но это снижает постоянное раздражение, которое преследовало меня по крайней мере двадцать раз на дню.
Еще я очень неравнодушен к смартматчингу и конструкции given/when. Оказалось, в своей текущей работе на Perl 5 я использую ее на удивление часто.
Дэйв: Когда выйдет Perl 6.1? И что в нем будет?
Вероятно, по крайней мере через год после Perl 6.0, который сам появится через полгода-год. Боюсь, я не слишком компетентен в этом вопросе, это полностью зависит от разработчиков.
Что касается того, что мы, скорее всего, добавим в Perl 6 в следующем основном релизе, то там, надеюсь, появится не слишком много. Вся суть дизайна Perl 6 — в попытке предоставить достаточно возможностей, чтобы недостающее было возможно добавить непосредственно из языка, а не через внедрение этого в сам язык.
Надо сказать, что я думаю, нашим интересом в то время будет потоковая модель Perl 6 и параллельные вычисления, и я ожидаю, что Perl 6.1 в этом отношении станет более продвинутым и полным.
Perl / Вычисления вообще / Все остальное
Дэйв: Какой из ваших модулей на спане самый полезный? А какой наименее полезен?
Похоже, наиболее широко используются Parse::RecDescent, Text::Autoformat и Regexp::Common. Не уверен, что это означает, что они самые полезные.
С другой стороны, можно поспорить, что чаще всего используется модуль Switch, поскольку, несмотря на его очевидные недостатки (а, возможно, именно из-за них!), он в итоге привел к тому, что в Perl 5.10 и Perl 6 добавились собственные версии given/when и смартматчинга.
Наименее полезный? Это, конечно, выяснить куда сложнее, чем хотелось бы. Очевидные претенденты — Lingua::Romana::Perligata (перл в грамматике латыни) и Coy (сообщения об ошибках, преобразованные в хайку), хотя я и знаю о том, что оба используются в продакшне.
Так что вероятно Acme::Bleach (перл, написанный одними пробелами). Особенно потому, что я знаю, что люди по ошибке пытались использовать этот модуль для «защиты» кода. Ох.
Джозетт: Мне постоянно говорят, что программы, написанные на перле, часто не могут прочитать другие перл-программисты, и что этой проблемы не возникает с программами, написанными на других языках, таких как питон. Согласны ли вы с этим утверждением и можете ли объяснить, почему так произошло?
Я слышу такое постоянно, но это попросту неверное утверждение. Я вижу много разного перл-кода в разном стиле, и могу читать большинство из этого без проблем. Я вижу много кода с непоследовательным стилем кодирования, с поддержкой которого другие программисты не испытывают непреодолимых трудностей.
Конечно, стандартный набор соглашений по кодированию — отличная идея и он должен у всех быть на первом месте. Но согласованное кодирование в читаемом стиле требует определенной дисциплины, которая не всем свойственна. Существует неизбежная кривая обучения: для отдельного программиста, для команды и для всего перл-сообщества. Я думаю, как сообщество мы хорошо прогрессируем, но суть согласованности и написания таким образом, чтобы было возможно читать, все равно сводится к индивидуальным программистам.
И — да, я часто слышу утверждение, что код, написанный на питоне (или яве, или на Эйфеле, или на любом другом языке, менее гибком, чем перл) по определению более читаем. Но это утверждение игнорирует фундаментальный факт о том, что синтаксис — лишь одно измерение, в котором люди выражают свою особенность и непоследовательность. И, во многих отношениях, наименее важное измерение.
Разумеется, весь код на питоне внешне должен выглядеть одинаково, но это лишь смещает внутреннюю сложность кода в какое-то другое измерение. Обычно это проявляется где-то в другом месте, в непоследовательном именовании переменных или методов, или в использовании трудных для понимания структур данных, или в странных API библиотек, или в пересечении функционального или процедурного стилей в том, как питон понимает объектное ориентирование.
В общем, плохие программисты будут программировать нечитаемо на любом языке. Перл лишь позволяет им делать это на самом простом и наиболее легком уровне — синтаксическом.
Грег: Если бы не существовало перла, какой язык вы бы выбрали?
Если бы перла не существовало, мне кажется, у меня бы возникла потребность его придумать. Наверное, неудачно.
На самом деле, это более или менее то, чем я занимался, когда обнаружил перл: я работал над дизайном динамического языка OOK (Object-Oriented Kernel). Но я отказался от него сразу как понял, что перл уже предлагает всю ту мощь, удобство и гибкость, к которой я стремился в собственном дизайне.
Если бы мне запретили создавать собственную замену несуществующего перла (и предполагая, следовательно, что не было бы руби), я подозреваю, что остановил бы свой выбор на питоне. Хотя я совсем не уверен, что был бы силой добра в том сообществе.
Или, возможно, я бы смотрел в сторону чего-то типа Lua и Sather. У них обоих огромный потенциал, который, правда, не принес популярности или доли на рынке. Была бы хорошая возможность внести свою лепту.
Грег: Какие некомпьютерные книги вы порекомендовали бы прочитать программистам?
Программирование — по сути созидательная работа, так что критически важно подкармливать креативность из внешних дисциплин. Меня самого всегда интересовали новые модели и метафоры вычислений и лучшие идеи интерфейсов, так что я по максимуму стараюсь читать что-либо научное (особенно, по физике и математике) и литературу о дизайне вообще. Но это я, а большинство такое чтение не вдохновило бы.
Так что общий ответ, я думаю, в том, что нужно искать книги, которые расширяют сознание непредсказуемым образом, которые выносят за привычные способы размышления и видения мира, ставят под сомнение собственные предположения и уверенность. Лучшие образцы: «Дизайн привычных вещей» Дональна Нормана, «Фрикономика» Стивена Дабнера и Стивена Левитта, «Ружья, микробы и сталь» Джареда Даймонда, «Государь» Макиавелли, «Поймай меня, если сможешь» Франка Эбигейла, «Затерянные в космосе» Уокера Перси или просто что-нибудь, написанное Дугласом Хофштадтером (к сожалению, многие останавливаются на «Геделе, Эшере, Бахе»).
Не скажу, что я согласен с каждой идеей или теорией в этих книгах или даже с большинством из них, но мне кажется, что каждая книга заставляет задуматься о наших уютных ожиданиях и убеждениях. И мне кажется, это очень важно.
Повседневное программирование во многом монотонно. Необходимо преодолеть эту однообразность, если хочется стать лучшим программистом. А умение мыслить за пределами рамок (и даже просто признать их существование!) для такого роста необходимо.
Думаю, в том числе и поэтому многие программисты естественно тяготеют к научной фантастике. Действительно хорошая фантастика переносит за пределы собственных предположений именно в этом направлении.
Дэйв: В 2009 году в Лиссабоне вы начали заниматься другим видом обучения — персональными тренировками в тренажерном зале. Какой вид обучения вам больше всего нравится?
Прежде всего, я педагог. Не имеет значения, обучаю ли я вычислительной технике, перлу или виму, или навыкам презентации, или силовым упражнениями, военному искусству или чему угодно еще: я просто люблю обучать, люблю наблюдать, как люди открывают новые знания в мире и новые возможности в себе.
Надо сказать, я стал завсегдатаем тренажерного зала раньше, чем хакером, так что в том, что я помогаю людям улучшать их силовые навыки, и, более важно, развивать уверенность и умственную дисциплину, которые нужны для достижения их физических целей, несомненно играет роль «первая любовь».
Грег: Представьте, что мы отправляем вас на остров, где можно программировать только на C, но мы разрешим взять с собой одну роскошную возможность из перла, какую бы вы взяли?
Определенно, управление памятью и сборщик мусора. Мне, на самом деле, нравится практический характер программирования на C, кроме утомительной необходимости делать malloc, realloc и освобождать память... особенно для строк.
Джозетт: Самое главное, будете ли вы обновлять свои книги и писать новые, если да, то когда мы можем ждать чего-то нового?
Я только что начал работу над новой книгой... про Perl 6. Надеюсь, она появится где-то в следующем году.
Что касается выхода вторых изданий, я, конечно, хочу пересмотреть «Perl Best Practices». За последние пять лет я столько нового узнал о хорошем программировании. То, как сообщество понимает слово best и имеющиеся у него инструменты, тоже значительно изменилось за это время. Но, если бы я задумался о втором издании, то надо, конечно, отследить еще несколько лет. Есть столько разных проектов, и так мало времени ими заняться.
Джозетт: 11 августа 2010 года вы согласились провести в Лондоне курс «Understanding Regular Expressions». Что получит участник такого курса? Как это поможет в его карьере?
Регулярные выражения — инструмент, которым должен владеть почти каждый программист, и, несомненно, каждый перл-программист. Регексы, особенно перловые, слишком полезны, мощны и эффективны, чтобы их игнорировать, если приходится заниматься любыми задачами по обработке текста.
Кроме того, механизм перловых регулярных выражений настолько мощный, что часто кусает руку разработчика. Многие, на самом деле, боятся использовать регексы и не уверены, что могут делать это правильно и эффективно.
Я возлагаю большую часть вины на то, как традиционно обучают регексам или даже на тот факт, что им не обучают вообще... от вас ждут, что вы сами научитесь, когда придется.
Это означает, что у большинства очень слабое представление о том, чем в действительности являются регексы и никакого понятия, как их составлять. Сама идея дизайна регулярных выражений (даже при том, что возможен дизайн программы) кажется странной большинству людей.
Так что нацеленность этого предстоящего курса — вернуть текущих (не)пользователей регулярных выражений к основам того, чем являются регексы, как они работают и как их можно составлять и оптимизировать (а не просто клонировать из существующих приложений, наполовину случайно адаптируя к новым задачам).
Кто получит пользу от большего понимания регексов? Каждый перл-программист, потому что регексы — неотъемлемая часть перла и позволяет эффективно делать работу. Особенно тем, кто работает с любыми видами текстов или строковых данных, распознает или обрабатывает их.
Как это им поможет? Это вооружит глубоким пониманием мощного инструмента. Уменьшит неуверенность и трепет перед созданием или поддержкой регулярных выражений в существующем коде. Увеличит ассортимент программистских навыков и техник. Другими словами, поможет стать лучшим, более широким и более компетентным программистом.
Джозетт: Как я понимаю, в апреле-августе вы в разъездах. Поскольку перл-сообщество будет радо встретиться с вами или послушать вас, не могли бы вы обнародовать свой маршрут?
Конечно. Он всегда доступен на странице damian.conway.org/Events.
conway, interview, lisbon, yapc — 27 мая 2010
В мае 2010 в Москве побывал Карл Мэсак, программист из Швеции, который принимает активное участие в развитии Perl 6. Мы встретились и поговорили о нем самом, о новом языке, о том, что с ним происходит и о том, как привлечь к языку большее внимание.
— Почему вы стали изучать Perl 6 и присоединились к его разработке? Это произошло не в 2000-м, а гораздо позже, когда язык был уже довольно зрелым.
— Не помню, когда я впервые услышал о Perl 6, это было где-то в 2003-2004-м. Тогда я начал читать Apocalypses и подписался на списки рассылки. А потом появился Pugs, и я втянулся в то неистовство происходящего с его разработкой. Я внес свой, совсем небольшой вклад, но при этом было очень приятно видеть, как Pugs развивается и крепнет, а Perl 6 оживает.
В 2007-м Pugs прекратил развитие, и я подумал: «Что же теперь? У нас больше никогда не будет Perl 6? Одна попытка и все?» Из-за того, что я не знал, что делать, я начал смотреть на Rakudo. В 2007-м Rakudo был еще небольшим и не мог делать многого, особенно по сравнению с Pugs, но, тем не менее, мы с другом решили его попробовать и создать движок вики. Это было летом 2008-го. То был лишь небольшой проект, который мы задумали сделать летом ради развлечения. И мы его написали :-)
— А сейчас вы создаете свою собственную «еще одну» реализацию Perl 6, Yapsi.
— Да, хотя это больше шутка. Это честная реализация, но мы по сути любители, которые пытаются делать что-то для себя, чтобы поучиться и воспользоваться компилятором для собственных нужд.
— Кто «мы»?
— Над Yapsi вместе со мной работает snarkyboojum, мы двое — основные разработчики.
— Он тоже верит, что Perl 6 когда-либо появится?
— Perl 6 уже появился. Сейчас надо заполнить пробелы. Возможно, несколько противоречиво, но я на самом деле не верю в будущую дату выхода Perl 6. На мой взгляд, он уже выпущен. Настолько, насколько возможно. Конечно, мы можем назначить дату и сказать, что в этот момент спецификация очень-очень стабильна, но это не сильно повлияет ни на меня, ни на мою программистскую жизнь. Я пользуюсь Perl 6 более или менее ежедневно. Он не сверхстабилен, но, по крайней мере, вполне реален.
— Для Perl 5 существует большой CPAN, который является сильным аргументом в разного рода спорах. А будет ли полезен Perl 6 без CPAN?
— Полезность — относительный термин, люди понимают ее по-разному. Однажды я пришел в канал #perl на irc.perl.org, мы говорили о том, полезен ли Perl 6, и мнение участников, в основном, затрагивало вопросы: «Есть ли модуль для работы с базой данных?», «Есть ли CGI?» и т. п., поскольку они так привыкли использовать CPAN, что Perl для них — и есть сам CPAN. Было бы очень большим шагом иметь хороший доступ к CPAN, но мне кажется, что и без этого Perl 6 может быть полезен в меньших задачах. Существует много маленьких скриптов, которые возможно написать на Perl 5 даже без использования CPAN. Вероятно лишь, что их полезность будет в 100 или 1000 раз меньше, так что хвастаться особо нечем.
— Вы были одним из тех, кто пытался реализовать то, что доступно в Perl 5 — модуль CGI.pm — на новом языке. Много ли сегодя подобных разработок? Существует библиотека для работы с датами и временем, доступна возможность вызывать функции libmysql, а есть ли другие проекты?
— Есть целый список проектов, упомянутых на proto.perl6.org, там где-то 30-40 проектов. Я, правда, не знаю, что эти цифры означают, потому что хотя проекты и существуют, не все из них сейчас развиваются. Некоторые, возможно, не обновлялись год. Но в общем, мне кажется, что люди заполняют потребность в коде для своих непосредственных нужд. Так что если у кого-то есть потребность подключиться к базе данных, они хотят найти простой способ это сделать: либо сделать это напрямую из Perl 6, или через Parrot или обертку на Perl 5.
— ОК, сиюминутные нужны как-то охвачены, а что в перспективе? Однажды меня спросили, будут ли новички в программировании выбирать Perl — не важно, пятой или шестой версии — после того, как появится Perl 6. Предпочтут ли они Perl другим языкам?
— Не думаю, что пока Perl 6 сам себе повод выбрать Perl 6 вместо Perl 5. Обычно, когда новички приходят в канал #perl6, они задают этот вопрос. Вопрос типа: «Привет! Я только что прочитал о Perl 6, он супер! Могу ли я не учить Perl 5?». Обычный ответ на это: «Вероятно, стоит хорошо присмотреться к Perl 5, потому что на сегодня Perl 5 куда мощнее Perl 6 и сможет решить задачи быстрее и легче». Пока изучение Perl 6 не означает, что не нужно знакомиться с Perl 5.
— Мне кажется, что изучение Perl 5 до Perl 6 напоминает освоение ламповой схемотехники перед тем, как приступить к транзисторам и микросхемам.
— Да, возможно. Но я хотел бы избежать метафоры, которая позиционирует Perl 6 как более продвинутый язык по сравнению с Perl 5.
— В то же время, Perl 6 — это второй язык в семействе Perl. Может случиться, что Perl-сообщество разделится на две части. Это возможно?
— Да, мне кажется, что мы это уже видим. Такое деление отражается и на комьюнити. Два языка в одной семье, и комьюнити со слегка разными свойствами и особенностями. Это иногда происходит и в November, началось с пары постов в блогах, потом мы с mst разговаривали в IRC. Это также заставило нас задуматься о том, как мы преподносим Perl 6. Не как следующую версию Perl 5. В некоторых случаях это правда, но такое утврждене не слишком верно, потому что это будет означать, что Perl 5 устарел, а это не так: Perl 5 будет жить еще долго.
— Что вы думаете о том, что Perl 5 перенимает некоторые элементы Perl 6, например, say?
— Я очень доволен, что это происходит. Это сближает языки друг с другом, и, кроме того, это вообще хорошая тенденция, что Perl 5 в каком-то смысле наследует фичи из Perl 6.
— Из будущего?
— Не из будущего, оба языка — сегодняшняя реальность. По сути, единственное существенное различие между Perl 5 и Perl 6 — в том, что Perl 6 — моложе и меньше. Он даже не то чтобы более футуристический, он просто делает акцент на других вещах. Мы не говорим об обратном портировании чего-то из Perl 6 в Perl 5, скорее, мы говорим о горизонтальном портировании, о переносе возможностей из одного форка в другой.
— Большое преимущество Perl 6 в том, что он полностью определен спецификацией. Но эта спецификация изменяется каждый день, поэтому невозможно закончить ее читать, не опасаясь того, что к моменту прочтения она окажется сильно измененной.
— Изменения происходят где-то раз в один-два дня. Должен сказать, что большинство изменений довольно незначительны: опечатки, грамматические ошибки, восполнение пробелов, которые нужно заполнить. Иногда, наверное раз в месяц, действительно случаются изменения в семантике, но даже они весьма малы сегодня. Мне кажется, причины изменений продиктованы в основном сегодняшней реализацией. Это очень хороший знак, в том смысле, что у нас не будет спецификации, в которой описано либо что-то невозможное, либо противоречивое, либо слишком сложное в реализации. Мы хотим оставаться практичными. Реализация в той или иной степени говорит спецификации, какой она должна быть. Здесь можно спорить, считать ли это изменениями или просто стремлением приблизиться к реальности.
— Но для новичка не существует простого и быстрого способа знакомства с языком.
— Да, и это проблема! Вот почему мы сейчас в фазе раннего тестирования, потому что нет легкого способа войти в Perl 6: нужно пожертвовать временем и приложить усилия, чтобы познакомиться.
— Есть ли способы это исправить?
— Создание документации, написание книг, руководств — всего того, в чем нуждаются новички, и разместить все это на какой-то центральной странице.
— Кстати, а что вы думаете о сегодняшней ситуации с публикацией книг? Каждая книга, будучи изданной, тут же устаревает. Существует много книг, многие из них весьма устарели и предлагают старые способы использования языка.
— Это особенно верно для Perl 6. Издано несколько книг, и в них описан синтаксис, который сегодня не компилируется. Perl 6 изменился.
— Написать книгу сложно.
— И рисковано.
— И это не даст какой-то ощутимой прибыли. Не думаете ли вы, что сегодня писать бумажные книги, в частности, о Perl 6, бесполезно?
— Я думаю, написание книги — по крайней мере своего рода психологическая победа. Мы прямо сейчас пишем книгу о Perl 6, приуроченную к выходу Rakudo *. Нам пришлось думать о том, как представить Perl 6 новичкам, как структурировать руководство размером с книгу, чтобы объяснить все аспекты Perl 6. Мне кажется, это упражнение важно само по себе. По крайней мере, из Advent-календаря в прошлом году мы видели, что создание руководств и демонстрация простых примеров — очень хороший способ привлечь внимание, способ заставить нужных людей заметить Perl 6, потому что мы описываем там все в очень сжатом виде. Это одна из целей книги.
18 мая 2010, Москва.
Беседовал и перевел Андрей Шитов.
interview, masak, perl6, yapsi, pugs, rakudo — 20 мая 2010
