Matzミーティングに潜入！Ruby開発者・まつもとゆきひろさんに聞くRuby秘話
こんにちは、広報の坂井（@hana_yonde）です！
ZOZOテクノロジーズでは月に1度、技術顧問であるまつもとゆきひろさん（通称：Matz）とのオンラインミーティングを実施し、勉強会を行っています。
「社員なら誰でも参加自由！」ということで、ミーティングにお邪魔してきました！社員があれこれ聞いていたので、当日出た質問とMatzさんからの回答を抜粋してお届けしたいと思います。
Rubyの人気が低下…？日本のプログラマーのガラパゴス化について
ー 最近、プログラミング言語の人気ランキングなどで「Rubyの順位が徐々に下がってきている」と感じることがあります。Rubyの人気がなくなってしまうと、日本のプログラマーがガラパゴス化するというか、世界から孤立してしまうんじゃないかなと思っているのですが、MatzさんはじめRubyを作っている方たちはどう考えていらっしゃるのでしょうか？
Matz：ご質問ありがとうございます。それについては、いくつか分けないといけない点がありますね。まず、人気がなくなってきているという点について。正直に言うと、2010年ぐらいからRubyの人気が実態を超えていたところがあったと思います。そう考えると、今はハイプ曲線で言う「幻滅」から「安定」に来ている時期なんだと思います。つまり、実態に見合った人気のレベルに落ち着いてきたというのが僕の認識です。
必要以上に人気が高まっている状態は不健全だと思うので、今安定しているというのはそれでいいんじゃないかと思っているんですよ。確かに最近ホットになりつつあるようなフロントエンドやAIなどのジャンルにおいてRubyはあまり強くないので、その辺りについて人気のかげりのように捉える方もいると思います。ただ、実際問題としてプログラマーがWebを開発する時のバックエンドの選択肢として、Rubyはやっぱり悪くないチョイスであり続けていると思ってるので、そういう意味で言うと安定的な状態にあると思います。
次に「ガラパゴス化」というのは「日本では伸びているけど世界では下がっている」という状態だと思いますが、先程申し上げた「人気が落ち着いている」というのは、日本に限らず世界的な状態なんです。つまり、逆に言うと日本でも海外でも根強い人気があると思っています。
例えばGitHubやShopify、AirbnbなどもRubyを使っていますし、海外の大きなサービスでもRubyが使われている例はそれなりにあるんです。それを考えると、日本だけRubyの人気が高いというのは、実は前提としてあまり正しくないんじゃないかなと思います。
最後に「Rubyを作っている人はどう思っているのか」という話について。先程の通りとはいえ、順位が下がっているのは間違いなく、人気が下がるとコミュニティの人たちが少なくなっていくというのは当然ありうることです。そういうことがないようにの魅力を維持していかなくてはならなくて、工夫したり新しい機能を追加したりとか、改善したりとかを継続しているわけですね。「当たるも八卦当たらぬも八卦」というところもあるので、私たちとしては当たらない努力を続けてますというところですね。
ヒープ領域とスタック領域の位置関係について
ー x86のメモリ構造ではヒープ領域は若い番号から古い番号に伸びていて、スタック領域はその逆に古い番号から若い番号に伸びています。この2つが逆の立ち位置にあってもおかしくないのに、なんでこのような位置関係になっているのでしょうか？
Matz：まず、スタティックなメモリ領域があるんですよね。プログラムのコードが置かれる領域で、書き換えることができない領域です。例えば、UNIXでプログラムが起動された時に、最初にその領域にメモリがアロケーションされるんです。その領域の終わりがブレイクという「ここまではメモリを使っているよ」という値になっています。ブレイク値を大きくすることによって、仮想メモリを割り当てていくアロケーション方式だったんですね。つまりブレイクより下の領域が常に実際に割り当てられたメモリで、ヒープということになのるので、ヒープが下から上に伸びていくのはそういう理由があります。
スタックのほうは、実はOSによって色々なんです。必ずしも上から下に下がっていくというものばかりではありませんでした。前提条件として、昔のコンピュータにはあまりメモリがなく、1つのプロセスには1つのスレッド(物理スレッド)しかなかったんです。そうすると、有限のメモリ空間を最大限に利用するためにはスタックはヒープと逆方向から下がっていって、メモリを使い果たした時にぶつかって終わりというレイアウトだったんですよね。ところが今のマルチスレッドでは、スタック領域が同じメモリ空間に複数あったりするんですよ。そうすると、スタックアドレスが飛び飛びになるので、実は今はどっちから伸びても関係ないんです。昔はそうだったので、今もそうしている感じのが多いだけですね。実際にRubyのGC(Garbage Collection)でスタック領域をスキャンするコードがあるんですが、スタックが上から下に伸びるか、下から上に伸びるかを条件分岐するようにしています。全部のOSで固定ではないということなんです。
ー スタック領域とヒープ領域ってコンピュータの歴史において同時期に誕生したものなんですか？
Matz：厳密に言うとヒープっていうのは正確ではなくて、1950年代のコンピュータには今の意味でいうヒープとかスタックはなかったんですね。FORTRANで関数呼び出しができるようになった時にリターンスタックって言う、今のものとはちょっと違う、関数の戻り値を積んでおくためのスタックができました。初期のFORTRANってローカル変数がなかったんですよ。
ー グローバル変数ということですか？
Matz：はい、全部グローバル変数です。グローバル変数を置くところが今で言うヒープに当たるところで、リターンアドレスを積むのが今で言うスタックに当たるものなんですね。1960年代になって、ALGOLっていう言語ができた時点で、ローカル変数をスタックに置くことができるようになりました。前後関係はちょっと正確ではないかもしれませんが、恐らくほぼ同じ頃に動的にメモリを割り当てるという概念が生まれています。それより前は動的にメモリを割り当てるっていう概念がなくて、配列なら必要な配列をグローバル変数にゴッと割り当てる。で、動的に変化しそうだったら、最大値を予想して、その最大値分を割り当てるくらいのことしかできてなかったんですよ。なので確信はないんですが、順番としてはローカル変数があるスタックがあって、動的割り当てをするヒープが出るっていう順番なんだと思います。
ー それなら、スタック領域が今のヒープ領域の位置にあったほうが自然かと思いました。若い番号からメモリを使うのがなんとなく分かりやすいので、コンパイル時に領域サイズが決まるのが最初にあって、その次に歴史的に最初に登場したスタック領域。そして、そこにスタック領域がいると置き場所に困っちゃったので、反対の位置にヒープがある方が自然な気がします。
Matz：そうです。そういう考え方も多分あると思います。ですが、これも私の仮説に過ぎないのですが、スタック領域とヒープ領域のレイアウトってOSによって違うんです。今言った「ヒープは下からスタックは上から」というレイアウトが典型的なのはUNIX系のOSで、それが作られた時にはヒープとスタックの概念は今とそんなに変わらない状態で発明されてたんですね。彼らにとってみたら、グローバル変数の領域とヒープの領域は意味的に近かったので、そこを伸ばすのは自然だったんじゃないかなぁと思います。
ー 確かに。どっかで逆転したとかはありそうな…
Matz：そうですね。なので例えばアセンブラしかなかった時代、1番初期のスタティック領域しかないようなFORTRANしか想定してなかったOSの時代のメモリレイアウトって、今私たちが知るものとはだいぶ違っていたかもしれないということですね。
Rubyは最初から世界中の人に使ってもらう想定で作っていたのか？
ー Rubyを作り始めた時、最初から「世界中の人に使ってもらうこと」を目標として開発に取り組んでいたのでしょうか？また、今となっては世界中に開発者がいますが、開発者やその言語を使う人を増やしていく中で、周りの人を巻き込んでいくために工夫したことがあればお聞きしたいです。
Matz：Rubyを作った1番最初の動機は「自分のための言語」だったんです。自分が仕様からすべて決めることができる言語が欲しいというのが唯一の理由でした。
もともとプログラミング言語自体に関心がありましたが、プログラミング言語を作ることよりもデザインすることの方に興味があったんですね。でも、既存の言語って文法などが決まっているので、自分で決められない所が多いじゃないですか。それがしたければ自分で言語を作るしかない、という流れですね。自分のために作ってくれる人はいませんし。
なので、世界中の人に使ってもらうというのは最初は全く意図してなかったんです。最初の頃のRubyって、ドキュメントやコミットログとかが日本語で書いてあったんですよ。しかし、そうなるともちろん日本人しか分からないので、ある時から全て英語にしました。それが世界に広まった理由の1つだとは思います。また、海外の掲示板サイトでよその言語のニュースグループのスレみたいなところに行って「最近私がやってるRubyっていう言語でこういう風に書けるんですけど」みたいなこと宣伝しにいったりしましたね。それでRubyのユーザーがちょっと増えたとは思います。
開発については、私だいぶ迂闊なタイプでですね…よくバグが残ってたりすることがあります。すると、バグレポートを書いてくれる人がいるわけですね。中にはパッチを書いて「こういう風にパッチを書くとうちのマシンで動きました」みたいなことまで投げてくれる人がいてですね。そういうものを取り込んでいって、参加してきてくださる人がたくさん集まったんですよね。
クオリティの高い完成された言語がボーンとあるだけではなくて、ちょっと「自分も直してもっと良くできるんじゃない？」と思ってもらえたってのが良かった所なのかもしれません。「自分が参加できるオープンソース言語」みたいなポジションをRubyが持てたというのは、良かったことだと思います。
2ちゃんねるのひろゆきさんと間違われる？
ー この前Twitterで拝見させていただきまして。「久しぶりに2ちゃんねるのひろゆきさんと間違われた」っていうことを呟かれていたと思うんですけど、昔はよく間違われたんですか？
Matz：日本人の名前として「ひろゆき」の方が圧倒的に多いんですよね。かつ、人間っていうのは、ひらがなとかが並んでると「自分が知ってる単語の順番で読む」っていうクセがあるんですよ。「ケブンリッジ効果」ってよく言ってるんですけど。「ケブンリッジ」って書いてあるのに「ケンブリッジ」の方がよく知ってるから「ケンブリッジ」って読んでしまうやつですね。
ま、そういうことで「ひろゆき」の方が圧倒的に多いので、私のこと知らないと「まつもとひろゆき」と読む人が多いと思います。メールの宛先に「まつもとひろゆき様」とか書いてあったりして（笑）その度に「ゆきひろです」とか言わないといけないんですけど。その「ゆきひろ」と「ひろゆき」の間違いは割と頻繁に起きます。
ただ、西村博之(ひろゆき)さんと間違われたことは、実際にはほとんどないです。この間はすごく珍しいことでしたね。10年くらい前に、彼に実際に会ったことがあって。その時に彼が言ってたのは、「『この人Ruby作ったんだよ』って言われたことがある」って言ってたので…。お互いに間違われた事はあるんじゃないかと思います。
Rubyはなぜ引数の記述の際に( )を省略することができるのか
ーRubyのメソッド呼び出しは( )をつける書き方と( )を省略する書き方がありますが、なぜ( )を省略する書き方ができるのでしょうか？
Matz：2段階にわけて話したいと思います。まず引数がない時に( )を省略できるのはなぜかということを話します。あれが省略できるとアトリビュートアクセスとメソッド呼び出しを同一化できるようになります。例えば「hoge.value」とか書くと、hogeのアトリビュートを取り出しているように見えますよね。でも実際はあれはアクセサを呼んでいるんです。そうすると、メソッドでラップできるので、ただ単にデータを取り出してくるだけじゃなく、なにか計算をしたり、ログをとったりとかのフックを設定することができるんです。
次に、複数の引数がある時に( )が省略できるのはなぜかということなんですけど、これはRubyはスクリプト言語だったので、シェルっぽい書き方をしたかったため、省略できるようにしています。シェルって引数を並べる時にいちいち( )を書かないじゃないですか。
実際の仕様も2段階に分かれていて、すごーく古いバージョンのRubyは複数引数のときは( )が必須でした。リリース前の世に出る前のバージョンですけど。
関数呼び出しと関数ポインタ取り出しのトレードオフ
ーPythonやCだと関数呼び出しの( )が必須なおかげで、( )をなくすことで関数ポインタを取り出せるという性質があります。Rubyで同様の方法で関数ポインタを取ろうとしたら、関数呼び出しになってしまい、どうやって関数ポインタをとるんだろうなと思いました。生成されたオブジェクトに対して、.methodを呼び出してシンボルを渡すことで関数ポインタを取り出せたのですが、煩雑でした。この点は設計上のトレードオフに挙がったりしなかったんでしょうか？
Matz：Lisp1とLisp2という言語クラスがあります。Lispって名前がついてますが、別にLispに限った話じゃないです。何かって言うと、メソッドの名前空間とアトリビュートの名前空間が同じかどうかでLisp1とLisp2に分かれています。JavaScriptとかPythonみたいに、「Object.名前」ってやるとそのオブジェクトのメソッドオブジェクトが取り出せる言語を、その名前空間が1つしかないという意味でLisp1と呼びます。Rubyみたいに、変数とメソッド呼び出しの名前空間が違うような言語クラスのことをLisp2って言います。Lisp族だとSchemeっていう方言はLisp1なんですね。Common Lispとかそれよりも古いMacLISPとかEmacs LispとかはLisp2なんです。これはトレードオフの関係なんですが、最近の言語だとJavaScriptにしてもPythonにしてもLisp1になってます。さっき仰ってたように、関数型プログラミングをするときには関数が簡単に取り出せたほうが楽なので、Lisp1の方が相性がいいんですね。
セマンティックモデルとしては、例えばJavaScriptの場合だと、アトリビュートを取り出すとメソッドオブジェクトが返ってくるので、メソッドオブジェクトに( )を追加すると、メソッドが呼び出されるという2段階になるんですね。オブジェクト指向モデルにはLisp2の方が向いていると思っていて、実際にSmalltalkとか、Common Lisp Object Systemとかその前身のFlavorsとかはLisp2モデルを使っているんです。なので、オブジェクト指向言語として作ったRubyはLisp2を使うべきだと思って今のようになってます。また、符号圧縮という考え方もあります。つまり、メソッド呼び出しとメソッドを取り出すときの頻度を考えると、前者の方が圧倒的に高いです。そうすると、ナイーブな実装だと2ステップなところが1ステップになるというのはオブジェクト指向言語ではメリットだと感じてRubyはLisp2モデルを採用しています。
ですが、関数型プログラミングが最近結構流行ってて、Rubyも関数型プログラミングの影響を受けた機能を足すようになってきたので、「メソッドを取り出すのに『.method symbol』とかいうのはやりづらい」という指摘も結構あります。まだ決まってないんですけど、オブジェクトからメソッドオブジェクトを取り出す演算子みたいなものを提供するのはいいだろうねという話は今しています。
結婚相手にプログラマーもしくはIT業界の人を選ぶメリット・デメリットは？
ー 周りを見てみると、プログラマー同士とか、IT強い同士の結婚っていうのも業界だとちらほら見かけます。Matzさんが思う「結婚相手としてプログラマー、もしくはIT業界の人を選ぶメリット・デメリット」はどういうものだと思ってるのか、人生の先輩として伺いたいです。
Matz：プログラマーを選ぶことのメリットって「自分の仕事が分かってもらえる」というのは大きいですよね。プログラマーの仕事って、意外と業界の外の人には分かってもらえないことがあると思います。「ずっとコンピュータの前に座って何やってんの」とか「コンピュータの仕事って、人間は関係ないでしょ」みたいなことを思われがちなんですけれども。実際はそのコンピュータの前に座ってても、メールなりでコミュニケーションすることの方が多いわけですし、そういうことを分かってもらえるというのは、1つメリットじゃないかなと思います。また、よそのご夫婦を見ていると、夫婦でペアプログラミングとかしてるの見たりとかですね、夫婦で「Rubyの仕様はこうあるべきだ！」みたいな議論をした話を見たりとかしてるとですね…そういうのはちょっとうらやましいなぁという風に思うところもありますね。自分の「仕事」っていう大事な側面を理解してもらいやすいっていうのはプラスですし、それから一緒に開発だったりプログラミングだったりっていうようなことに一緒にすることができるというのは別のプラスでもありますね。
では、デメリットが何かというと、ソフトウェア開発って結構忙しい仕事である傾向が多いので、そうすると夫婦揃って忙しいということになりがちなのは、デメリットと言えばデメリットかもしれませんね。あと、プログラマーであろうがなかろうが、人間は互いに理解できない生き物なので、ちゃんと時間を取って、自分のことを伝えたり相手のことを理解しようとしたり、そのポーズを取ることが必要だとは思います。プログラマーだろうがなんだろうが関係ないですが…。
特に、日本の場合は男女の立場の違いみたいなものは、社会や文化に組み込まれてたりして、不均衡とか不公平とか起きがちなんですよね。それは相手がプログラマーであろうがなかろうがお互いがある程度納得感のあるように調整していかないといけないんじゃないかな、という風に思います。
出産の時に痛い思いをするのも女性だし、両方とも働いているのに女性だけに家事を押し付けがちなところもあったりとかですね。そういうことも考えるとですね、その辺の不均衡をどう解消するか、納得するか…まぁちょっと分からないですけれども、それも含めて相手がコンピュータに理解を示していようがいまいが話し合いをしないといけないっていうのは確かじゃないかな、という風に思います。
「旦那さんは好きなことばっかりして遊んでいるのに」と、プログラミングしてる時って遊んでるように見えるんですよね。楽しんでやってるからなんだけども。「自分の伴侶はコンピュータの前でずっと遊んでるのに、私だけなんか家事をして、子育てをして…」とか思われると、だいぶまずい。実際それで怒られたことあるんですけど（笑）
十分な話し合いと納得をしていただければ。納得を得る努力をしていただければという風に思います。私自身、30年間ずっと成功してきたわけではないので（笑）
非エンジニアが参加してみた感想
ギークな話題から結婚観まで、もりだくさんだった今回のMatzミーティング。どんな質問にも終始笑顔でていねいに答えて下さっているのが印象的でした。Matzさん、ありがとうございました！！
ZOZOテクノロジーズでは、エンジニアを募集中です。カジュアル面談Weekも開催中なので、気になる方は以下からご覧ください！