2016年9月8日から10日まで、国立京都国際会館にて「RubyKaigi 2016」が開催されました。基調講演の模様をレポートします。

RubyKaigi 2015に続き、2016も初日の基調講演はまつもとゆきひろさんです。

Ruby3ではパフォーマンス、並列実行、型の3つが焦点になっています。RubyKaigi 2016ではパフォーマンスについては卜部さん、並列実行については笹田さんからの講演があります。そこで型について話そうと思うと述べ、「⁠Ruby3 Typing」という題で、Ruby3における型についての構想を語りました。

Ruby3は型の先駆けになっていたい

2010年代に登場した多くの言語は静的型付け言語です。Rubyは静的型付けができず、Rubyが死んだと言われる理由として「型がないことが挙げられている」とまつもとさんは言います。一方で、Rubyに安易に型を追加するべきではないと考えているそうです。

技術は振り子のように動く

Smalltalkのころは動的型付けが当たり前でしたが、Javaが出ることで静的型付けが当たり前、と変化しました。その後JavaからRuby、JavaScriptというように、再び動的型付けが当たり前になっていきました。そして今、またRubyやJavaScriptからSwift、Goのように静的型付けへと振り子のように動いています。Rubyに静的型付けを安直に追加してしまうと、また逆に振れたときに取り残されてしまうだろうとまつもとさんは考えているそうです。そこで、SwiftやGoの次、未来の型について考えて、Ruby3は型の先駆けになっていたいと述べます。

Rubyにおける型とはダック・タイピングの「ダック」

Rubyにおける型とはダック・タイピングの「ダック」である、とまつもとさんは言います。ダック・タイピングとは「アヒルのように鳴き、アヒルのように動けば、それが実際には機械であろうとも、内部構造を気にすることなくアヒルであるかのように扱うことができるはずだ」という理念のことです。この「ダック」という期待される振る舞いこそが、Rubyにおける型であるとまつもとさんは述べます。例えば、RubyのStringIOはIOのサブクラスではありませんが、IOと同じくwriteメソッドを持つため、IOと同じように扱うことができます。

多くの静的型付け言語では継承やインターフェースを実装していることを明示する必要があります。これをNominal Subtypingと呼びます。Nominal Subtypingの場合、前もって宣言されていなければ期待される振る舞いを持っていてもコンパイル時にエラーになってしまいます。先述したように動的型付けであればダック・タイピングによってエラーにならず実行できるため、動的型付けは静的型付けと比べ未来に対して開けているとまつもとさんは主張します。

一方で、動的型付けはいいことだらけでもありません。欠点があるため、昨今は静的型付け言語に勢いがあります。最大の問題は、実行してみないとエラーがあることがわからない点です。実行前に基本的な整合性についてチェックができれば、より早くバグに気づくことができます。エラーメッセージもわかりにくいことが多いです。また、テスト忘れなどによってカバレッジが不足している場合には型エラーがあることに気付けない場合もありえます。さらに、型にはドキュメントの側面もあるためコメントで型情報を書いている場合もあります。

Nominal Subtypingに対して、Structural Subtypingという型の派生方式があります。例としては Go言語のインターフェースが挙げられます。これは、型としてインターフェースを定義しつつ、その実装を満たしていることを宣言する必要はありません。このためダック・タイピングと静的型付けの両方のメリットを享受できます。

一方、そもそも型を書きたくないとまつもとさんは強く主張します。

型を書きたくない理由

プログラムを書いているときに、無駄だと思うものは誰も書きたくありません。Rubyは生まれた時から動的型付け言語で、型指定が無くてもこれまで動いているため、型指定はむしろ積極的に外すべきだとまつもとさんは主張します。また、型定義をする必要がある場合、型に名前を付ける必要があります。コンピュータサイエンスにおいて名前付けは最も困難なものの1つとして挙げられますが、名前を付けないで済めば具体化するコストを下げることができます。

そこで、Structural Subtypingに型推論を足すことができないだろうか、とまつもとさんは提案します。

振る舞いの推論

コードからGo言語のインターフェース情報のようなものを自動生成することができれば、型を書かずに済むのではないかとまつもとさんは言います。この手法だと型について100%担保することは難しいかもしれませんが、現在のRubyでこういったチェックは一切行われていないため、80%くらいでもないよりはよくなるはずだと考えているそうです。

型チェックを行う際に、期待される振る舞いに矛盾があることで型エラーのいくつかは調べられるはずだ、とまつもとさんは述べます。例えば、aという変数に対してgsubとsliceとmapを呼び出している際に、これらすべてを持つクラスがなさそうなのでエラーにする、というようなことができそうです。

より詳細な振る舞いの情報を集めるためには、静的解析だけではなく実行時情報も使えそうだと言います。gemを公開する際に、テストを書いているはずなのでそのテストから型情報を集めて型のデータベースを作ることができるのではないかと述べます。これによって、より正確な情報を集めることができるため、エディタのサポートなど賢い開発環境を作ることができそうです。

Rubyを作り続ける理由

ここまでの提案はまだ構想段階であり、実際に動くわけではありませんが、重要なメッセージとして「みんなのことを考えている」ということが言いたいとまつもとさんは述べます。

Rubyには、動的型付けなのでエラーに気づくのが遅いという欠点があります。テストがあれば大丈夫と擁護するような優しいコミュニティですが、言語仕様としても「より楽しくプログラミングできるように」支援したいと考えているそうです。もし動的型付けが楽しさを阻害するようなら直したいし、静的型付けが阻害するようなら入れたくはないと述べ、今回の提案も開発時の体験をよくするアイデアの一つであると、よりよいプログラミング体験を提供できるよう気にかけていることを強調します。

達成が困難そうな目標を設定し、コミュニティに発破を掛けることがRubyのコミュニティリーダーであるまつもとさんの役割だと考えているそうです。パフォーマンス、並列実行、型の3つが焦点になっているRuby3ですが、これを2020年の東京オリンピックまでに成し遂げたいと目標を語りました。

OSSコミュニティは止まっていると寂れてしまうため、前に進み続ける必要がありますが、そのためにやれることはなんでもやる、とまつもとさんは言います。Rubyを作った理由も、作り続けている理由も、これから新しいRubyを作る理由も、すべてはみんなに喜びを届けるためであると述べ、「⁠ハッピーハッキング」の言葉で講演を締めくくりました。