Pragmatic Perl

Выпуск 16. Июнь 2014

Интервью с Флорианом Рагвицом (Florian Ragwitz)

Флориан Рагвиц (rafl) — немецкий Perl-программист, автор и соавтор многих модулей на CPAN, разработчик ядра Perl.

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

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

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

Однако, у меня есть воспоминания о неком “детском обучающем компьютере”. Он выглядел как лаптоп, но был всего лишь детской игрушкой. У него был монохромный экран 4x20 символов, и в нем было пара обучающих программ в духе словарных или математических головоломок. Я долго искал в интернете и скорее всего это был “V-Tech Genius Leader 4004 Quadro L” (http://www.pinterest.com/pin/146930006562843060/) и очевидно он продавался только в Германии. В дополнение к разным развивающим играм в нем был интерпретатор BASIC и краткое руководство к этому языку. У меня нет никаких воспоминаний о том, что я программировал на этом устройстве, но я помню, что был очарован BASIC и проводил за ним много времени.

Не совсем приятные воспоминания у меня остались от i486, который моя семья использовала в своем деле некоторое время. Мне нравилось играть в игры, знакомиться с Windows 3.1, DOS и набором разных файловых команд, но мне несколько раз сильно попало, когда я ломал систему и моя семья вынуждена была звонить в сервисный центр, чтобы продолжить свою работу.

Другие воспоминания о программировании у меня со времен средней школы. Мы все использовали графические калькуляторы Casio модели CFX-9850G (http://en.wikipedia.org/wiki/Casio_9850_series). Его можно было программировать с помощью диалекта BASIC, это было лучшим развлечением во время скучных уроков. Помню я написал несколько программ, которые использовал на уроках математики и физики для решения некоторых задач, но в большинстве случаев я писал игры. В то время я гордился тем, что написал графические шахматы для двух игроков. К сожалению оба игрока должны были играть на одном калькуляторе. До сего дня я виню в этом баг в моей модели калькулятора в реализации команд Send() и Receive(), что не позволило написать работоспособную версию для режима мультиплеера. Мои попытки написать искусственного противника также не увенчались успехом.

В школе также я познакомился с такими языками как Logo и Pascal, и пытался выучить Visual C++, Visual Basic и Java, как только у меня появился собственный компьютер. Но ни один из них так и не прижился. По-настоящему программировать на постоянной основе для решения реальных задач я начал после того, как перестал пользоваться Windows. Большинство задач в то время были небольшими и я писал их в шелле. Некоторые посложнее писались на awk, PHP и Perl.

Какой редактор используешь?

Оба!

Очень давно, где-то в 2002 году, я перешел с Windows на Linux как основную операционную систему. Частью этого перехода было мое знакомство с Vim. Через некоторое время, после того как я научился правильно выходить из редактора, у меня получилось прочитать документацию. Мне очень понравились его модальный режим и выразительность.

Vim отличный редактор и даже сегодня я регулярно его использую. Хотя, моим главным редактором стал Emacs.

Я хотел перейти с Vim на Emacs довольно продолжительное время. Меня привлекали некоторые его особенности и расширения. Много времени я провел в org-mode (http://orgmode.org) и вероятно не захотел бы переходить на другой редактор, который бы не предоставлял подобного функционала. Возможность использовать разный шрифт в одном буфере очень сильно помогает при редактировании структурированного текста, как, например, LaTeX-документов или Perl POD — отображение =head1 заголовков большим размером, чем =head2, делает текст для меня более понятным.

В дополнение к этому, у меня есть привычка проводить слишком много времени за тонкой настройкой утилит, которые я часто использую, включая текстовые редакторы. Мне больше нравится писать на Emacs Lisp, чем на Vim Script.

Переход с Vim на Emacs не был простым и потребовал нескольких попыток. Однако все получилось просто, когда я перестал использовать Vim для редактирования Emacs-конфигурации и заставил себя использовать Emacs для всего, включая алиас alias vi=emacs в конфиге моего шелла.

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

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

Я смутно вспоминаю как заинтересовался Perl. Еще будучи в школе, где-то в 2003 году, я много времени проводил за веб-программированием на PHP. Возможно, я наткнулся на Perl читаю книгу по UNIX, или во время поиска альтернативы PHP, который мне не сильно нравился в то время.

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

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

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

С большинством.

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

Доступ к разным идеям выраженным на разных языках программирования часто заставляет менять мое мнение об этих идеях. У таких языков как C и Pascal с их статической типизацией есть много практических проблем, но это не делает статическую типизацию плохой идеей. Потоки не плохие, потому что в Perl они плохо реализованы. Парадигмы функционального программирования могут решать многие задачи естественным способом, но также есть и множеств задач, которые более элегантно решаются с помощью объектно-ориентированного подхода.

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

Поэтому я стараюсь учить множество языков, когда мне предоставляется возможность. Среди наиболее интересных для меня в последнее время стали Haskell, F#, OCaml, Go и Scala.

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

Исторически у Perl в свое время было много преимуществ над другими языками: его “manipulexity” и “whipuptitude”, поддержка разных парадигм, его переносимость, отличная поддержка текстовой обработки, его культура тестирования и т.д. С тех пор, однако, многие другие языки его догнали.

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

В Perl все еще остается возможность, по моему мнению, удивительной гибкости. Многие вещи, обычно невозможные в других языках, вполне себе реализуемы в Perl, несмотря на то, что иногда приходится постараться. Perl мне бы нравился намного меньше, если бы было невозможно написать такие модули как List::Gather, или Scope::Escape::Sugar. С другой стороны, подобные модули добавляют функционал уже имеющийся в том или ином виде в других языках. Не знаю, хорошо это или плохо.

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

Мне не приходит на ум одна единственная особенность, которую бы хотелось иметь в языке будущего, но я надеюсь, что эти языки позаимствуют возможности таких языков, как Lisp, Haskell и Scala. Мне кажется, что есть множество интересных идей в этих языках, которые еще не попали в массы.

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

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

Ты пишешь CPAN-модули потому что нет такого функционала, или как доказательство, что такое можно реализовать на Perl?

Большинство написанных мною модулей или правок, внесенных в модули других людей, были мотивированы реальными задачами. Почти все время, которое я тратил на правку существующих модулей, было попытками чинить баги, на которые я наталкивался, или же сделать их более общими для решения определенных задач. И очень редко, как, например, в случае List::Gather, мне приходится писать новые модули, потому что существующие не удовлетворяют моим требованиям.

Большинство моих новых модулей реализуют функционал, которого вообще не было на CPAN. Многие из них это просто биндинги к существующим C-библиотекам, которые я хотел использовать.

Единственным модулем, который я написал как доказательство, что такое можно сделать в Perl, был мой эксперимент с signatures.pm.

Как получилось так, что ты начал выпускать perl-дистрибутивы?

Я не помню как конкретно это произошло, но свой первый Perl-релиз я выпустил в 2010 году, когда Jesse Vincent был в роли пампкина (pumpkin). В IRC он то ли попросил меня сделать релиз, то ли я сам напросился в добровольцы. В то время процедура релиза, которую заложил Jesse, была довольно хорошая и выпуск новой версии perl оказался на удивление простым.

Моими любимыми релизами остаются 5.15.4, который я выпустил сидя на диване Ларри Уолла, 5.17.5, который я выпустил во время доклада на YAPC::Brasil, и 5.14.2, единственную выпущенную мною версию не для разработчиков.

Как можно начать вносить свой вклад в развития ядра perl?

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

Оказывается мой первый комит в ядро был в 2008 году. Тогда умное сравнение given/when было новым и интересным для меня, и, очевидно, B::Deparse, с которым я много работал, не очень хорошо поддерживал эту новую структуру. Мне это сильно досаждало и я поправил это. Это было очень просто — изменение всего лишь одной строчки кода в модуле B::Deparse.

Многие из моих ранних комитов следовали похожему шаблону. В какой-то момент я обнаружил, что нельзя просто совмещать флаги -E- и -p/-n в однострочниках perl -n'} END { ...'. Небольшой трехстрочный патч и все заработало. Где бы я ни находил опечатку или неточность в документации, я всегда отправлял патч. Это приносило внутреннее удовлетворение.

В общем, нет ничего магического в ядре perl (хотя, возможно, исключением является sv_magicext() и подобные функции). Большая часть ядра написана на самом Perl — обычном Perl с которым вы сталкиваетесь каждый день. Нет причин его бояться. Мне кажется, что каждый Perl-программист сможет поучаствовать в развитии своего языка программирования тем или иным образом, если захочет этого.

Достаточно ли у perl волонтеров для развития кодовой базы? В чем он сейчас нуждается?

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

Мне неизвестно в чем в данный момент нуждается Perl. Если кто-то хочет поучаствовать, стоит посмотреть на документацию perlhack и Porting/todo.pod в дистрибутиве, там находится множество отправных точек. Уверен, что сообщество разработчиков perl5 с удовольствием пообщается с вами о том, как можно помочь, если связаться с ними через список рассылки, IRC-канал #p5p или любым другим способом.

Лично я надеюсь увидеть альтернативные реализации Perl, которые можно запускать на различных окружениях, как, например, JVM, CLI или даже LLVM. Такие проекты как Compiler::Lexer, Compiler::Parser и gperl двигаются в правильном направлении, но, как по мне, есть еще куда расти.

Что делаешь для Debian?

Уже не очень многое. В свое время я поддерживал относительно большое количество пакетов. Большинство из них были Perl-ориентированными, но я также собирал и несколько не Perl вещей, как, например, музыкальный плеер XMMS2 и несколько клиентов к нему. Сейчас большинство моих пакетов уже нашли новых сопровождающих, которые отлично справляются с поддержанием их в обновленном и рабочем состоянии.

Где сейчас работаешь? Сколько времени проводишь за написанием Perl-кода?

Я работаю в небольшой консалтинговой IT-компании Infinity Interactive (http://iinteractive.com). Там я работаю со всем, что подходит для решения проблем наших партнеров. Иногда это Perl, иногда это что-то другое. Мне нравится техническое разнообразие в моей работе.

Последнее время я в основном работаю над задачами системной автоматизации. Приложения, написанные на Perl, занимают примерно 10% или 20% моего рабочего времени.

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

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

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

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

Как ты понимаешь, что твой доклад слишком сложен для среднего разработчика?

К несчастью, я обычно этого не замечаю.

Откуда пошло Acme::rafl::Everywhere?

Это случилось во время YAPC::NA 2012 в Мэдисоне, Висконсине. В первый же день я присоединился к группе перловиков, организованной Дейвом Рольски для проведения (анти-) ужина по поводу приезда. Среди нас были Роберт Блэквелл и Sawyer X.

Я не сильно помню как разговор перешел на меня, но в какой-то момент Роберт заметил, что я принимаю участие во многих сообществах и/или проектах. Подозреваю, что он ссылался на большое количество разнообразных модулей на CPAN, который я поддерживал в то время, а также на то, что я участвовал во многих не Perl-проектах как Git, Linux, XMMS2 и Arduino и, возможно, также на тот факт, что я был на всех пяти YAPC и на многих международных Perl-воркшопах в том году.

В какой-то момент кто-то произнес “you are everywhere!” (“да ты везде!” — пер. с англ.) и Sawyer’а понесло. Большинство шуток из Acme::rafl::Everywhere были придуманы на том ужине. Позже, когда Sawyer после конференции выложил модуль, несколько других людей отправили pull-запросы на добавление других дополнительных фактов.

Есть даже команда “!rafl” на DuckDuckGo.com.

У меня двойственное отношение ко всему этому.

Часто выходишь на улицу?

Если небольшой загар на моем лбу и шее может быть индикатором — то слишком часто.

Есть множество интересных вещей, которые происходят в Бруклине и вообще в Нью-Йорке, и, к сожалению, большинство из них не происходят у меня дома. Чтобы посмотреть на все это, мне приходится заставлять себя выходить из дому. Эта та жертва, которую я готов принести. Также выбор пива на моей домашней полке сильно ограничен, поэтому часто приходится работать из разных баров и пивных на открытом воздухе на районе.

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