2013年5月30日～6月1日の3日間、お台場にある東京国際交流館にてRubyKaigi 2013が開催されています。毎日1つある基調講演をそれぞれレポートします。

1日目の基調講演では、RubyのパパであるMatzこと、まつもとゆきひろさんが「Rubyのつくりかた」と題して話をしました。まつもとさんは今までのRuby会議すべてで基調講演をしており、いわば定番のキーノートと言えるかもしれません。

Ruby 以前

Rubyを作る前、まつもとさんとコンピューターの関わりについて、歴史をおって話しました。

1979 BASIC

まつもとさんが初めてプログラミング言語と触れあったのは1979年のことで、SHARP製のポケットコンピューターを買い、BASIC言語でのプログラミングでした。変数名がアルファベット1文字でしか宣言できず、26個の変数しか使えなかったそうです。今考えると大変そうですが、当時のまつもとさんは「そういうものだ」と疑問に思わず、プログラミングを楽しんでいました.

1980 PASCAL

高校時代の1980年、本屋さんでPASCAL入門に出会いました。BASICでプログラミングしていたときにあたりまえだと思っていたことがあたりまえではなく、「⁠処理に名前をつける」「⁠処理を再帰させる」「⁠データの構造をまとめる」「⁠変数のスコープをローカルにする」など、BASICより便利にプログラミングできることに驚き、感動しました。

ただし、PASCALのコンパイラは当時20万円以上しており、とても高価で買えなかったため、もっぱら本のプログラムを紙に書き写して楽しんでいました。

1982 LISP

1982年にはLISPに触れました。人工知能に使われているとのことだったが、ひととおりやってもどこが人工知能に関係するのかはあまりよくわからなかったそうです。 しかし早いうちにLISPに触れていたのは、その後Rubyに大きく影響を与えることになりました。

1983 OOP

雑誌、アスキーに半ページだけ載っていた記事でオブジェクト指向と出会ったのは1983年のことです。興味をもち色々調べてみようとしたものの、当時鳥取在住の高校生であったまつもとさんには、それ以上に情報を集めるすべが少なく、バックナンバーをまとめた雑誌でSmalltalk72というSmalltalkの情報をみつけたものの、古すぎる情報でプログラムが動かせなかったり、その情報の参考資料として載っていた本を借りて読んだものの、難解で理解できなかったなど、あまり望むような結果にはならなかったようです。

しかし、当時の時点では一見徒労に終わってしまったようなこういった苦労の積み重ねによって、今のRubyがあるのでしょう。

1984 Smalltalk

大学に入り、筑波に住んだ松本さんは1984年にSmalltalkに出会いました。高校のときにあんなに苦労して調べたSmalltalkの情報が簡単に手に入る筑波をとても都会だと感じたと話していました。

1988 C

1988年にC言語に出会い、どちらかというとプログラミング言語を調べるのが好きだったまつもとさんが、初めて腰を据えてプログラムを書くきっかけになりました。

Emacsに出会ったのもこの頃で、Emacsはレガシーとやや冗談めかして言いながらも、今も使い続けているそうです。

1989 CLOS

1989年には CLOS（Common Lisp Object System）というプログラミング言語に触れたまつもとさんでしたが、実際にはCLOSでプログラミングをしたことはないそうです。ただ、アイデアはその後のプログラミングの参考になったと言及していました。

1990 Cmail

Emacs用メールリーダーソフトのChain Mailのソースコードを改良して、作者へパッチを送ったところ「私はもう使っていないので好きにして良いです」と言われたため、まつもとさんがメンテナとして、ソフトを保守していくことにしました。

折しも、悪い意味での「チェーンメール」が流行していた頃だったため、ソフトの名前をCmailへ変更して運用していたそうです。

これがまつもとさんにとって初めてのオープンソースとなりました。1990年のことです。

1991 OOP C

仕事をはじめたまつもとさん、C言語でオブジェクト指向を使いたいと考え、候補にあがったのがC++やObjective-Cでした。しかし1991年当時のC++はまだ多重継承などが実装されていない状態で、まつもとさんが利用したいと考えている条件には合わず、またObjective-Cはコンパイラが入手できず、利用できませんでした。

そこで、まつもとさんは、C言語をオブジェクト指向プログラミングで利用できるようなライブラリを作成していきました。半年程度の納期のうち、はじめの4ヶ月くらいをライブラリ作成にあててしまい、残りの期間で依頼のものをつくったそうです。

ここで作成したライブラリは、その後一部がRubyの中にも取り込まれました。

1993 Ruby

このように様々なプログラミング言語、プログラムに触れたまつもとさんが1993年に作ったのがRubyでした。当初は一人で開発していたため、後に述べるようにモチベーションの維持が大変だったそうです。

プログラミング言語への傾倒

なぜ好きなのか

まつもとさんはプログラミング言語が好きだと言います。なぜでしょうか。

本来であれば、思考を表現するための方法とは、思考が主、表現が従という主従関係になるはずなのですが、表現方法というものが思考におよぼす主従関係の逆転した影響は無視できないようです。表現方法や見方を変えてみると、思考も変わるという不思議な体験が皆さんにも経験としてあるかもしれません。

プログラミング言語もまた、思考の表現手段の一つで「コンピューターにさせたい私の思考」を表現するのがプログラミング言語であるため、先程の例でたとえると、プログラマの思考はプログラミング言語に影響されます。つまり、プログラミング言語の適切な設計は、プログラマの思考をガイドすることにつながります。まつもとさんはそこに面白さを感じているようです。

例として、まつもとさんが中学～高校時代に出あったプログラミング言語BASICとPASCALを挙げました。PASCALにはある再帰という概念がBASICにはなく、そのため、当時BASICしかやっていなかったまつもとさんは当初、再帰というものを理解できなかったそうです。

言語設計

言語を設計するということは、思考を設計するということになります。

Ruby の良くないと思うところに改善をリクエストするのも言語設計の一部ではあるものの、8～9割のリクエストはRubyにとりこまれていないという現実もあるため、まずは自身で言語を作ってみたらどうかと提案されていました。

例えば、次のようなトピック

• オブジェクト指向
• 関数型言語
• 並列型言語
• ドメイン特化言語

を持つ言語だけではなく、

• ミニ言語
• トイ言語

のような、実用に達しないかもしれない小規模な言語でも十分楽しめるし訓練にもなるようです。

言語実装

言語実装も、プログラマにとっては楽しみの宝庫で「言語実装はコンピュータサイエンスの総合芸術」であり、「⁠プログラマとして退屈したことはない」と話します。

実際に実装してみた例として、次のものを挙げていました。

• 逆逆ポーランド記法：逆ポーランド記法 (1 1 +) => 2 の数値と記号を逆にして (+ 1 2) => 3 とすれば読みやすい。画期的発明だ！と思ったが、逆の逆ポーランド記法なので、実の所ただのポーランド記法のことだった。
• Classic：Eiffelを参考にクラス指向風のCを作った。Class風CなのでClassicという中二的な名前にしてしまった。黒歴史なので絶対に調べないでもらいたい。

Ruby のつくりかた

このような言語設計や言語実装、プログラミングの経験をふまえてRubyを作りはじめたため、Rubyには様々な言語の要素が含まれています。LISPからはS式以外、Smalltalkからは充実したクラスライブラリやmethod_missing、Perlからは文字列操作や正規表現、配列操作、Cからは演算子やUNIX文化を取り込み、

Ruby = Lisp + Smalltalk + Perl + C

と評していました。

開発の初期は次のように「必要なものを作るために必要なもの」が芋づる式に増えていき、'Hello World'を出力するのに半年かかるような状態で大変だったようです。

• 'Hello World'という文字列を作るためには、String クラスが必要である。
• String クラスの継承元が必要なので、Object クラスが必要である。

• そもそも、クラスという概念を扱うために、実装が必要である。

• やっとStringオブジェクトが完成したのでprintしよう。

• printはメソッド呼び出しなので、メソッド呼び出しを作らなければならない。

• メソッド呼び出しが完成したので画面に表示しよう。

• 画面に表示するためにはIOを考えなければならない。

• うまく動くようになったのだが、しばらく動作させているとプログラムが終了してしまう。メモリを解放していないせいなのでGCが必要だ。
• プログラムにリンクするだけで動作するGCがあるようだ。

• 実際にリンクさせてみるとうまく動作しないため、結局自分で実装しなければならない。

1993年に作りはじめたRubyは、このような苦労を経て、1994年12月に限られた人へ配布、1995年の12月に0.95版が公開されました。

自分用言語を作ろう

自分で言語設計をしてみよう

まつもとさんが言語設計を皆さんに推している理由は、言語を作るという行為が、その言語に必要なものを取捨選択するという練習になり、プログラマに必要な能力が養われるためだそうです。

APIやインターフェース、これらも広い意味での言語であるため、言語設計を練習しておくと、良いAPIやインターフェースの設計が上手になってきます。

まつもとさんは、もっと沢山の言語を、もっと沢山の人に作ってみてもらいたいと述べていました。

開発の秘訣

まつもとさんは新しいものを作るときの開発の秘訣として次の項目を挙げました。

• 全く新しいものを追求しない
• ひとつずつ進歩する
• 組合せる
• よく知っている(or 好きな)ものを使う
• 自分が使いたいものを作る
• 作品を愛する
• 長く続ける

自分に必要なものを、自分の手に馴染んだ道具で、焦らずじっくりと作っていくという自給自足がコツのようですね。 長い間多くの人に親しまれているRubyのようなプロダクトを生み出した人の秘訣なのでぜひ参考にしましょう。

情熱を絶やさない

次のような言葉を受けると、情熱が冷えてしまうことがあります。

• 「もう沢山の言語があるのに、まだ言語が要るのか？」
• 「どうせ広まらない」
• 「時間の無駄」

こういった言葉をかけるのは他の人だけではなく、自身の心が自身にそう訴えることもあります。実は、まつもとさんも諦めそうになったことがあるそうです。

ところで、釣りが好きな人に

• 「どうせ釣れない」
• 「釣ってもおいしく食べられない」

という言葉をかけるとどうなるでしょうか。そこで釣りをやめてしまうでしょうか。そうではなく

• 「釣れなくてもいいんだ」
• 「釣ろうとすることが楽しいんだ」

という答えが返ってくるかもしれませんね。釣った結果の魚を楽しむのではなく、釣りという行為自体を楽しんでいるので、結果にフォーカスした言葉では釣り人の情熱を冷ますことはできないのです。

同じように、まつもとさんは次のような考え方で情熱を維持したそうです。

• 「使われないのがどうした？」
• 「私は言語が好きだ」

作った言語を使う時の嬉しさではなく、言語を作る時の楽しさにに重きを置いたこの言葉は、私達がプログラミングをするときに、結果もさることながら、プログラミング自体を楽しむのに似ていますね。

他人の意見に左右されたり、評価を心配するのではなく、自身の本能に従って情熱を絶えず燃やし続け、雑多なアィディアをどんどん実装しようと述べていました。