Дэйв: Мы часто слышим, как говорят: «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. У них обоих огромный потенциал, который, правда, не принес популярности или доли на рынке. Была бы хорошая возможность внести свою лепту.
Грег: Какие некомпьютерные книги вы порекомендовали бы прочитать программистам?
Программирование — по сути созидательная работа, так что критически важно подкармливать креативность из внешних дисциплин. Меня самого всегда интересовали новые модели и метафоры вычислений и лучшие идеи интерфейсов, так что я по максимуму стараюсь читать что-либо научное (особенно, по физике и математике) и литературу о дизайне вообще. Но это я, а большинство такое чтение не вдохновило бы.
Так что общий ответ, я думаю, в том, что нужно искать книги, которые расширяют сознание непредсказуемым образом, которые выносят за привычные способы размышления и видения мира, ставят под сомнение собственные предположения и уверенность. Лучшие образцы: «Дизайн привычных вещей» Дональна Нормана, «Фрикономика» Стивена Дабнера и Стивена Левитта, «Ружья, микробы и сталь» Джареда Даймонда, «Государь» Макиавелли, «Поймай меня, если сможешь» Франка Эбигейла, «Затерянные в космосе» Уокера Перси или просто что-нибудь, написанное Дугласом Хофштадтером (к сожалению, многие останавливаются на «Геделе, Эшере, Бахе»).
Не скажу, что я согласен с каждой идеей или теорией в этих книгах или даже с большинством из них, но мне кажется, что каждая книга заставляет задуматься о наших уютных ожиданиях и убеждениях. И мне кажется, это очень важно.
Повседневное программирование во многом монотонно. Необходимо преодолеть эту однообразность, если хочется стать лучшим программистом. А умение мыслить за пределами рамок (и даже просто признать их существование!) для такого роста необходимо.
Думаю, в том числе и поэтому многие программисты естественно тяготеют к научной фантастике. Действительно хорошая фантастика переносит за пределы собственных предположений именно в этом направлении.