Pragmatic Perl

Выпуск 7. Сентябрь 2013

Интервью со Stevan Little

Stevan Little — автор ООП-фреймворков Moose и mop, альтернативного perl5 интерпретатора на Scala — Moe, и многих других Perl-модулей.

Когда начал программировать?

Первый раз я программировал на BASIC в 1984, когда моя семья купила Apple ||. В основном я программировал простую графику и безуспешно пытался программировать квесты, я потерял интерес где-то через год. Я больше не программировал до 1997 года, когда узнал про HTML и Javascript и получил работу с первыми веб-страницами.

Первоначально я просто копировал и хачил простые Javascript-виджеты, но в конце концов купил большую книгу O’Reilly Javascript и научил себя программировать. После этого я провел несколько лет, читая книги по программированию, и выучил несколько других языков, включая такие вещи, как Ada 95, Erlang, LISP, Standard ML, Java и Python. И только в 2002 году я был нанят на текущую работу в Infinity Interactive, и я выучил Perl.

Каким текстовым редактором пользуешься?

Мне всегда больше нравились графические редакторы, до недавнего времени я был пользователем TextMate, но полгода назад я перешел на SublimeText 2. Мне он больше нравится, потому что у него есть несколько экономящих время особенностей, которыми обладают большие IDE, но он не навязывает тебе свой порядок работы или что-то в этом роде.

Когда и как познакомился с Perl?

Как я уже сказал, выучил Perl, когда меня в 2002 наняли на текущую работу. В то время я все еще в основном занимался HTML/CSS и Javascript по работе и много упражнялся с Python в свободное время. По-началу я не был очень рад тому, что придется учить Perl, пока я не нашел книгу Damian Conway «Object Oriented Perl» и не увидел, что на самом деле может Perl. В силу того, что я изучал большое количество языков программирования, было довольно просто выучить Perl, но несколько лет потребовалось, чтобы понять, что значит писать действительно «перловый» код.

С какими другими языками приятно работать?

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

Совсем недавно мне понравилось работать со Scala, который я использую в паре экспериментальных проектов. Я нахожу его в некоторой степени очень похожим на Perl в философии TIMTOWTDI (есть больше одного способа сделать это – прим. перев.). Однако у него очень глубокие академические и функциональные корни, которые позволяют сторониться от более практичной философии Perl «главное, чтобы работало». Но это все еще очень молодой язык, и очень интересно наблюдать, в какую сторону будет двигаться сообщество.

На работе у нас большое количество проектов на C#, и мне всегда очень нравилось работать с этим языком. В каком-то смысле это «Java, сделанная правильно» в том смысле, что дизайнеры языка очевидно многое почерпнули из Java и знали как не надо делать. Также хочу отметить, что уделять внимание основным библиотекам, как, например, в C#, очень полезно, многие open source языки не думают об этом, что усложняет добавление их в будущем.

Также я недавно игрался с TypeScript, попыткой Microsoft сделать Javascript более подходящим для больших задач. Мне понравился этот язык, жду, когда выйдет версия 1.0.

Какое, по-твоему, самое большое преимущество Perl?

По-моему, самое большое преимущество, как и самый большой недостаток, это философия TIMTOWTDI.

Из всех языков, которые я изучал и с которыми работал, ни один из них не дотягивает до гибкости Perl. В качестве хорошего примера можно привести новое API ключевых слов, что позволяет прервать парсер интерпретатора при исполнении и изменить синтаксис языка, мне неизвестно ничего из похожего в других языках. И это не просто новая вещь в Perl, у нас всегда был доступ к op-tree через модуль B, с помощью которого можно сделать много страшных вещей. Такой уровень доступа к runtime языка позволяет делать много интересных и полезных вещей в Perl. Вместе с этой гибкостью, Perl также надежно ограничивает такие функции, что позволяет их безопасно использовать даже в продакшн-системах.

Но в тоже время такая гибкость и ограниченность также проблема Perl.

Perl из-за TIMTOWTDI это язык со многими диалектами; хорошими, плохими и совсем ужасными. Я убежден, что именно поэтому у Perl репутация неподдерживаемого языка. У любого проекта с большим количеством кода на любом языке будет свой внутренний диалект, созданный в течение длительного времени его автором(-ами), и если повезет, это может помочь новому программисту в чтении и понимании кода (когда он выучит диалект, конечно). Для более строгих языков типа Python или Java вариации диалектов, сосуществующих в одном коде, довольно мало. Но такой гибкий язык как Perl, с его исключительно искушенным парсером, способен поддерживать большое количество диалектов одновременно. Это сильно усложняет жизнь новому программисту для обучения, поддержки и безопасного расширения кода.

Какими, по-твоему, особенностями должны обладать языки будущего?

Мне кажется, что хорошая модель распараллеливания будет самой важной частью любого языка будущего. Я лично предпочитаю модель акторов с полным разделением, потому что я нахожу ее наиболее практичной и самой простой. Она тестируется в бою языком Erlang в течение уже 20 лет и в последнее время перенимается Java- и Scala-сообществами с большим успехом. Я не говорю, что модель акторов это лучшая модель, но она наиболее интересная в данный момент.

Также мне кажется, что гибкий и надежный вывод типов тоже будет ключевым свойством. В прошлом вывод типов можно было найти только в таких функциональных языках, как Standard ML, OCaml и Haskell со строгой типизацией, но недавно его начали применять и в динамических языках. Примером может служить компилятор TypeScript, который, получив на входе обыкновенный Javascript (так как TypeScript это расширение Javascript), проверит все типы, даже без их указания. Это заставляет программиста быть более строгим при использовании переменных — если переменной присвоено целое число, нельзя затем присвоить строку — TypeScript также предоставляет обходной путь в виде типа “Any”, который позволяет программисту нарушать это правило. Такая комбинация гибкости и жесткости, как мне кажется, будет хорошим свойством любого языка будущего.

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

Почему написал Moose? Почему он стал таким популярным?

Я написал Moose после того как поработал с объектной системой Perl 6 в рамках моей работы над проектом Pugs. После длительной работы с хорошей объектной системой Perl 6 возвращение к базовой ОО в Perl 5 очень сильно показало, какой муторной и скучной она может быть. Я уже прототипировал объектную систему Perl 6 четыре или пять раз для Pugs, поэтому я просто перенаправил свои усилия, чтобы сделать что-нибудь работающее и для Perl 5. Были две или три неудачные попытки, прежде чем я написал Class::MOP и затем на его основе написал Moose.

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

Что думаешь об альтернативных или, так называемых «легких», реализациях Moose?

У меня нет с этим никаких проблем, они заполняют нишу, которую Moose никогда не заполнит. В течение последних нескольких лет было много таких реализаций, хороших и плохих, сейчас я думаю, что наилучшим является Moo, потому что он позволяет прозрачно «проапгрейдиться» до Moose, если потребуется.

Что за проекты mop и mop-redux?

Проект p5-mop был первой попыткой написать объектную систему, похожей на Moose, которая бы могла войти в ядро Perl. В конечном счете он был раздавлен весом собственной сложности и несколькими хитрыми багами, которые невозможно было обойти. Должен признаться, что этот факт привел меня в уныние, и в течение некоторого времени я начал негативно относиться к ядру Perl. Это, в свою очередь, привело меня к проекту Moe — попытке написать Perl 5-подобный язык, используя Scala. Moe превратилось в эксперимент с концепциями языка, которые я бы хотел видеть в Perl 5, но которые сложно прототипировать с помощью самого Perl 5.

В самолете домой после YACP::NA в этом году я решил дать p5-mop второй шанс, на этот раз воспользовавшись опытом, который я приобрел при разработке Moe. Это привело к проекту p5-mop-redux, над которым я сейчас работаю. У меня большие надежды на него, и я буду им заниматься несколько следующих месяцев и буду пробовать проталкивать в ядро Perl.

Может ли использование ООП-фреймворка без понимания привести к плохим практикам программирования? Возможно ли писать «чистый код» без ООП-фреймворка в Perl?

Мне кажется, что плохое понимание своих инструментов часто приводит к плохому их использованию, не думаю, что ООП-фреймворк чем-то в этом случае отличается. Вполне возможно написать чистый код без ООП-фреймворка, код Plack может служить отличным примером этому.

Не разделен ли, по-твоему, сейчас CPAN на два лагеря: те, кто используют Mo*, и другие?

Нет, мне кажется, что разделение больше между «Зависимости — это хорошо» и «Зависимости — это зло». Пользователи Mo* больше попадают в лагерь «зависимости это хорошая вещь», остальные в «зависимости это плохо», и я не думаю, что Mo* является здесь разделительной чертой. Надеюсь, что Moo, имея небольшое количество зависимостей, поможет построить мост между этими двумя лагерями.

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

Где сейчас работаешь? Сколько времени уделяешь программированию?

Я работаю в небольшой консультационной фирме Infinity Interactive, у нас 24 постоянных сотрудника и несколько постоянных фрилансеров. Мы предоставляем разные сервисы, такие как Perl-программирование, высококачественная HTML/CSS-верстка, сложные пользовательские интерфейсы на Javascript, .Net- и Java-программирование, консультирование в сфере системного администрирования и многое другое. На данный момент в основном я занимаюсь управлением и дизайном архитектуры проектов больше, чем программированием для клиентов, но не все так плохо, ведь у меня больше времени заниматься open source проектами, в том числе и p5-mop.

Стоит ли советовать молодым программистам изучать Perl?

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

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