Во время осенней конференции Ruby Russia я, на правах организатора, поймал в кулуарах автора Ruby и устроил ему часовой допрос интервью. Вопросы старался выбирать незаезженные, чтобы ответы были нам полезны, а не “за все хорошее против всего плохого”. И дедушка таки смог меня, старого плюсового разработчика, удивить! Под катом — расшифровка интервью, нетривиальное мнение Юкихиро Мацумото про типы вообще и руби в частности, а также возможность все это обсудить в комментах. На связи я с руби-командой Evrone наперевес. Мацумото мы приглашаем в Москву регулярно, есть возможность заранее придумать интересные вопросы для будущих интервью.

Как основатель языка вы получаете много предложений и идей. О чем вас спрашивают чаще всего?

Очень часто спрашивают – «Я использую язык X. Почему бы вам не добавить функцию из X в Ruby?». В большинстве случаев я отвечаю, что это невозможно. У нас разный языковой дизайн и разная языковая политика. Мы не можем просто взять некоторые функции из X и добавить в Ruby. Но иногда мы все же заимствуем хорошие идеи из других языков, таких как Python, JS или Elixir.

Сейчас в динамические языки добавляют возможность явно указывать типы. Это уже появилось в Python, PHP и JavaScript (TypeScript). Что вы думаете по этому поводу, как будет развиваться работа с типами в третьей версии Ruby?

Rust и Go – статически типизированные языки. В больших проектах сотни разработчиков создают и поддерживают очень много кода, миллионы строк. В таких случаях проверка типа (type checking) удобна, она позволяет обнаруживать ошибки. В других случаях мы должны написать тест, чтобы убедиться в корректности используемых типов. Объемы тестов увеличиваются с ростом проекта. В этом я вижу причину популярности статической типизации, так как ее использование позволяет сократить количество тестов.

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

Отдельный файл информации о типах, который мы называем «файлом сигнатур ruby», будет содержать информацию о типах, используемых в библиотеках, гемах и вашем коде библиотек. Также мы предоставим новый инструмент, «профилировщик типов», который будет собирать информацию о типах. Он может обнаружить противоречие или конфликт типов на основании самого кода или аннотаций типов.

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

В будущих версиях Ruby появится возможность статической проверки типов, до некоторой степени. Все-таки Ruby– это динамический язык, и основные проверки типов в нем принято делать во время выполнения нашего кода. Проверка типов «первого уровня» использует информацию о типах в коде и помогает разработчику обнаружить от 40 до 80 процентов ошибок. Проверка типов «второго уровня» генерирует информацию о типах на основании самого кода. В будущем, с помощью таких инструментов мы сможем обеспечить статическую проверку типов в Ruby без необходимости для разработчика явно указывать их…

Мне нравится эта идея и я с нетерпением жду будущих версий Ruby, чтобы посмотреть насколько хорош будет такой подход. Здорово, что вы проводите эксперименты с языком. Какое будущее вы видите для Ruby, в каком направлении развиваете язык?

На самом деле, я не управляю языком или сообществом. Я просто предоставляю технологии, а сообщество самое решает, в какую сторону идти. У нас достаточно технологий почти для всех областей, чтобы сделать Ruby гибким и продуктивным. Например, Ruby в основном используется для создания веб-приложений. Но я хочу, чтобы Ruby применялся и в других областях: исследованиях и вычислениях, искусственном интеллекте, машинном обучении, в сфере инноваций. Мы стараемся сделать технологию пригодной для более широкого применения.

Нам, разработчикам, нравится называть вещи разными именами. “Это спортивная машина”, а это “семейная машина”. JavaScript – это язык для веб разработки C – системный язык низкого уровня. Как вам нравится называть Ruby, позиционировать его?

Я бы назвал Ruby “продуктивным языком программирования”. Продуктивность – одна из главных целей, основных задач Ruby. Он разрабатывался для людей, а не машин. Иногда разработчики жалуются на дизайн языка, когда что-то из синтаксиса сложно реализовать эффективно. Дизайн Ruby ориентирован не на производительность, а на продуктивность. Это освобождает разработчиков для решения более сложных задач, связанных с самим проектом. Мы стараемся сделать Ruby максимально продуктивным, и настолько производительным, насколько это возможно.

В Python нет многострочных анонимных функций из-за сложности разработки. Приятно слышать, что для Ruby вы и core разработчики стараетесь облегчить жизнь программистам, несмотря на сложность реализации. Кстати, если мы начали говорить о сложности. Представьте себе, у вас есть возможность отправиться в прошлое и дать один совет себе молодому, когда вы только начали разрабатывать Ruby. Какой это был бы совет?

Не заимствуй слишком много у других скриптовых языков. Твой язык программирования будет лучшим языком общего назначения. Большой фокус на скриптовости станет своего рода рудиментом в будущем.

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

Если нужно выбрать что-то одно, то это блоки. Блоки в Ruby уникальны, это полезная абстракция функции высшего порядка. Они намного проще, чем в других языках. Это дает как ограничения, так и удобства использования.

Совпадение, но блоки – это то, что мне больше всего нравится в Ruby. В своих собственных выступлениях и интервью я говорю о Ruby как о языке с DSL, синтаксическим сахаром и блоками. Блоки – это очень круто.

В других языках, например в Swift, если последним аргументом функции указана другая функция, то эта функция-аргумент может вести себя как блок в Ruby. Предложение о подобном синтаксическом сахаре есть даже для JavaScript. Я очень горжусь этим.

Да, в JavaScript с его синтаксисом «толстой стрелки» часто используют последний аргумент функции как “что-то вроде блоков в Ruby”. Не могу не задать обратный вопрос. Что вы можете назвать самой большой ошибкой проекта, которая должна быть исправлена или уже исправлена?

Есть немного. Начнем с глобальных переменных. Они были полезны для скриптового языка, но теперь выглядят как рудимент. Я также сожалею, что добавил потоки в явном виде – нам нужна более удобная абстракция для concurrency. Еще одна моя ошибка в дизайне – отсутствие иммутабельности у некоторых объектов. Например, сейчас можно поменять time zone для объекта времени. Вместо того, чтобы просто создать новый иммутабельный объект. Это то, о чем я сожалею.

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

Я full time разработчик Ruby. Половину своего рабочего времени я работаю над дизайном следующей версии языка. Остальное время работаю над альтернативной реализацией MRuby. Мейнстрим реализация создается core разработчиками, а я только принимаю решения, которые они отражают в коде.

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

К счастью, все рабочее время я провожу с open source. У меня нет давления со стороны клиентов, у меня нет боссов, я сам ставлю себе задачи. Все это позволяет мне работать без стресса. У меня нет дедлайнов кроме даты следующего релиза Ruby. Эта свобода позволяет мне чувствовать себя расслабленным.Также я стараюсь проводить время не за компьютером, уделяю внимание своим близким, семье, помогаю местной церкви, гуляю собакой и играю со своей кошкой.

Многим российским Ruby разработчикам нравится Япония как страна, ее культура. Они смотрят аниме, читаю мангу, приезжают в Японию как туристы. Как коренной японец и разработчик программного обеспечения, какие места и активности вы можете порекомендовать коллегам-разработчикам, посещающим Японию?

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

Есть ли что-нибудь в японской культуре и языке, что повлияло на создание Ruby?

У нас нет контроля над таким культурным влиянием и его трудно оценить. Например, в японском языке предложения склеиваются друг с другом. Точно так же, как работает “method chaining” в Ruby. Может быть, это и есть влияние японского языка. Япония – богатая страна и у нас нет необходимости в постоянной тяжелой работе. Open source не приносит денег, но работая на основной работе или полагаясь на деньги спонсоров я и контрибьюторы можем поддерживать и развивать язык и делать лучшую технологию. Это тоже влияние Японии и возможности, которые она дает.

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

Создание языка программирования – это не очень сложная техническая задача. Многие студенты, посещающие курсы разработки языков программирования в университете, могут сделать свой язык и в этом нет ничего запредельно сложного. Сложность заключается в том, что язык – это способ выражения мыслей. Это относится как к языкам программирования, так и к естественным языкам: русскому, английскому, японскому. Языки программирования, такие как Ruby, Python или JavaScript – они помогают нашему разуму формулировать мысли. Это главная задача языков программирования. Хороший язык программирования предлагает подход к формулированию мыслей. Для Ruby такой подход – это “продуктивность разработки и удовольствие от написания кода”. Для других языков это может быть “простота”, “эффективность” или что-то еще. У каждого языка свой подход. И если вам нравится то, что предлагает Ruby для формулирования мыслей, то это ваш язык.