0009 号 巻頭言

初稿：2005-09-06

言語と人間とこだわりと

Rubyist Magazine 第 9 号をお届けする。

今号は Ruby の初心者の方に捧げる「Ruby の歩き方」から始まり、 Rubyist Magazine 一周年記念企画として、 諸方面の方々からありがたい言葉をいただいた 「Rubyist Magazine へのたより」と、 これまたさまざまな方からいただいたものを読者のみなさまへ提供する 「プレゼント」の二つがある。 さらに、中田さんをお迎えした「Rubyist Hotlinks」、 XML による設定ファイルが嫌いな Rubyist にとって重要なフォーマットである YAML を解説する「プログラマーのための YAML 入門」、 CGIKit の解説では HTML オーサリングソフトの Nvu を使って HTML を作りながら CGIKit のアプリケーションを構築していく 「Nvu と CGIKit2 による Web アプリケーション開発」、 実は本誌では初の試みとなる書籍の紹介記事として、最近出版された「幸福の王子」本こと 『dRuby による分散・Web プログラミング』を紹介する 「書籍紹介」がある。 さらに連載陣には、 前回の Python と比べるとぐっとマイナーな CLU を紹介する 「Rubyist のための他言語探訪」、 RD を Ruby 用のドキュメント記述言語として利用するためのマークアップについて説明する 「RD でも書いてみようか」、 相変わらず悩みの尽きない文字コード変換ライブラリを比較・紹介する「標準添付ライブラリ紹介」、 いよいよ最終回ということで、COM について各言語での使い方などを比較しながら紹介する「Win32OLE 活用法」、 ついに Ruby 本体にマージされ、期待が高まる YARV について、 その命令セットを紹介する「YARV Maniacs」、 一周年にちなんで Ruby 1.6 にスポットライトをあてる「小アンケート企画『いまさらruby 1.6？』」、 そしてイベントレポートとして、先日行われた「第 5 回 Ruby 勉強会＠関西レポート」と「Lightweight Language Day and Night レポート」、そしてそして「Ruby 関連情報」に「Ruby 関連イベント」と、 一周年にふさわしい充実した内容となっている。

毎度のこととはいえ、 こうやって概要を書くだけでちょっと疲れてくるようなボリュームではあるが、 興味のあるところからごゆっくり読んでいただければ幸いである。

さて、Rubyist Magazine と日本 Ruby の会が一周年ということで、 今後の日本 Ruby の会と Rubyist Magazine の活動を考えてみたい。 などと思っていたのだが、具体的な活動を考えるよりも前に、 先日小波さんが日本 Ruby の会 ML に送ったメールについて触れ、 そもそも日本 Ruby の会として活動をする目的について考えてみる。

小波さんからのメールの内容はこちらの通り ([ruby:929] 会則に「普及」はいらない？) である。 勝手に一言で要約させていただくと、 会則の中で「普及」について触れるべきではないか、 という意見である。

こちらについては、創刊号の巻頭言でも触れた通り、日本 Ruby の会では積極的に普及をうたうことはないつもりである。 がしかし、これは一年前に決めたことでもあり、 もう一度原点に振り返り、その意味をさらに考えを深めてみるにはよい機会である。 以下ではこれについて考えていこう。

まず、このような普及を支持する考え方はめずらしくない、 いや、むしろ当然のものであることは踏まえておきたい。 例えば日本 PHP ユーザ会でも、発足時のプレスリリースに 「PHP の普及と発展を目指し、以下の活動を行います。」と 書いている (日本 PHP ユーザ会記者会見資料)。 また、PyJUG こと日本 Python ユーザ会も 「日本における Python の普及／発展を目論む非営利団体」と自己規定している (PyJUG について)。 また、国内のユーザ会の中でもしっかりとした組織運営がなされているという話をよく聞く日本 PostgreSQL ユーザ会も、 会の目的として 「本会は日本における PostgreSQL の普及と発展を主な目的とします。」 としている (日本 PostgreSQL ユーザ会)。 このように、そもそもユーザ会のような団体は普及を目的とする ものなのである (これとは異なる例として、*.pm のような地域コミュニティについては交流がメインになる場合もあり、この場合には積極的な普及はうたわないかもしれないが、さすがに Ruby の会は交流を目的とした地域コミュニティとは言いがたい)。

加えて、小波さんのメールにある、 「Ruby を初心者に教育したり，あるいは勉強会などのイベントのお世話をする」ということは、とてもよいことだと思う。 そしてそのようなことを継続に行われていて、しかも一定の成果をあげているということは素晴らしいことである。

しかし、このようなことは理解しつつも、 では「Ruby の普及」を会として積極的に行うべきか？　と問われると、 それは違うような気がしてならない。

なぜだろうか。何が違うのだろうか。

小波さんの活動により、Ruby が幾分か普及したのかもしれない。 しかし、そのことが素晴らしいのではない。 小波さんに Ruby を教わった方々が、Ruby を使うことにより、 (おそらく) 今までできなかったことができるようになったり、 今までもできなくはなかったことがさらに簡単にできるようになったり、 今までとは違うものの見方ができるようになったりしたことこそが、 素晴らしいことなのである。

このことは他の言語に置き換えてみればわかる。 もしも Ruby ではなく Perl などの他のスクリプト言語であれば、 教わった方々が同じようなことができるようになったとしても、 それは Ruby を使ったときより素晴らしくなかったのだろうか。 そんなことはないだろう。 どの言語がより望ましいかは、 それを習うものがその時点または将来にその言語を使って自身にとってどれだけ役に立つのか、 といったことにより評価される。 それは言語自体に備わった性質というより、使い手の性質によるものだ。 であれば、 Ruby がそれ以外かは使い手によって考慮するべきであり、 何の留保もなく「Ruby を普及させるべき」とは言えないことになる。

さらに教える側の都合や思惑というものがある。 ある言語は別の言語よりも与えられた前提の前では教えやすいといったことや、 応用範囲の向き不向きといったことや、 あるいはたまたまあるライブラリの有無といった条件があったりする。 そのような都合により、教える言語が決まり、 結果としてその言語を普及させる、といった活動を行うことになる。

この順序は逆ではない。逆であってはいけない。 使う側の人間よりも、使われる言語を重視するべきではない。 Ruby を普及させるための活動は、やはりあくまで手段であるべきで、 目標として掲げることではない、と思ってしまう。 そして、このようなことを踏まえた上で、 はじめて Ruby を普及させる活動を高く評価できるようになる、 と考えている。

ところで、上記のような言語よりも使う人間を優先する考え方は、相対的に Ruby を低くみることにつながるのではないだろうか。 ある意味ではその通りかとも思うが、Ruby についてはそうとも限らない。

Ruby という言語にはいくつものこだわりが込められているのだが、 その一つに「名前」に対するこだわりがある。 本誌の記念すべき Rubyist Hotlinks 第一回でもまつもとさんより好きな言葉として挙げられた 「名前重要」という言葉は、Ruby 内外でも知られるようになりつつある。 広く使われるようになったのはおそらく去年辺りからではないかと思うが、すでに 2000 年の時点でまつもとさんによる用例 ([ruby-dev:11236]) がある。

また、1999 年に出版されたバイブルこと『オブジェクト指向スクリプト言語 Ruby』でも、 巻末付録の Ruby 用語集には「名前重要」ではないが「名前」という項目があり、 「しかし、名前には不思議な力があるので、悩むだけの価値はある。」と書かれている。

しかしながら、プログラミング言語の仕様や実装という側面から見た場合には、 メソッドなどにどのような名前を使おうと、さほど違いはない。 Ruby のパーサからしてみれば、 予約語と重複しない限り単に識別子として区別されるだけであるし、 評価器や VM から見れば、メソッド ID でしか扱われていない場合も多い。 純粋な言語自身としては、どのような名前であれ、 スコープの中で区別さえなされていればどうでもよいことである。

名前は誰にとって重要なのか。もちろん、言語を使う人間にとって、である。 それを殊更に大きく取り上げたがる Ruby という言語は、 明らかにそれを使う人間の方を向いている言語である。

別の Ruby の特徴を挙げてみよう。 最近 Ruby が 内部 DSL のホスト言語として取り上げられることがある (Martin Fowler’s Bliki in Japanese - 言語ワークベンチ：ドメイン特化言語のキラーアプリ？) が、 これを快適にしている文法上の理由の一つとして、 メソッド名とその引数との間に使われる「カッコ」が省略可能である、 という点が挙げられる。つまり、「october(14, 2005)」が「october 14, 2005」と書ける、という点だ。

しかし、この特徴は良いことばかりではない。 この実現のために Ruby の文法は空白の扱いがややこしくなっている。 そのため、若干複雑な文法やルールが必要となり、 おかげで『「コンパイラ・スクリプトエンジン」相談室 6』スレッドで叩かれたりもしているわけだが、しかしこれも「ユーザの使い勝手」という、 なんとも人間的な要素を最大限考慮するために起きたことに他ならない。

これらの特徴から言えることは、言語を使う人間を重視するというスタンスと、 Ruby を重視するというスタンスとは、何の齟齬もなく並立する、ということだ。 むしろ、人間を重視するからこそ、 Ruby のような言語に惹かれてしまうのかもしれない。 Ruby は、そのような性格を持つ言語なのである。

Ruby on Rails の作者 DHH は、最近自身の blog で「Can software have opinions?」 というエントリを書いている。また、 O’reilly のサイトに掲載されたインタビュー (O’Reilly Network: Ruby on Rails: An Interview with David Heinemeier Hansson) でも、 Rails のことを「Opinionated Software」と述べている。 DHH は特に触れていないようだが、Opinionated Software が Ruby で書かれているのは偶然ではない。 なぜなら、Ruby もまた、まつもとゆきひろというプログラミング言語デザイナーが、 自身のこだわりを注ぎ込んだ「Opinionated Language」であるからだ。 そしておそらく日本 Ruby の会が、 他のユーザ会などとは少々異なる「Opinionated Group」を目指してしまうのも、また偶然ではないのだろう。

(るびま編集長　高橋征義)