[comp.prog] Свежее интервью Matz-а в InfoQ

Мне, как бывшему Ruby-исту, было интересно прочитать свежее интервью Якихиро Мацумото (Matz), создателя языка Ruby, в журнале InfoQ.

Если его коротко пересказать, то получается следующее:

• в последнее время Matz активно работал над веткой 1.9 языка Ruby, которая гораздо быстрее, чем 1.8. Так же в Ruby пытаются сделать поддержку нескольких виртуальных машин Ruby в рамках одного процесса;
• когда Matz начинал разработку Ruby, он имел представление о функциональном программировании в рамках возможностей языка Lisp. И лишь затем познакомился с более продвинутыми средствами, которые доступны в Haskell и OCaml, хотя понимание некоторых из них дается ему с трудом;
• если бы Matz разрабатывал Ruby с нуля сейчас, он бы попробовал добавить в Ruby что-нибудь из функциональных языков. Например, какую-то форму ленивых вычислений. Но вот добавление этих возможностей в уже существующий язык представляется очень тяжелым делом – слишком многое придется менять в дизайне языка;
• по мнению Matz попытки “подружить” функциональный и объектно-ориентированный подходы в одном языке (вроде того, что делают в Scala) – это очень трудное дело, в котором обязательно чем-то придется жертвовать;
• Matz знаком с Haskell, написал несколько маленьких программок и его впечатление о типах и о самом Haskell-е неоднозначное. По поводу типов – с одной стороны, они помогают вылавливать ошибки на ранних стадиях, но с другой – это лишняя головная боль для разработчика, поскольку о них постоянно нужно думать. И даже автоматический вывод типов и компактность языка здесь не сильно помогают, т.к. типы все равно никуда не исчезают и о них нужно думать. Так же в Haskell-е программисту хорошо тем, что он описывает, что он хочет сделать, а не как это делать. Но при этом сам Matz не всегда понимает, как же именно будет работать программа. В языке Ruby с этим проще – его вычислительная модель тривиальнее;
• язык Clojure и использование STM кажется Matz-у интересным. Хотя он и не считает, что Clojure является чем-то новым. Скорее хорошо упакованным набором давно известных вещей. А вот внедрение STM в Ruby выглядит маловероятным, поскольку язык изначально не был предназначен для этого;
• Matz считает, что Ruby похож на SmallTalk, но является более легковесным. На Ruby проще писать маленькие программки, которые не тянут с собой большие image-файлы. Поэтому Ruby является более практичным языком;
• Matz радует наличие портов Ruby для других платформ – JRuby и Iron Ruby. За Iron Ruby он не следит, а вот JRuby ему кажется очень интересным. А то, что программы, написанные специально для JRuby не будут работать на Ruby MRI он не считает проблемой – да, есть такая особенность. Это в точности тоже самое, что и Ruby-программы, заточенные только под Unix или только под Windows;
• что касается дизайна языка, то если нужно было делать выбор между удобством языка и скоростью, Matz делал выбор в пользу удобства. Поэтому Ruby MRI не быстр. Но ребята из команды проекта Rubinius напряженно работают, чтобы создать быструю реализацию. Так же Matz сильно озабочен тем, чтобы язык не оказался переусложненным. Чтобы не оказалось как в C++, куда была добавлена относительно не сложная штука – шаблоны, но из-за которой сложность языка C++ слишком увеличилась;
• сильно Matz уважает разработчиков языка Python. По его мнению в Python сложился и очень хорошие библиотеки, и хороший дизайн самого языка. И вообще, сейчас выбор динамического языка – это вопрос вкуса. Кому-то нравиться Python, кому-то Ruby. Это точно так же, как кто-то любит собак, а кто-то – кошек.

Еще Matz высказался в том плане, что сейчас доминирующей парадигмой является ООП, которая появилась очень давно – в 50-60 годах. И что в ближайшие несколько десятилетий мы вряд ли увидим какую-то другую настолько же мощную парадигму за исключением функционального программирования (которое само по себе так же далеко не ново).

Много Matz говорил о поддержке конкурентного программирования. С упором на модель актеров. По его мнению, лучший подход к этой проблеме – это сосредоточение всех модификаций состояния внутри агентов и взаимодействие агентов между собой посредством сообщений. И что эта штука в языке будет перспективнее, чем STM. Хотя он не знает, будут ли актеры частью языка или же просто Ruby-овой библиотекой (коих для Ruby существует уже пара-тройка штук).

eao197: ёптыть, очень приятно осознавать, что коллектив, в котором мне повезло работать в конце 90-х, додумался до этого уже тогда. И что мы уже давно именно так программы и разрабатываем, только называем актеров агентами. Данная ремарка является откровенной рекламой SObjectizer-а ;)

Disclaimer: я рассказал то, что воспринял из интервью Matz-а. Далеко не все я пересказал. И я далеко не уверен, что все рассказал правильно. Так что переадресую всех интересующихся к первоисточнику ;)