RubyKaigi 2016が始まりました!スポンサーであるグッドパッチもエンジニア数名で京都に来ています。
早速、今朝発表されたRubyの父Matzによる基調講演のレポートをお送りいたします。

Ruby3の柱

東京オリンピックの年にリリースすることを目指して開発されているRuby3には大きく3つの柱があります。

  • 型(Typing)
  • パフォーマンス(Performance)
  • 並列処理(Concurrency)

今回の基調講演は、この中のひとつ「型」についての話です。

プログラミング言語の変遷

まずはじめに、プログラミング言語の「型」という側面についての振り返りがありました。

プログラミング言語にも時代によって流行りがあり、それは振り子のように繰り返されています。
かつては動的言語のSmalltalkやLispがあり、次に静的言語のJavaが流行し、JavaScriptやRubyのような動的言語が流行り、現在はGoやSwiftなどの静的言語が注目を集めています。

このような変遷を辿り、2010年代に出てきた新しい言語には静的型付け言語が多く、Rubyのような言語は「死んだ」とまで言われることもあります。
しかしMatzによると、このような流れは振り子のように繰り返されているので安易にRubyに静的型付けを導入するのではなく、Rubyにとっての型というものについて真剣に考えて導入していきたい、ということでした。

「型」とは?

そもそも「型」とはなんでしょうか。血液型のように共通の性質を集めたもののことでしょうか?

Rubyにはダックタイピングと呼ばれる考え方があり、Rubyプログラマはこの考え方に沿ってプログラミングしています。
Matzの話ではこれこそがRubyの型であるということでした。

ダックタイピング

「アヒルのように鳴き、アヒルのように歩くならそれはアヒルである」という考え方があり、これがダックタイピングです。
プログラミング的に言い換えると、「クラスや継承などは関係なく、アヒルを演じることができるオブジェクトであればそれはアヒルである」という、つまりはオブジェクトの振る舞いにのみ注目する考え方です。

ダックタイピングは非常に柔軟性が高く、Rubyにおけるプログラミングの高い生産性の元にもなっています。
柔軟性が高く振る舞いのみを考えればよいダックタイピングは、プログラマは脳の負担を減らす点でとても優れています。

静的型付けを行うとダックタイピングはできないため、このような柔軟性は損なわれてしまいます。

ダックタイピングにおける「アヒル」は静的な型ではありません。クラスでもありません。ただの「期待される振る舞い」です。
プログラミングにおいてクラスやインターフェイスの型指定も実はこの「期待」の近似でしかなく、実物はプログラマの頭の中にしかありません。

静的型付け言語は、近似をすることによって静的な型付けを手に入れるかわりに柔軟性を失っていると言えます。

DRY

プログラミングにおいてDon’t Repeat Yourself (DRY)という重要な原則があります。その名の通り「同じことを繰り返し書くな」という原則です。
さらに噛み砕くと「書かなくてよいものは書きたくない」というプログラマの欲求につながります。

「型を書く」ということはそもそもがこの欲求に反することであり、楽しくプログラムを書けることを重視しているRubyでは導入しがたいことです。

この観点でみると型を書かなくて良い現在のRubyは最高です。

動的型付けの欠点

動的型付け言語でダックタイピングなRubyは上述のようにプログラマの負担を減らし、楽しくプログラミングするという点では素晴らしいです。
しかし、動的型付けには欠点もあり、それが近年静的言語が多く使われている理由でもあります。

最大の欠点は、実行してみないと型エラーがわからないことです。これは、静的型付け言語であればコンパイル時に防ぐことができます。また、エラーメッセージも不親切です。

ドキュメンテーションという点でも欠点があります。
静的型付け言語の場合、ソースコードからメソッドの返り値や引数の型を読み取り、自動で多くの情報をもったドキュメントを生成することができます。
Rubyなどの動的型付け言語の場合、ドキュメンテーションのためにメソッド定義とは別にコメントとして型情報を書きます。結局型は書いてるのに型チェックだけがないという最悪の状況です。

矛盾

  • 型なんて絶対に書きたくない!
  • でも型ほしい!

すごい矛盾してますが、課題があるということは改善できるということです。
この矛盾を改善のチャンスと捉えるのは、さすがMatzといったところですね。

解決策

型を書きたくないという課題は、型推論である程度解決できます。
しかし、一般的な型推論による静的型付けではダックタイピングできません。
Rubyでダックタイピングを捨てるというのは考えられないので、ダックタイピングをできるように静的なチェックをいれる必要があります。

ダックタイピングは「振る舞い」にのみ注目する考え方でした。
振る舞いを静的に定義するものとして、例えばGo言語のインターフェイスがあります。
このような仕組みがあればダックタイピングを実現しつつ静的にチェックすることができます。

ただ、もちろんインターフェイスも書かなくていいのであれば書きたくありません。

Matzが辿り着いた答えはこれらを組み合わせた「静的な振る舞い推論」でした。
静的にアヒルを推論するというのが次世代におけるRubyの「型」だという考えです。

Soft Typing

この基調講演の中で、Matzは静的な振る舞い推論による型システムをSoft Typingと呼んでいました。

この仕組みにより、プログラマは静的型システムのメリットを享受しつつも、今までのように頭の中での考えをそのままぼんやりとプログラミングできるようになるはずです。

Soft Typingではプログラムの実行前にソースコードから型推論してチェックを行うことになります。
Rubyでは動的に振る舞いを定義することも多いため、もちろんこの方法ではカバレッジを100%にすることはできません。
しかし、たとえ80%であっても現在は0%なので全然マシです。

また、もし上手く推論できなかった場合にも、現在と同様の動的な型付けにフォールバックするだけでプログラムは動作することができます。

Matzは実行時に型情報を収集するということも考えていました。
プログラム実行時の型情報をデータベース化し、例えばGemのような外部ライブラリの型もそのデータベースから読み取り、より正確な型チェックが行えるのではないかということでした。

まとめ

いよいよ「Rubyの型」が明らかになってきて、ますますRuby3への期待が高まってきました。

MatzはRuby3の大きな改善として、ダックタイピングを維持したまま型推論による静的な型チェックを行えるような仕組みを考えていました。
まだまだ構想段階でSoft Typingという名前も変わるかもしれないということですが、Rubyプログラマとしてはかなり楽しみな機能です。

また、MatzはなによりRubyプログラマとRubyコミュニティの未来を真剣に考えているということを強調していました。
このように引っ張ってくれるリーダーがいるというのはユーザとしてとても頼もしいし、安心もできますね。

今回のRubyKaigiはRuby3の3本の柱それぞれの発表があります。
それ以外もとても興味深い発表がそろっていて、明日、明後日も楽しみです。

最後に、グッドパッチでは最先端のRubyを活用してプロダクトを支えるRubyエンジニアを募集しています!
ご興味のある方はぜひお気軽にオフィスに遊びに来てください。お待ちしています!
https://www.wantedly.com/projects/37793