0049 号 巻頭言
Ruby 3.0とSoft Typing
Rubyist Magazine 第 49 号をお届けする。
今号は、遅ればせながらの後編である Rubyist インタビュー特別編 小崎資広さん 後編、 RubyKaigi 2014での西山さんの発表を元に寄稿していただいた Ruby 考古学 消された機能編、 所さんによるバンガロールでの meetup やカンファレンスの体験談を紹介する 「インドのシリコンバレー」バンガロールの IT コミュニティ事情、 さらに、地域Ruby会議のレポートとしてRegionalRubyKaigi レポート (45) 大江戸 Ruby 会議 04、 島田さん角谷さん翻訳本を紹介する 書籍紹介『Rubyのしくみ Ruby Under a Microscope』とそのプレゼント企画の 0049 号 読者プレゼントという内容となった。
RubyKaigi 2014 のまつもとさんの講演にて、ついに Ruby 3.0 の構想が発表された。
Ruby 2.0 については、初回の RubyConf 2001 でもその話題があったくらいに、 Ruby 界においては Ruby 2.0 というのは前世紀から語られてきたものである。 ある意味、「Ruby の未来」とは 2.0 のことだった。 それが現在のこととなり、そして過去のこととなりつつある今、 次の「Ruby の未来」として 3.0 という目標が、具体的に語られるようになった。 そのことだけでも、古参 Rubyist としてはとても感慨深いものがある。
もっとも、そのような懐かしい思いを浮かべるのは少数派だろう。 実際に RubyKaigi に参加し、まつもとさんの講演を聞かれた方々、 あるいは動画 (http://rubykaigi.org/2014/presentation/S-YukihiroMatzMatsumoto ) で講演を閲覧された方々は、 Ruby 3.0 として語られた構想についてどのような感想を持たれたのだろうか。
私はといえば、とても興味深いものだと感じた。
2.0 のことを思い出してみよう。Ruby 2.0 の目玉として挙げられていたものは、VM の導入、 多言語化 (M17N) 対応、GC の改良、ネイティブスレッド対応といった点だった (M17N 対応は当初 1.8 で導入する予定だったが、間に合わずに 2.0 へと 持ち越されることとなった。また、2001 年当時は 1.9 は 2.0 に向けての 開発版になるだろうと思われていた)。
2.0 の開発目標について今から振り返ると、当時から特に意外なものではないというか、 言語処理系が正常進化を遂げれば起きるだろう (しかしながら容易とはいえないかもしれない) 未来を狙ったものだったと言えるだろう。 とはいえ、その中でも M17N はやや変わったポジションにあった。
2.0 の開発が始まった当時、M17N 対応の大きな課題は Unicode 対応だった。 るびまでも成瀬さんが以前書かれた力作、「Ruby M17N の設計と実装」にある通り、 実際のところ、Ruby 以外の多くの言語処理系にとっては、 いろんな意味での Unicode 対応と M17N 対応がほぼほぼイコールであることも少なくなかった。
しかしながら、Ruby ではその方向性は排除された。CSI(CodeSet Independent) 方式で行くことが決定されたためである。 もっとも、これは荒唐無稽なものではなかった。 Ruby では日本語周りの複数の文字コードに対応していたとはいえ、 それでもこれはチャレンジングな方針であった。 あるいは途中でやはり Unicode ベースになるのかも、という可能性もなかったとはいえない。
実際に Ruby 2.x シリーズの路線がほぼ fix した現在の状況としては、 (マジックコメントを書かない) デフォルトの文字コードとしては UTF-8 になりつつも、 Unicode への変換を強要せずに、バイト列も Unicode 以外の レガシーな文字コードも扱える、という結果になった。 UTF-8 以外も普通に使えるけれど、UTF-8 を使うともろもろ便利、という状況は、 多様性を持ちつつも opinionated であるという Ruby の文化とよく調和しているように見える。 結論としては、この方向性は間違っていなかった、と言えるだろう。 少なくとも、CSI 方式による実用的な言語は作れる、ということを示すことができた。
そして Ruby 3.0、そのうちの RubyKaigi で触れられた Soft Typing である。
最近の他言語を見るにつけ、現在は静的型づけ言語が盛り返しつつあるように思える。 Python も型アノテーションが提案され (http://www.infoq.com/jp/news/2014/09/python-type-annotation-proposal )、 また JavaScript の世界でも、TypeScript を筆頭に静的型づけを持った AltJS が広まりつつある。 型宣言のない言語に対する忌避感は強い。
Ruby に対しても何かしらオプショナルな型づけを導入することが期待されており、 3.0 でもそのような方向に進化するのを期待する人も多かっただろう。 事実、Rubinius は 3.0 で Gradual typing の導入を検討している (http://rubini.us/2014/11/14/rubinius-3-0-part-5-the-language/ )。
しかしながら、まつもとさんは Ruby 3.0 において、静的型付けの導入については露骨に拒否しようとしている。 その理由は様々あるだろうが、2.0 で CSI 方式を選択したことを思い起こさざるをえない。
RubyKaigi で挙げられてた理由としては、Duck Typing の文化との相性の悪さがあった。 しかしながら、それよりもそもそもの理由としては、「わざわざ書きたくない」といった、 プログラマの三大美徳の一つとも言われる「怠惰」によるものに思われてならない。 これだけ計算資源が利用できる現在、エディタなり IDE なりが十分に賢ければ、 人間がわざわざ明示的に書かなくてもよろしくやってくれればいいのに、 そうすればソースの見た目もスッキリするし…… といったような極めて都合の良い感覚である。 確かに型を書かなくても問題なく動くし、問題なくコードが書ける (それをサポートする都合のよい機能が利用できる) のであれば、書く理由はないし、書かれていない方がシンプルである。 が、それが容易に実現できるのであればそうなっているわけで、 そのような都合のよい言語環境が実現できるかどうかは今のところ定かではない。
平凡な感覚では、そんなに頑張らなくても素直に型ヒントくらい書けるようにすればいいのに、と思われるかもしれない。私自身もそう感じなくもない。 それはそうなのだけれど、そういう無難な方向には流れない、というのはいかにも Ruby というか、 まつもとさんらしい判断だと思う。
もっとも、そのようなわざわざ孤立を恐れず独自の路線を歩むことを選ぶ言語設計者は一人ではない。 先日日本で開催された Go Conference 2014 Autumn では、Rob Pike 氏による基調講演にて、 様々な言語が 1 つの大きな言語に収束しているように見えるが、 Go はその流れに与しない、という発言があったそうだ (http://gihyo.jp/news/report/01/GoCon2014Autumn/0001 )。 動的言語にも静的型付け的な機能を追加しようというのも「1 つの大きな言語」への志向の現れだろう。 そして Ruby もまた、Go とは方向性は異なるが、「1 つの大きな言語」ではない特徴を持った言語を生み出すことに可能性を見出そうとしているのではないか。
付け加えて述べるならば、Ruby の場合、その言語開発はボランタリーな開発者コミュニティによるものであり、 それを全面的に支援する大きな企業や法人があるわけではない。 そのため、何かしら開発者が自発的に参加したくなる、技術的に面白い課題が必要となる。 オプショナルな型に頼らない、動的型付けによる言語の仕組みを作り、それを活用する、 という方向性は、開発者を惹きつける技術的課題としても興味深いと言えるかもしれない。
コミッターではないけれど、Ruby の発展をずっと見てきた私としては、 なんかまた面白そうなネタを見つけてきたなあと思いつつ、 Soft Typing がどうなるのか、今後も興味深く注目していきたい。
(るびま編集長 高橋征義)