Ruby チュートリアル (Ruby 1.8.6 編)

2007.11/22-12/21, 2008.3/7, 2008.12/24 (鈴)

Ruby がはじめて広く公開されたのは,1995 年 (平成7年) 12 月 21 日, NetNews の fj.comp.oops,fj.lang.misc に Yukihiro Matsumoto 氏 (当時 Toyota Caelum Inc., Nagoya, Japan 所属) が "ruby 0.95 - the object-oriented script language" と題する記事 (Message-ID: <x3ybs6llre.fsf@ix-02.nagoya.caelum.co.jp>) を投稿したのが最初である。 今日いわゆる Ruby コミュニティの中心となっているメーリングリストの前身もこのとき立ち上げられた。 記事中,Ruby 紹介の最初の2段落の内容を下記に示す。

rubyは「手軽なオブジェクト指向」をテーマにしたオブジェクト指
向スクリプト言語インタプリタです.一応,perl程度の仕事は大体
こなせる程度の機能は持っています.

特徴は

  + Alogolっぽい文法(ちょっと独特)
  + 変数に型は無い
  + 変数名でスコープが分かる($varは大域変数,Varは定数,var
    はローカル変数,@varはインスタンス変数)
  + 普通のオブジェクト指向機能(クラス,メソッドコールなど)
  + 珍しいオブジェクト指向機能(Mixin, 特異メソッドなど)
  + 演算子オーバーロード
  + 例外処理機能
  + イテレータとクロージャ
  + ガーベージコレクタ
  + ダイナミックローディング (アーキテクチャによる)
  + 簡易Tkインタフェースもある
  + ドキュメントが貧弱(特徴じゃないぞ)

などがあります.後,C言語による拡張も容易にできるようになっ
ています.

現在,Ruby は当時の「perl程度の仕事」を越えた分野にも利用されているが*1, 上記に挙げられた特徴の記述は,欠点も含めて概ね今も妥当である*2,。 ここではこの Ruby という言語について学習しよう。 対象とする処理系は ruby 1.8.6, およびその Java 上の互換実装である jruby 1.1.6 とする。 ruby 1.8.6 はおそらく現時点 (2008年 12月) で実社会に最も普及している実装といってよいだろう。 より良い性能と言語仕様をもった,より新しい Ruby 処理系については後日,別の稿で取り上げる。

*1: 1995 年当時,適度に強力で扱いやすい手頃なスクリプト言語処理系が ほかによく知られていなかったことから, Unix 界では Perl が流行していました。 C 言語による開発に比べればはるかに手軽であったため, Unix の人々は,Perl の本来の守備範囲であった ちょっとしたテキスト処理やシステム管理を越えた分野への Perl の応用を試みていました。 新進の Ruby が Perl を強く意識したことは自然な成り行きでした。

しかし, もともと汎用言語ではなく小さな目的のための専用言語として 設計されていた Perl の仕様は,そうした試みに不適合をおこし始めていました。 例えば,少し大きくなったコードをサブルーチンに分割しようとしたとき, 言語自体は仮引数の宣言をサポートせず,わざわざ引数結合の文が必要でした。 サブルーチンに複数の配列を渡そうとしたり,配列を入れ子にしようとしたとき, 素直に書いたのでは自動的に配列どうしが連結されてしまいました。 Perl は狭い用途に特殊化しているきらいがありました。
(当時の Perl のキャッチフレーズに「簡単なことは簡単に」 "make the easy jobs easy" というものがありました。 心地よく響くこの言葉は,事実としては,Perl の設計者にとって簡単であるべき仕事を Perl は簡単にこなせるように設計されている,ということにすぎませんでした。 冷静に考えれば,この言明は他のすべての高水準言語に適用可能です。 「高水準言語」の定義といってもよいかもしれません。ある意味,宣伝の勝利でした。 残念なのは,サブルーチンや入れ子のデータ構造をつくることが, 簡単であるべきことに含まれていない模様だったことでした)

後者,配列連結の問題は 1994 年 10 月以来の Perl 5 で採用された「リファレンス」で一応の解決をみました。 しかし,そもそも日常的なデータ処理に対し「リファレンス」「デリファレンス」 のようなことをプログラミング技法として意識的に操作することを強いたのは事実上 Perl だけでした。 今日使われている多くの言語 (Ruby,JavaScript, Java を含む) では,プログラミングの第1日目から無意識に使いこなせるようなことが Perl では高等技法でした ("Advanced Perl Programming" 邦訳「実用 Perl プログラミング」の第1章はすべて 「リファレンス」の説明に費やされています)。 普通の言語ならば簡単に済むはずのことも, Perl では言語のデフォルトが特定用途向けに特殊化しているため, しばしば 余分な手間 がかかりました。 この Perl の弱点は今日でも基本的には解消されていません。 それでも全体としては C で書くよりはずっと楽でしたが, 人々のあいだには潜在的な不満が蓄積されていた,と見るのが妥当でしょう。

そんな状況で現れた Ruby は,Perl の守備範囲では Perl とほぼ互角に使えながら,他の 分野でもなるべく不自然な記述を強いないように設計された言語でした。 この戦略は成功をおさめ,Perl の守備範囲の半ば, さらには無理をしながらも Perl が使われていた,または使われようと していた領域,そしてさらに当初想像されなかったような応用分野にまで Ruby の普及が進み,現在に至ります。 しかし,その一方,空白文字の有無に微妙に依存する不明瞭な構文規則から, よく考えればナンセンスに近い宣伝文句に至るまで, 心情的に同情できる面もあるにせよ当時の流行であった Perl の負の側面に多かれ少なかれ同化してしまったこともまた否めない事実でした。 今はようやく,かつての Perl の影から徐々に抜け出しつつあるといえるでしょう。
ちなみに「デリファレンス」dereference の接頭辞 de- は,この語では下降ないし強意を表します。 reference 「参照」に対して dereference は参照先に到達すべく「参照する」「参照し下す」ことを意味します。 従来の技術用語でいえば「間接参照」という言葉が該当します。 あえて新語を作るならば「参照解決」が妥当かもしれません。 最近,あちこちで「逆参照」「参照はがし」等の訳語を見かけますが, これらは接頭辞の他の意味から言語感覚を欠いて作り出された誤訳といってよいでしょう。
*2: ただし,ここで「Algol っぽい文法」とは,文括弧に begin end を使うという程度の類似性を指すととらえるのが妥当でしょう。 例えば,Ruby は Algol 系言語だ,とまでいうのは,おそらく言い過ぎです (参照: 1.6 節 注釈)。 とりあえずフルセットの 実際に動かせる Algol 60 を Python 上に用意しました。もしも望むならば,君自身の目と手ですぐ確かめることができます。

参考文献 (新刊順)

例題の変数名などの一部は E. Rodda: "Deltora Quest" series, Scholastic, 2000-2002 による。 この物語では魔法の七つの宝石の一つとして ruby が活躍する。


Copyright © 2007, 2008 OKI Software Co., Ltd.