情報処理2015年12月号特集記事「20年目のRubyの真実」インタビュー

笹田：今日はよろしくお願いします。「Rubyの真実」を久しぶりに読んでいただいたわけですが、一番ささるセンテンスってありました？　「確かに、これはそうだな」、というような。
松本：結局プログラミング言語において、普通の人が注目するのは、客観的な評価ををしやすいところ、といっていること。
笹田：普通の人っていうのは？
松本：プログラミング言語を選ぶ人とか。
笹田：ユーザですか？　開発者？
松本：それは誰でも同じだと思うんだけど、次の仕事にどのプログラミング言語を使おうかとか、あるいは、より良いプログラミング言語の設計について研究しようとしているかもしれないし、自分でデザインして実装しようとしているかもしれないし。で、そういう人たちそれぞれ、言語を評価するわけだよね。使うか使わないかとか、この機能を採用するかしないかとか。そういうときに、最初に評価しがちなのは、機能がどうこうとか、性能がどうこうとか、そういう点で評価しがちなんだけど、本当に大事なことはそこではないと。
笹田：一貫性の話とか。
松本：そうそう。
笹田：「Rubyの真実」にも、いくつか書いてたりしますよね。単純さ、美しさ、簡易さ、性能…。一貫性、簡潔性、柔軟性…。
松本： こっちは大事なほうね。
笹田：「Rubyの真実」的には、一貫性はいらないよねって話じゃない？
松本： ユーザインタフェースの原則の多くはそうだって話なんだけど、この時点では、一貫性はそんなにいらないとは言ってないんだよね。「このような原則を考慮して設計された言語はプログラマにやさしい」。やさしさの理由は、一貫性、簡潔性、柔軟性だと、ここでは言っていた。だけど、一貫性…この時点だと、Principle of least astonishmentに対しても…
笹田：「驚き最小の法則」
松本：そうそう。割とポジティブだったんだよね、12年前は。
笹田：そこは違うと。
松本：そこはちょっと違うんだよね、今は。昔は、「驚き最小の法則」は大事だと思ってたし、一貫性も、いまよりも重要だと思ってた。
笹田： だからここに書いたわけですね。
松本：書いてある。

松本：今となってはね、驚き最小の法則って、特に言語設計の議論をするときは、邪魔にしかならないっていうことが明らかになった。実際に、Rubyという、すでにあるものを使ってみて、それに対して、ネガティブな驚きが少ないというときに使ってたのね、元々は。なんだけど、使う人はバックグラウンドが違うから、自分のバックグラウンドと違うと、どうしてもびっくりするわけだ。
笹田：「代入がある！」とか。
松本：そうそう、場合によってはね。「ローカル変数が書き換えられるとはどういうことだ」とか。
笹田：それは驚きだからよくない。
松本：ね。っていう風に思われるということがあって、そう思う人も当然いるわけで。それに対して「驚き最小の法則」に反するみたいに言われるとすると、それはちょっと違うということになる。特に言語仕様の言語設計の議論において、驚き最小の法則ってのが邪魔になると。
笹田：経験で。
松本：この12年の経験で分かったと。
笹田：なるほど。他の人たちとのディスカッションの中で、これで説得するのがしんどい、というのが分かってきた。
松本：逆に、それで説得しようとする人がいて、しんどい。
笹田：あー、なるほど。
松本：それは、あんたの驚きだけど、僕の驚きではないから、という話になってるくるわけね。共通の議論の土台にならない。「Rubyの真実」を書いていた頃は、Rubyのデザインにかかわろうなんて人はほとんどいなかったので、我々で決めていた。それが自分の感性にあっていて驚きが少ないか、驚きがあっても、新しいことを学んだという、ポジティブな驚きだった。
笹田：ふむふむ。
松本：なんだけど、この後、コミュニティも広がって、もっとRubyを良くしよう、変更しようという議論に参加しようという人が増えてきた。そうすると、そういう議論が始まるわけで、そのときに、「驚き最小の法則」みたいなものを持ち出して来られることが多くて。「驚き最小の法則」があるって言ったのは僕だから（笑）、当然といえば当然なんだけど、逆に、それってめんどくさいっていうか。あなたの驚きのバックグラウンドを、我々は共有していないよっていうことが多くなって。で、言語設計の議論においては、「驚き最小の原則」については、言わないようにしようっていう。
笹田：で、どうするべきか、と。自分にとって、良いか悪いか。
松本：そうそう。それを理由にしてはいけないわけ。で、僕が驚いたからではなくて、これがあると、こう嬉しいから、としないといけない。前提条件が明らかにならないものに「驚き最小の法則」に反するって言われると、それは、あなたにとってはそうだろう、っていう話で終わってしまう。
笹田：ユースケースや利害得失をベースに議論しましょうということになった。
松本：そうそう。
笹田： となると、一貫性はないんだけど、こういうケースだとメリットがある、というような議論に。
松本：あ、一貫性の話は置いておいてね、まだ。「驚くかもしれないけれども、あなたの常識とも反するかもしれないけれども、それは受け入れてください」って、言わなければならないこともある。
笹田：そこで、求めるべき内規っていうのは、ユースケース。
松本：ユースケースだったり。どういう嬉しさがあるかっていうことを表現しないと。「ここはこうあるべきだ、なぜなら、私がこれに驚いたからだ。驚き最小の原則に反するから」っていうロジックがあまりにも多くて。で、それって話にならない。それはあなたにはそうかもしれないけれども、そのあなたの提案した機能を入れたら、ほかの人が驚くかもしれないし。ほかの人の驚きに対して、責任を取らなくちゃいけない身としては（笑）、あなたが驚くっていう理由だけでは入れられないよねっていう話。
笹田：元々、まつもとさんが驚くのを最小にしようっていうニュアンスだった。
松本：そうでもないんだけど。とにかく、驚くかどうかっていうのを、言語に入れるべきかどうかの基準にしてはいけない。だから、これを入れると、良いっていうかどうか、便利であるかどうか、あるいは、より良くなるかどうか。その良くなるっていう基準も、もちろん議論ごとに提示しなくてはいけないんだけど。その基準で良いかどうかっていうことで議論するべき。
笹田：便利っていうのも、ここでは便利だけども、他のところでは良く分からないっていうのもありますよね。
松本：もちろんそうですよね。
笹田：そこは、どう判断されているんですか。
松本：それは、提案ごとに、こういう基準で良い、ということを明示しないといけない。
笹田：で、明示して、確かにここでは良いということがわかった。でも、他の機能との整合性が取れていないっていう場合は。
松本：そう。トレードオフになるよね。
笹田：そこはどう決めますか？
松本：それは僕が決めるしかないんじゃない（笑）
笹田：で、そのユースケースは良くあるから、ぜひやるべきであるとか、それはあんまりないよね、とか。
松本：そうそう。あんまりない割に、ほかに影響があるから、トレードオフ的には採用できないというのはある。
笹田：なるほど。そこは、まつもとさんの技術者としての勘で、最終的に決める？
松本：まぁ、そうだよね。結局、提案する人はトレードオフに対する責任は取らないわけじゃない？
笹田：そうですね（笑）
松本：で、あなたの言う機能を入れて、それでほかに不便があるからって、文句を受けるのは僕なので。で、僕がトレードオフを享受できるかどうか、耐えられるかどうか、1つ心の中の基準にはなってる。言わないけど。
笹田：なるほど。そうなんですね。

笹田： 一貫性とは別の話で、一貫性と驚き最小の法則は一緒かと思ったけど、そうではない。
松本：驚き最小かどうかっていうのは、実は、一貫性より多くのことを含んでいて、一貫していないと驚くのは確かなんだけど、一貫しているからといって、驚かないとは限らない。
笹田：なるほど。
松本：「驚き最小の法則」のときの驚きって、実は色々な使われ方をしていて、一番多いのは、自分の慣れ親しんだプログラミング言語と違うって驚く、自分の文化との違いに驚くっていう。それは、一貫性があるかどうかってのは関係ないんだよね。
笹田：なるほど。では、一貫性だけで考えていうと、今ではどう思ってますか？　先ほどの話が、そのまま適用されるってことですかね。価値をきちんと定義し、それをほかとの影響も合わせて議論して。一貫性が議論の正当化にはならない？
松本：ここにある機能が、ここにもあるべきだ、とか、誰も使わないけど、こっちにあるから、こっちにもあるべきだ、みたいなことは、止めようかなと。
笹田：似たような機能で、こっちはエラーになるから、こっちでもエラーになるべきだ、みたいな。この間、[ブロックとキーワード引数の話]とかありましたよね。
松本：一貫性のために、揃えることは最優先ではなくて、揃ってることで嬉しいなら、それはいいんだけど、揃っていても、誰も使わないし、あってもなくても関係ないような時やむしろデメリットがあるときにまで、揃える必要はないかなという。
笹田：先ほどのブロックの話は、まさに揃えるかどうか、って話でした。これまで、ブロックを起動してもエラーにならなかったけど、Ruby 2.0.0からキーワード引数が導入されたことで、対応しないキーワードをつけてブロックを呼ぶことで、エラーが出るようになりました。あそこは、微妙なところだったと思うんですよね。それまでは、どんなブロック呼び出しでもエラーにならなかったので、驚くかもしれない、と。
松本：うんうん。
笹田： なので、エラーにならなくてもいいんじゃないかなというのは、ちょっと思ったんですよ。それで、エラーになってもならなくても、たぶん今のところはまだ困らない。まだ導入されたばかりの機能なので。
松本：そうだね。
笹田：そこに対して、明確に、誰が嬉しいんですかっていう風に、この間聞かれてましたよね。それで反論を封じた感じだったんですけれども。相手は一貫性しか言ってないから。
松本：うん。
笹田：そこはもう、ユースケースの方が優先であると。
松本：ユースケースもそうだし、あれの場合は、トレードオフが存在したわけだよね。つまり、エラーを無視することで、エラーの発見が遅れるっていうことは、デメリットなんだよね。で、今までのものとの、ほかの部分との、一貫性をとって、デメリットを受けるには、嬉しさがないなという風に思った。
笹田：逆に言えば、早めにエラーを出すようにすることも良いと。
松本：たとえば、互換性を何も考えずに、もし変更するとすれば、逆に、エラーを早く発見する方法に進みたいと思っているぐらいなのに。
笹田：あー。なるほどね。
松本：エラーの発見が遅れることは、原則的に悪いことなので、そっちの方向に進むことは選びたくなかった。
笹田：なるほど。了解です。では、一貫性の話はそれぐらいで。

笹田：あと、簡潔性、柔軟性の章。この辺は、まぁそうだよねという感じでしょうか。
松本：それはそうでしょうね。
笹田：簡潔性といったときに、さて、Rubyは簡潔かというと、多分この読者は「えっ」っというところですけれども（笑）
松本：簡潔っていう観点は、何で測定するか、という話になるのだけれど。たとえば、Rubyで書かれたプログラムが、どれだけ短くなるか、という。ポールグレアムは、トークンの数って言ってたけど（笑）。あるアイディアを表現したいのに必要なプログラムの構成要素の数が少ない方がいいっていうのが、基本的な概念で。で、そこは結構重要なんじゃないかなと、いまだに思ってる。そこは変わらないかな。
笹田：APLみたいに、ギュギュっとするのがいいんでしょうか？　ドメインが決まっていれば。
松本：ドメインが決まっていればね。たとえばRubyの配列とかの使い方の観点でいうと、APLの圧縮度は、記憶容量的な問題で結構辛いところがあって。僕はいまだにAPLの記号が覚えられないんだけど（笑）。そのことを思うとね、どっかに閾値はあって、現時点では、僕が閾値になってるのは確かだよね（笑）。僕の脳みそで把握できるかどうかって。なんか提案された機能を使ってプログラムを書いたときに「あ、これは簡潔に書けた」、だけど、多分、3カ月後にフレッシュな気持ちでみたら、多分理解できないっていうときは、ちょっと慎重になるよね。

笹田：柔軟性については、Ruby はもう十分柔軟で、それはもう変わんない感じですね。
松本：うん。
笹田：もっと柔軟でなくしてほしいっていう話がありますよね。Static typing 入れてほしいっていう声はたくさんあるじゃないですか。柔軟性と独立の事象なのかな。早くエラーを発見したいとか。
松本：早くエラーを発見したいという要求は、当然あるわけで、それはもっともだと思うんだけど、逆に、早くエラーを発見するというのがゴールで、そのゴールを達成するための手段として、たとえば、Static typingがあるんだけれども、Static typing を全面的に採用してしまうと、ある種の柔軟性は失なってしまうところがあるので、これもトレードオフなんだよね。
笹田：そうですね。
松本： 最近は、スクリプト言語と言われている言語で書かれているプログラムの規模が、昔に比べてずいぶん大きくなって、数千行、数万行、あるいは数十万行のプログラムを書く人が出てきた。そうすると、実行することなしに矛盾を発見したいっていうニーズが、より強まった。だから、たとえば、2010年代になって生まれた言語になってくると、静的型のついた言語が圧倒的に多い。
笹田：型推論がついたりとかですか。
松本：型推論がついてたり。静的型があって、かつ、型推論がついているっていうのが、圧倒的に多い。
笹田：まさに [Crystal] が Ruby においてそういう、型を追求した感じというところですかね。
松本：多分ね。で、そういうのが当然出てくるとは思うんだけれども。それは、ある種の柔軟性を失うことになるので。
笹田：うーん、本当にその柔軟性は必要なのかっていう。
松本：そうそう。
笹田：アセンブラでやったら、全部柔軟だよねって言っちゃうと、何もできなくなるのと同じで。
松本： いや、できますけど（笑）。言ってることは分かる。
笹田：Ruby にマクロを入れないっていうのも、柔軟性とは逆の方向ですよね。
松本：そうだね。
笹田：マクロがあれば、なんでもできる。でも、なんでもしたいのか、っていう。
松本： だから、どこかに閾値があって、そこはこう、僕が3カ月後にフレッシュな気持ちで見たときに、分からなくなるかもしれない（笑）。そういう不安があるものは慎重になるっていうのが基準だよね。やっぱり。
笹田：デザインポリシーですね。
松本：そうそう。基準はそこにある。あと、静的な型については、Rubyの柔軟性ってのは、ダックタイピングみたいなもので導入されてきて…12年前にダックタイピングって言ってたのかなぁ。あんまり言ってなかった気がするけど。
笹田： 書いてないですの、少なくとも、「Rubyの真実」には。
松本：ダックタイピングみたいなものが明文化されてきた。結局、ダックタイピングっていっても、要は、動的結合を言い換えただけなんだけど（笑）。ま、ダックタイピングという言葉を前面に出すことによって、継承であるという関係ってのは、意味がないな、という風に追求するポジションが、明確になったっていうのがあって。で、Rubyはずっとそこできてたわけだよね。で、そうすると、静的型の提供するような、サブクラスであれば代入可能ですよ、とか。
笹田：それはまさに、Java的な型システムですよね。
松本：そうそう。Javaの場合はね、インタフェースで、implementっていう形で宣言しておかなければいけないので。で、そういう意味の Static typing っていうのには、与することができないっていう風に思っていて。たとえば、Go の Static typing とかだと、気持ちは分かる。メソッド持ってればいいっていうのは、まぁ分かるって感じがする。でも、書くのがめんどくさいなっていうのが一番大きくて（笑）。
笹田：うーん、やるんだったらそっちに。
松本：あっちの方向だろうね。

笹田：12年前の「Rubyの真実」では、「オブジェクト指向大事だった。入れたのはすごいよかった。現代のスクリプト言語が、オブジェクト指向言語であるのは興味深い」っていうふうに書いていた。
松本：うん。
笹田：これは今でも適切？　継承とかは、この頃から言っていないのかな。
松本：継承の重要性は、言ってないね。
笹田：言ってない。オブジェクトが、何をするかというのは知っているっていう。
松本：うんうん。
笹田： Smalltalk 的な。
松本：モジュール的な。機能のモジュール化としての、単位としての、オブジェクト。
笹田：オブジェクト指向は適切である。それは変わらない？
松本： うーん、そうだね。ただ、現代においては、関数型が、まぁ、当時からあったんだけど、いわゆる副作用のない、少ない、Haskell や、OCaml みたいなタイプの関数型言語が、非常に普及してきて、概念もよく理解されるようになった。で、副作用をどう制御するのかっていうのが、重要なテーマになってきている。
笹田：オブジェクト指向と、副作用云々は、独立な話だと思うんですけどね。
松本：これが難しいところで、つまり、アイデンティティの話で。
笹田：あ、分かります。mutability をいかに制御するのかというのが、ああいう世界だと思っていて。これは mutable 許さないっていう世界とはバッティングするよねっていうのと。
松本：そういうこと。
笹田：いくつかの言語では、それを両立できていると思うけれど。たとえば、変更は毎回別のオブジェクトを作る、とか。
松本：オブジェクト指向は、そんなに大したものではないと思うので、オブジェクト指向っぽく見えれば、それでいいと思うんだけど。
笹田：うーん。なんか、変更の単位が小さく見えればいいっていう。
松本：そうそう。それでいいと思うんだけど。ただ、毎回新しいものを作るっていうモデルが、馴染むかどうか、よく分からないところがあって。オブジェクト指向が有効に適用されるといった、たとえば、GUIツールキットみたいな話だと。
笹田： ウィンドウが、もう1個できるのか、とか（笑）。
松本：そうそう。新しいオブジェクトを作ったときに、同じオブジェクトを指してるよねっていう。同じ画面上の、仮想的なものを指しているよねってなったりすると。
笹田：関数型で考えると、状態が変わったら、まったく新しい世界ができるっていうことですよね。
松本：やり方によって、いろいろだと思うけどね。たとえば、ストリームタイプのものもあって。ユーザのインプットが、全部ストリームとして中に入ってきますと。で、画面への出力は、全部ストリームして外へ出て行きますという感じのものも、当然あるわけで。
笹田：JavaScriptなんかだと、最近はそういう風に作ろうとしている感じがしますね。
松本：そうだね。Reactとかそんな感じだよね。全部がーんと出しちゃって、それに応じて、変更された分だけ、アップデートする形を、処理系の中で持っているという感じではあるけど。で、2015年現在では、オブジェクト指向は主流になったので、どうでもいいっていうか、あって当たり前なんだけど。2015年時点でいうと、関数型の普及期に入ってきていて、ただ、オブジェクト指向が素直に扱うことができた問題が、素直に扱えないものがあるので、それをどうするのかというのが課題で。
笹田：素直に扱えないって、なんですか？
松本：今言ったけど、毎回世界が置き換わるって、どういうことよ、画面上のウィンドウは変わらないじゃんっていう。
笹田：関数型にすると、なかなか難しいけど、オブジェクト指向だったら、今までできたことじゃないの、と。あれ、オブジェクト指向だと、なかなかできないって話じゃなかったっけ。
松本：オブジェクト指向でやりづらいことって、実はあまりないんだよね。
笹田：なんでもできる。
松本：そうそう。それは、アセンブラがなんでもできるっていうのと同じだから。関数型の方が抽象度が高いので、その抽象化のモデルが我々の脳内に持っているモデルと、必ずしも合致していない。現時点では合致していないので、それが我々の脳内モデルが進化するのか（笑）プログラミングモデルが進化するのか分からないけど。何かもう一歩必要なのではないかなと思っているっていう感じ。
笹田：なるほど。
松本：そんなふうな未来が来たら、もしかしたら、オブジェクト指向はいらないって話になるかもしれないけど。

笹田：見かけの重要性は、DSL（Domain Specific Language）かな。
松本： DSL もそうなんだけど。「Rubyの真実」を読み返して思ったんだけど、日本のコンピュータサイエンス、プログラミングが始まるようになってから、過去50年ぐらいの間、さまざまな試みが行われて。言語作った人もいっぱいいるのに、流行っているのが Ruby しかないのはどういうことかっていうのを、書きながら思っていたのを思い出した。で、こういうふうにしたら、次の言語ができるかもよ、という意味も込めたつもりがあったような気がするのよ。
笹田：全然乗ってきてないね（笑）
松本：誰も乗ってこないのは、どういうことなんだろうねぇ。それがね、今一番、多分言いたいことだと思う（笑）。Ruby 1つしかないのは不健全で。もう1つや2つ出てきてもいいと思うんだけど。で、いろいろな事情があると思うんだけど。だから、アカデミックなことだけを前面に出してデザインするといかんから、非本質であるみたいなことを、次の言語のデザイナーに、ヒントとして出したつもりがあったということを、読みながら思い出した。なんだけど、明確に書かなかったせいか、誰も乗ってこなくて（笑）。
笹田：あー、今だと、それこそ、いろいろな知見があって、Rubyにもいろいろと足りない点が分かってきた。
松本：そうそう。
笹田：なので、今はチャンスだと。
松本：ねぇ、だから新しい言語が来てほしいし、来るべきだと思ってるのね。で、それが、たとえば、言語の当たり年の95年から、今までの間、言語の氷河期みたいな時代だった、っていうなら、まだ分かるんだけど。出しても出しても上手くいかないと。でも、そうでもなくて。結構、プログラミング言語出てきているのに、日本から来ないんだよな。
笹田：個人が出してるのは、あんまりないと思いますよ。個人から出して流行ったのって。
松本： CoffieScript
笹田：あれ、個人なんだ。
松本： うん。
笹田：プロダクトに上手く当たったっていうことですね。
松本：もちろん、DartとかGoとか、TypeScriptとかは企業からだけど。
笹田： Scalaとか。
松本：Scalaはね、割と個人が大きいと思うけどな。オデスキー先生、結構自分でデザインしてるし。あと、Clojureもそうだよね。個人だよね。Rich Hickeyさん。
笹田：個人、結構いる。
松本：うん。だから個人だからできないってことはないと思う。もちろん、2010年代の言語のメインストリームが、企業によって、Swiftもそうだよね、来てるのは確かなんだけど、じゃ、個人が勝負できないかっていうと、そうでもないんだよね。
笹田：座談会で、加藤先生もいってましたよね。OSは難しいけど、言語ならまだいける。
松本：言語ならまだ、ギリギリいける。いまならいける。まだ間に合う。企業ベースの言語が出てきたのって、ほんと、ここ5年ぐらいだから。逆に言うと、12年前からの7年間は、何をしていたんだっていうところがあって。
笹田：なるほど。それはぜひ、最後のまとめの章に（特集第1記事のまとめの章に書きました）。
松本：言いたいなと思って。読み返して、思い出したのは、次の言語来てほしいと思って。ヒントとして、巨人の肩に乗るとか、入手可能性とか、コミュニティとか、運の善し悪しとか。
笹田：ああ、これ全部そうなんだ。なるほどね。
松本：そうそう。課題については現状の報告だけど、非本質が重要だとか、こういうのって、次に来てほしいっていう。だから、こういうやり方って大事だよっていうつもりで書いたのに、誰も乗ってきてない。
笹田：（笑）

笹田：見かけの重要性の話で、DSLの話を振りたかったんですけど。12年経ってみて、これは良かったっていうのはありますか。DSLが流行ったっていうのは、その中の1つのものだと思うんだけど。DSLも含めて、何かその辺はありますか。
松本：見かけ大事だったのは確かで。ここまでDSLとして使われるっていう風には思ってなかったんだけど、そういう使い方ができるようなことは、意識していたので。
笹田：意識していたんですね。
松本：うん。括弧外れるとか…。
笹田：括弧外れるのはそうですよね。セミコロン書かなくていいとか…。
松本：そうそう。最初は必須だったのよ、実は。セミコロンはなかったけど、括弧は必須だったんだけど、書いているうちに、これ、書いてて、なんかこう…、必ずプログラムに見える。設定ファイルみたいに見えないので。
笹田：あ、設定ファイルにしたかった。
松本：したかった。たとえば、自分でエディタを作ったとして、エディタの設定ファイルが.emacsみたいなのをRubyで書くとしたら、どう見てもプログラムにしか見えないものにしたくなかったのね。
笹田：へー。
松本：その辺は考えて、括弧を外すのはすごい大変だったんだけど。正直（笑）
笹田：パーサ書くのがね。
松本：パーサ書くのが（笑）だけど、意地でも括弧を外さんといかんと思って。で、外したんだけど。
笹田：そしたら、ああ、英語っぽいっていうので、英語圏の人が。
松本：Rakeぐらいは予想してたんだけど、なんか、RSpecとかは、ちょっと予想外…。
笹田：Rakeぐらい。
松本：そうそう。targetとか。ちょっと前までの、RSpec の should_not be とかはだいぶ予想外な感じが。
笹田：設定ファイルみたいに描きたいっていうのが、それがRubyの流行った理由の1つなのかな。
松本： まぁ、あると思うよ。で、あと延長線上にマクロが出てくるんだけど、ブロックと、括弧を外せるメソッド呼び出しがあったら、マクロいらないんじゃないかと思って。
笹田：それがキーアイディアだった。
松本：そうそう。で、そのまま突っ切ってる感じ。
笹田： いまでも変わらないですね。
松本：そうだね。マクロをやると、なんでもできるけど、なんでもできる必要もないかなと思ってて。マクロをなくてもRSpecをかけるので（笑）。
笹田：ほかの言語への変換、たとえば、SQLへの変換みたいな話は、支援したいねとおっしゃってますよね。それで「!」がメソッド呼び出しになったりとか。
松本：うんうん。
笹田：で、まだ if ができないとか。それでどうしようみたいな話はあって、その辺をまだ支援したいと思っている？
松本：うーん、なんらかの形で考えたいとは思っているんだけど。
笹田：それは、マクロでやりましょうということになりませんか、シンプルに考えると。
:松本: 普通に考えたらね。そうなんだけど、まぁ、ちょっと…。
笹田：それはやりすぎ？
松本：やりすぎかなと思っていて。で、Elixirっていう言語は、マクロはあるんだけど、マクロがあるっていっても、あれはASTを操作できるだけなんだよね。で、そうするとそれは1つの方向性として、もしかしたらありなんじゃないかと思うところはある。
笹田：もう定義されているメソッドは書き換えられなくて…。
松本：プログラムをコンパイル時に、ある一定の条件でASTを取り出して、それを加工してもう1回埋め込んだ状態で、コンパイルする。
笹田：でも、マクロってそういうもんじゃない？
松本：マクロはそういうもんなんだけど、えーっと…。
笹田： Cのとかは全然違いますけど。
松本：まぁ、Cのマクロは違うけど。
笹田： Lispのってそうじゃない？
松本： Lispはもともと、プログラムがTreeだから。Lispだったらあんまり問題ないんだけど。たとえば、Dylanって言語があって、あれのマクロって、定義がすごい大変なので。もともとのAlgolっぽい文法とマクロを組み合わさないといけなくて、パターンマッチングみたいなことをして、なんとかにマッチしたところは、ここに展開するみたいなことを書かないといけなくて、そういうのって、絶対に嫌ですよね。
笹田：ASTを取り出して、それを弄るのはいいんだ。
松本： えーっとね、まだマシ。
笹田：Crystal そうですよ、確か。
松本： Crystal もそう。うん。そうなんだけど。あと、そうすると、呼び出しがメソッドかマクロかを調べないと、どっかで分かるようにしないといけなくって。スタティックに。でも、ね、Lispとかだと、関数呼び出しもマクロ呼び出しもあんまり関係ないので。
笹田：そうですよね。
松本：で、あれはできないし、かといって、マクロ専用の記法が入ると、すごい気持ち悪いので（笑）。
笹田：あの、1つの案として、さっきASTを取り出して、それをいじって、また戻すっていったんですけど、ASTは取り出せて、終わり。戻せないっていうモデルはどうですかね。たとえば、ほかの言語へのトランスレーションを考えるときには、木構造が取れました、それでほかの言語にやりましたとか。たとえば、もともとのRubyからSQLに変換するという例だと、ブロックの中の文字列を取り出してパースして、それをRDBMSへ送る。その後、Ruby には戻さない。で、たとえばevalみたいな感じで。define_methodで渡して、そっちでやるとかっていうのは。
松本：その場合、ここからここまでの範囲のASTを欲しいっていうのを、どうやって書くかって話だよね。
笹田：ブロックでいいんじゃないですか。
松本：このブロックで…。でもそしたら、ブロック全部でASTを保存しておくってこと？
笹田：うん。取れるようにする。
松本：それって、現状コンパイル後に捨てる AST を後生大事に取っておくってことだよね。実装的には。
笹田：えっと、実装の話をすると、ええと…ソースコードだけを保存しておく。ファイルは変わらないということを前提で、ファイル中の位置だけ取っておいて、ぱっと文字列取ってこれるので、改めてそこからパースする。
松本：っていう風にする？
笹田：うん、というのは別にコストはかからない。やろうやろうって前から言ってる話ですけど。
松本：それ、でも、元になるファイルが存在しないevalでは動かないよね。
笹田：evalのときは、動かすプログラムをがんばって保存する。
:松本: 保存する？（笑）そっか。…ASTを取り出すことそのものは、実はあんまりネガティブではなくて。
笹田：どうでもいい？　やったほうがいい？
松本：どうでもいい、やってもいい。どれぐらい嬉しいか、どのぐらい影響があるか、ちゃんと見積もらないと、断言はできないけど。
笹田：多分、AST の仕様を決めるときに波乱になると思うんですけど。
松本：まぁ、そうなんだけど。ただ、いわゆるマクロを導入しましょうっていう提案に比べると、ずいぶん拒否感は少ない。
笹田：なるほど、そうなんですね。…すみません、だいぶ、こう、たぶん…。
松本：これは記事には載せられない（笑）
笹田：見かけに関しては、12年の経験は、そんな感じで。
松本：基本的に、大事にしている原則については、そんなに変わってなくて、ただ、いくつかの点について、一貫性についての重要と思っている度合いが下がったとか、あと、それに関連して「驚き最小の法則」っていうのを、言語設計については重要視しないというふうになったというのはあった。それは何かというと、たぶん、2003年の時点で、言語設計の判断って、基本的にぜんぶ僕がしてたんだよね。新しい機能を入れるかについても、僕がするっていう。
笹田：自分でアイディアを出してた。
松本：自分でアイディアを出して、自分がこれはいいんじゃないっていって、ほかの人にダメ出しをされて、採用されなかったケースは、このときからあったような気はするけど（笑）で、そういうのはあったんだけど、現代においては、どちらかというと、いろいろな人がRubyに対して提案を出すようになって、僕はそれを取捨選択することが多くなってきたんだよね。
笹田：なるほど。
松本：で、そうすると、そういう議論の進め方が変化してきたっていうのは大きいかな？

笹田：コミュニティに関して。「Rubyの真実」の中では結構短いんですよ。「開発コミュニティも良いやつばっかりだぜ」、って感じで書いてあって、開発コミュニティのことしか書いてないんですよ。インタプリタ開発コミュニティの話しか書いていない。オープンソースで、こんなふうにして、うまく回ってますって書いてない。たぶん、10年で変わりましたよね。
松本：変わったのはそうだよね。この時点だと、たとえば、PerlにはCPANがあるけど、Rubyにはないってずっと言われてたんだけど、いまやPerlがRubygemsを真似する時代になってたりするので。
笹田：そうですね。
松本：ライブラリの数でも、カバーしている範囲内でも、圧倒的に勝ってるっていう現状を考えると、プログラミング言語を選択するときに、あの言語は美しいから選ぶって人は、むしろ少数派で、どっちかっていうと、あの機能、あの仕事をしたいときに、こういうライブラリが定義されているので、仕事が早く進むから、言語を選ぶっていう人が、圧倒的に多いので。そういう意味では、インタプリタ開発コミュニティの外側の、Railsであったり、Rubygemsであったりっていうコミュニティが果たす影響っていうのは、ものすごく大きくなっているというのは確かですよね。
笹田：たぶん、この頃って、日本国内がやっぱりおっきかったと思うんですよね。
松本：そうですね、はい。
笹田：日本で閉じた印象で、「Rubyの真実」は書かれていると思います。現在では、Rubyは世界中に広まっています。2001年から、アメリカで行われるRubyカンファレンスが始まり、2004年のRuby on Railsで、バーっと広がりました。何か変わったとかありますか。
松本：Rubygemsもそうだし、その他のものもそうだし、そういう開発コミュニティを超えた、より広いRubyコミュニティの成長ってのは…。
笹田：ユーザコミュニティ。
松本：そう。ユーザコミュニティってのは、Railsによるものが、かなり大きい。
笹田：生活が変わった？　違うな。何をここに書くと面白いのかな。
松本：コミュニティの国際化ってのは1つあるよね。たとえば、メーリングリストの流量が、海外のものが、国内を超えたのが、何年だったっけ。2006年？　グラフ書いている人がいたけど。なんかその辺で。で、そこから先は、指数関数的というか、ものすごい勢いで差が開いていく一方だったりとか、あるいは、カンファレンスも、日本で細々と開かれたり開かれなかったり、勉強会したりしなかったりだったのが、アメリカで定期的にRubyカンファレンスができて、最初は30人だったのが、いまだと、何百人参加があって、さらに、それに加えて、Railsカンファレンスが出席者二千人とかってのがあって。で、それだけで飽き足らず、世界各地で、Rubyのカンファレンスが開かれるようになって。で、それぞれのカンファレンスが、数百人とか出席者があって。それも1回だけじゃなくて、レギュラーのものが。
笹田：まつもとさんも、毎年色々なところに行って。
松本：本当だよね。何カ国も。この間ヨーロッパ行ったら、行ってない国の方が少なくって。
笹田：（笑）
松本：ヨーロッパの地図見たら、だんだん塗りつぶされた数が増えてるっていう。東ヨーロッパは、まだ行ってない国は結構あるんだけど、それでもチェコもポーランドも行ったし。
笹田：ポルトガル行きました？
松本：ポルトガルはまだ。
笹田：僕の方が先ですね（笑）
松本：フィリピンも行ってないし（笑）
笹田： 本当だ。さっきの話だと、こういうふうにやると、言語作れるぜ、流行るぜ、という話だったけど、国際化ということに考えると、注意することって何かありますか。
松本：えっと、言語のリーダーってのは、コミュニティリーダーに直結しがちなので、そこで、たとえば理不尽なものに対しては、どうとかですね。
笹田：理不尽な参加者に対しての。
松本：理不尽な参加者に対しての、こう、英語ではtrollって言うんだけど。あれに対して、そんなこと言わないで、みたいになだめるような。後ね、毎回気をつけているのは、フェア、公正公平であること。もちろん僕はRubyを作ったから、Rubyの中では一番偉い人ってことになってはいるんだけど（笑）、実際コミュニティの中に入ってきた人は分かるんだけど、実は僕はあんまり一番えらいって感じはいなくて（笑）。まつもとがまた変なことを言っているとか言われることもよくあるので（笑）。で、そういう意味でいうと、公平なコミュニティ運営を心掛けていて。誰かが、いわゆる、ふとした思いつきを出しても、3年ROMれみたいなことを言うんじゃなくて（笑）。そのアイディアについては、真面目に返事をする。お前みたいな素人は口を出すな、みたいなことではなくて。
笹田：寛容であるってことなんですかね。
松本：寛容であるっていうか、フェアってことだよね。その人が、10年前にRubyコミュニティに参加しなかったのは、その人のせいではないじゃない。出会うかどうかの問題だから。
笹田：そうですね。
松本：あなたは10年前に、Rubyの開発に参加してなかったから発言権はありませんって言われたら、それはフェアじゃないよね。そういうのは嫌なのよね。僕がそう言われたくないからだけど。
笹田：なるほどね。そういうのを注意しておけば、こんなに大きいコミュニティができる。
松本：…かどうかは運次第だけど。
笹田：（笑）
松本：まぁ、あとは出会いを大事にみたいなのはありますよね。Rubyの場合だと、Dave Thomasが本を書いてくれたときに、本書くのにすっげーたくさんのメールを書いてきて、あれはどういうことだ、これはどういうことだって、すげーメール書いてきて。当時はあんまり英語は得意じゃなかったし、アップアップしながら返事書いたんだけど（笑）。そのとき、大変は大変だったけど、だけど、それがあるから、今のRubyがあるっていうのは、言い過ぎではないし、あと、たとえば、2001年に、デンマークのカンファレンンスに行ったときに、DHHに会ってるんだよね。
笹田：おお、そうなんだ。
松本：まだ学生だったんだけど。
笹田：へー。
松本：で、それでプログラミング言語について、一生懸命しゃべった覚えがある。
笹田：えっと、Rubyがこうだとか、彼から、なんでこうじゃないんだとかそういう？
松本：Rubyのデザインについて話した覚えがあって。そのとき、彼はそのカンファレンスの学生ボランティアだったんだよね。で、PHPプログラマだったって言っていた気がするけれど。Dave Tomasと、僕と、DHHが、同時だったかな？　それぞれ同じカンファレンスに来て、そういう話をしたんだけど。僕は、実は正直忘れていて、後でDHHから、そのときの話を聞いたときに、おお、そういえば話したことが。あの人があなただったのね、みたいなことが。ま、それもやっぱり、お前みたいな素人が口出すな、みたいなことを言ったら、何くそRubyでなくてPythonでやるってなったかもしれないし（笑）。
笹田：ファンを大事に（笑）。
松本：ファンを大事に。貴重な存在だから（笑）。自分の作ったものに対して、関心を持ってくれると嬉しいので、それに対して口出すなみたいな言い方をするなと。
笹田：なるほど。
松本：コミュニティの話をすると、あとは、GitHub以降は、ソーシャルコーディングが流行って、すごいスタートアップが早くなったってのがあるよね。新しいものが増えたときに、それを見つけるっていう点でも早くなった。
笹田：社会的に、コーディングの速度が早くなった。
松本：うん。たとえば、Streemっていう言語を、去年の年末に作って。自分の作ったソースコードを、バックアップのつもりでGitHubのリポジトリにアップロードしたら、誰かが即見つけてきて（笑）。で、バズるっていう。そのときの時点で、文法定義200行しかない、ゴミみたいなソフトなのに、それでもバズるっていうのがあって。それでPull Requestを送ってきたりとか。お前の構想している機能を俺が作ってやるみたいな人が出たりとか、そういうことがあって。それって、Rubyを作ったとき、1993年の公開前とか、あり得ない感じだったので。そういう意味でいうと、ものすごい速い。
笹田：どんどん公開した方がいいよってことですかね。
松本：それね、今回そう思うようになったのが1つあって。つまり、オープンソースソフトウェアって、すごいたくさん、途中で挫折するやつがあるのね。で、GitHubとか見てても、コンパイルもできないじゃんみたいのが、結構たくさんあって、オープンソースソフトウェアがうまくいくには、実には、動くレベルまで持って行って、動くからこそ、みんなが話をするっていう風に、ずっと思ってたんだけど、Streemって、動かない時点からバズって、パッチ投げてくれるひともいたというところを見ると、結局、注目を浴びさえすれば…。
笹田：プロモーションが大事。
松本：プロモーションが大事なんじゃないかなという風なことを。Heroku入社以来、毎年リリースに変わったときに、この年の、このリリースの目玉はなんだ、っていうのを考えるようになって。それまでは、とりあえず思いついたものをどんどん入れて行って、リリースのタイミングで入ったら、それは目玉として言おうねっていう手順だったのが、逆に、今年の年末にリリースするから、これとこれは入れておかないと、何もしないと、何それみたいなことを言われるので。これとこれは入れて、変化しているということを示そうみたいなことを考えるようになったのが、ここ数年の、5年くらいの変化のような（笑）。
笹田：プロモーション大事というのが、リリースに出てきた姿勢として。なるほど、面白いですね。
松本：気持ちが変わったのはある。コミュニティについて。

笹田： 処理系の話をしましょうか。この辺は面白いですよね。いろんな処理系の課題があるよねって話が書いてあって。この辺、mrubyでだいぶ解決した。
松本：そうなんですよ。12年も経って、こんなものが。mrubyが出たのは2年前だから、10年経ってってことだね。
笹田：インタプリタ初期化もできるようになったし、インタプリタの高速化もできるようになった。
松本：できてるできてる。ネイティブスレッドは、実は対応してないんだよね。だけど、高速化はできてるので、スレッドに構造体を割り当てるのができるようになったし。
笹田：それがまさにやったのが、Riteという名前をつけるものだったということですね（笑）。
松本：Riteって名前をつけようと思ったんだけど、結局mrubyになりました。
笹田：mrubyが、まさにそうなったと。
松本：実現しました。
笹田：ネイティブスレッド対応は、CRubyでやったので。
松本：CRubyでやったね。
笹田：適切かどうか分からないけど。
松本：まぁ、いまね、インタプリタロックがどうとか言われてるけど。
笹田：言われてますね。うーんと…バイトコード化と、新たなガーベッジコレクションの導入予定。実現した！
松本：できましたね。この時点では、ささだくんはイメージできてたのか…。でもRiteが出てきたってことは、あんまあれなのかな。
笹田：未踏の頃ですよ、たぶん。
松本：でも、あの時点だとさ、できてたんだけど、取り込めるレベルまで届くかどうかは、確信持てなかったもんね（笑）…未踏、2003年だったっけ？
笹田：2002ぐらいじゃないですか。
松本：2002年だっけ。…あ、僕の未踏？僕の未踏は2000年。
笹田：だから、それの流れじゃないですか、この話は。私が作り始めたのは、2004年だもん。
松本：2004年に作り始めた。これは、その時点ではYARVはないんだ。
笹田：ないですね。…ええと、この辺の課題は、大体で終わってる感じがしますね。
松本：そうだね。実装については、言ったことはちゃんとやったみたいな感じ。

笹田：じゃあ、今後の課題を。
松本：この時点で、予想はできてなかったことうちの1つは、普通のコンピュータのコア数が、ここまで増えるとは思ってなくて。で、デュアルコア、クアッドコア、下手すると、オクタコアみたいなのが、普通のコンピュータにあるので、8個のスレッドを活用しないと損するみたいな（笑）ところについては十分予想ができなかったってのがあって。それが1つと。もう1つは、それも関係するかもしれないけど、ハイトラフィックなところ。
笹田：ハイトラフィック。
松本：当時から、当然Webサイトはあったんだけど、ほとんどのWebサイトって、月間アクセス数5,000件とか（笑）そんな感じだから、ここもそんなに関係ないと思っていた。なんだけど、今だと5,000アクセスとか秒単位で終わってしまう感じがあって。そのような環境。あるいは、C10K問題とか。
笹田： それは、言語レベルでは、何で対応するんですかね。
松本：分かんないんだけど。
笹田：C10Kについては、selectはダメだっていう文脈だったじゃないですか。それでEventMachineとかできてきました。それで、EventMachine、CRubyのbindingでつかえます。それでいいんですかっていう。
松本：なんだけど、あれはマルチコアが使えないんで。それどうするか。マルチプロセスでばら撒くかとか。で、なんだけど、Unicornだと、メモリ食いすぎるから、本当はスレッドでやりたいよねみたいな流れがでて。で、Rubyネイティブスレッドは、マルチコアが活用できないよねっていう流れがどんどんきてると思うので、そこは考えないといけないなと。
笹田：そうですね。考えます。処理系に関してはそんな感じかな。
松本：うん。で、まぁ、あとは、僕にとって予想外だったのは、ここまで未来になっても、メモリがボトルネックになっているというのが予想外で。
笹田：メモリ消費。
松本：うん。
笹田：クラウドでメモリがたくさん使えると思いきや！
松本：思いきや、実は、ちっちゃいのがいつまでも生きていたっていう（笑）。
笹田：課金されるようになったっていうのが面白いですよね。時代が一回りした感じが。
松本：そうだね。だから、ああいうテクノロジってぐるぐる回るので、CPUがボトルネックだったとか、メモリがボトルネックだったとか、ネットワークがボトルネックだったとかいうのが、ぐるぐる回ってるので。で、今は最近メモリが一番ボトルネックになっていることが多くて。いろいろな新しい機能や、スピード速くしたいので、JIT入れますとかするときに、でもメモリがっていうのが、二言目にでてくるとか。
笹田：そういう意味だと、JITは課題に入れてもいいですか。
松本：JITは入れたいところだよね。ま、検討はしたいと思うんだよね。
笹田：処理系に関してはこんな感じかな。性能改善と。あと、処理系というより言語でなにかありませんか。
松本： 言語についてはそんなことはなくて、適用分野を広げたいですね。適用分野を、Ruby=Web言語みたいになってるので、それは2003年とは違うところで。この時点では、スクリプト言語みたいなイメージだったけど。
笹田：そうですね。
松本：現時点では、Ruby=Web言語みたいな。まぁ、ユーザの意識の変化みたいなのが。
笹田：そうか。2003年では、Ruby=テキスト処理言語なんですね。それが今だと、Web言語。
松本： Web言語で。なんだけど、そこで閉じてはいけないみたいのがあって。次の領域を常に探さないといけないってのがあって。で、特にこの時点では、Rubyってのは、名もしれない、いつ終わるか分からないっていうか。注目は浴びてるけど、そのうち消えるかも、みたいに思われてたみたいなんだけど、実は僕の意識は、そこはあまり変わってなくて。Rubyは明日にも滅びるかもしれない（笑）って、毎日思ってて。トレンドの変化によって、Rubyの人気が急激に下がる、みたいなことが起きるんじゃないかと、いつもドキドキしてるんだけど。
笹田：なるほど。
松本：で、そういう意味でいうと、パラノイアっていう。Intelのポリシーがそうらしいね。only paranoid can surviveって言って。偏執狂だけが生き残るっていうみたいな。だから、いろいろなことをやれっていうのがあるみたいだけど。で、その思想ってのは、Rubyはいつも明日死ぬと思って生きてきたので、20年間（笑）。で、生き延びるためにいろいろなことを。だから、Webが来たからもうRuby大丈夫じゃなくて、Webじゃない新しいところにもとか思ったりやったりするのも、僕が貧乏性なところもあるんだけれども、生き延びるために何でもやります、みたいな。
笹田： うーん…。で、サメのように、どんどん泳ぎ続ける。
松本：そうそう。走り続けるっていうか。あ、そうそう。走り続ける話もしたほうがいいよね。そういえばね。どうしても保守的な判断になりがちなので、過去のプログラムが壊れるからもう変化しません、みたいな。そういう選択肢を重ねて停滞すると、つまらないんで（笑）
笹田：つまらないと人が減ってっちゃう。
松本：そうそう。つまらないと、コミュニティが衰退するので。そうならないように、燃料を（笑）、ガソリンを投入しないといけない。

笹田：だいたい一回りしましたかね。
松本：そういう感じだね。で、やっぱり、この10年の間に起きた大きな変化ってのは、Web化と、コンピュータの性能の向上と、特にマルチコアなんだけど。予想外だったのが、メモリのバンド技術が、メモリの量が、そんなに伸びなかったっていうところで。それに応じて、Rubyそのものも、性能が良くなるように変化しましたし、12年前にやりたかったことは、だいたいやりましたが、まだまだ新しい状況に十分適応できているとは言い難いので、これからも変化し続けます。という感じかな。
笹田： まとまった。
松本： 言語設計についても、これが大事だと思ってきたものは大切にしてきましたが、その中のいくつかは、実は大事だと思ってきたけど、そんなに大事ではなかった、というのが明らかになりました。特に言語設計を議論に参加したいと思う人が増えたので、それに伴って、驚き最小の原則とか、一貫性とかについて、プライオリティが変化しましたってのがあって。最後に、12年前にこの記事を書いたときには、Rubyの次の言語が、読者から出てきてほしいと思ったんだけど、まったくその気配がないので、どういうことかと（笑）次の10年こそ、新しい言語が日本から、というかこの記事の読者から、出てほしいと切に願うということを、今度は明確に書こうと。
笹田：明確に。かかってこいと（笑）
松本：かかってこいだよ、ほんとに。2番目が、Streemだったら、お笑いだよね（笑）
笹田：（笑）
松本：日本から2番目の言語が出ました。誰が作りましたか。まつもとです（笑）大笑いだよね。
笹田：また上司が言語を作ってる（笑）（注：Heroku, Inc. において、松本は笹田の上司）。
松本：そうならないといいよね。
笹田：そうですね。今日はどうもありがとうございました。