0037 号 巻頭言
「たのしい」Ruby再考
Rubyist Magazine 第 37 号をお届けする。
今号は、あの松田明さんをお迎えしての Rubyist Hotlinks 【第 29 回】 松田明さん 、 yhara さんによる、読むと南米のカンファレンスに参加したくなる あなたが南米のRubyカンファレンスに参加するべきn個の理由【前編】、 Jeweler を使って RubyGemsの作り方を解説する Jeweler で作る Rails 用 RubyGems パッケージとそのテストについて、 前々号のChef でサーバ管理を楽チンにしよう！ (第 1 回)に続いて Chef のレシピの書き方を解説する Chef でサーバ管理を楽チンにしよう！ (第 2 回)、 34 号に掲載された他言語からの訪問 【第 1 回】 Groovy (前編)の続きとして Groovy の特徴的な機能を紹介する 他言語からの訪問 【第 2 回】 Groovy (後編)、 前々号に引き続き、RubyKaigi の舞台裏を紹介する Making of RubyKaigi2011 第二回、 地域 Ruby 会議のレポートとしては RegionalRubyKaigi レポート (26) TokyuRuby 会議 04とRegionalRubyKaigi レポート (27) とちぎ Ruby 会議 04 となっている。
これだけ何度も巻頭言を書いていると同じ話を書いてしまいそうになる一方、以前書いたと思っていても書いていない話題が見つかることもある。
今回は「Ruby のたのしさ」について書く。
Ruby はたのしいプログラミング言語である、言い換えれば、Ruby は「たのしさ」を価値基準とするプログラミング言語である、という話はたびたび聞いたことがある人も多いだろう。 その初出は調べきれていないが、書籍の形で現存する最初期のものとしては、まつもとさんと石塚さんによる『オブジェクト指向スクリプト言語 Ruby』である。言うまでもなく、これは世界初の Ruby の書籍である。
■Ruby は「プログラミングを楽しくする言語」です
（略）
ちょっと大げさに表現すると、Ruby の究極の目的は、有限の人生においてプログラミングの楽しい部分にできるだけ集中できるように助けることです。
(『オブジェクト指向スクリプト言語 Ruby』p.21-22 より)
つまり Ruby は普及しはじめる以前から、「たのしい言語」としての価値基準を確立していた。 もちろん、さらに付け加えると、それを広める一定の役割を果たした本としては、『たのしい Ruby』がある、と著者の一人としては思いたいところである。
このように、バイブルとして広く読まれていた本から入門書に至るまで、たのしいたのしいと連呼していれば、否が応でも「Ruby はたのしいらしい」と思ってもらえるようになったのではないだろうか。他の言語でここまで「たのしい」を強調した言語は、あまり見たことがない。というのは控えめな表現で、正直に言えば私の観測範囲の中ではまったく見たことがない。
もちろん、言うまでもないことだが、Ruby がことさら「たのしい」というのは、Ruby 以外の言語がたのしくないからではない。むしろ、多かれ少なかれ、広く使われている言語であれば、どの言語もどこかしら「たのしさ」を持つものだ。 そのような言語と Ruby が異なるところは、Ruby が「たのしさ」を自身の価値として、評価のための指標として掲げている、という点にある。つまり、Ruby のたのしさというのは、何かの結果やたまたま持っている特徴ではなく、その本質的な設計方針なのだ。Ruby の「たのしさ」のすごみは、その一点に集約される。
世の中にはさまざまな言語がある。新しい言語は、それまでの言語と比べ、どこかしら優越していることを示さなければ、新しい利用者を増やすことが難しい。そのため、様々な利点をうたう必要があり、実際にそのようなお題目が、新たな言語が作られる根拠 (Rationale) として並べられる。
多くの場合、何かしら特徴的な機能を持つことをその言語の特徴として挙げられることが多いだろう。 また、新しいプラットフォームや環境への適応の高さをうたう場合もある。 たとえば最近であれば、マルチコア等の並列環境への適応の高さ、といったようなことだ。 つまり、新しいニーズに対し、これまでの言語よりもより優れた能力を持つ、という具合である。新しい言語の売りとしては、妥当なものだろう。
それ以外によく用いられる指標としては、速度や省メモリ、あるいは省電力などの具体的なパフォーマンスの良さがある。 もちろん単純な速度やメモリ消費量であれば、これまでの low-level の言語にかなわないことが多いため、正面から主張することは難しい。しかし、そこは似たような言語や、ライバル視している言語に対してのパフォーマンスと比較し、その言語によるプログラミングの容易さとセットで宣伝されたりする。
これらに対して、Ruby の指標の少なくとも一つは、「たのしさ」である。「Ruby は他の言語と比べ、よりたのしい」、ということを自らのアイデンティティとしている。 これは機能的な特徴やパフォーマンス的な特徴とはあまりにも違いすぎる。 率直に言って、ちょっと非常識に見える。
そもそも「たのしさ」というのは指標たりうるのだろうか。 新しいソフトウェア開発の現場で言語を選定する際、その言語の採用する根拠として「Ruby はたのしいので、本プロジェクトの開発言語として採用するべきです」というシーンを思い浮かべてほしい。どことなく違和感を感じずにいることは難しい。そもそも「Ruby は Python と比較してどのくらいたのしいのか」と言われれば回答に困りそうだ。
あるいは、他の言語が、その特徴として「Ruby よりもたのしい」と言い出すことを想像することも、正直に言って難しい。 そもそも、私たちが「Ruby のたのしさ」について語るとき、実際には定量的なメトリクスを持っていることをほとんど期待していないことが多いだろう。
これはつまり、「たのしさ」という指標は、競争から逃れる、という意味も持っている。
プログラミング言語は競争にさらされている。いろんな意味での「リソース」は、人的リソースも含めて、無尽蔵にあるわけではないし、ニーズも無限ではない。その競争の中で、何かの地位を確立するには、競争に耐えうるだけでの価値を明示しつつ、日々価値を高めなければいけないように思えてくる。
それに比べると、「たのしい言語」というのは、どこかしら競争を降りているように見える。
それで大丈夫なのか？ という心配はあるだろう。 たとえば Rails は「生産性」にフォーカスしていた。しかしながら、 その生産性は、たのしさと密接に結びつくそれであったように思う。
「たのしさ」という価値基準は、Ruby とそのエコシステムが持ちえた、得難いものである。 Ruby は決して未来永劫安泰であるわけではないはずだし、そのように思い込むのは大変危険でもある。 しかしながら、その「たのしさ」という指標をたいせつにしていけば、Rubyの独自性を保ち続け、 Ruby と Rubyist に対して価値あるものを与え続けていくための土台になるのではないかと思う。
Ruby を使う時には、そのコードの基準として、「たのしいかどうか?」「どうすればよりたのしくなるのだろうか?」ということを、日々のコードを書きつつ、考えていたい。
(るびま編集長 高橋征義)