ぽっぽこメモ太郎

短くて分かりやすい備忘録を目指しています

まつもとゆきひろ コードの世界(第2章)

先日、久しぶりに「まつもとゆきひろ コードの世界」の第2章を読み返した。
10年以上前の本だけど今でも十分勉強になることが書いてあるので、読んだことの無い方は一度読んでみて欲しい。

tatsu-zine.com

今回は「動的型付け言語のデメリットを克服する方法」について、自分の感想も交えてメモしておく。

動的型付け言語のデメリットと対処方法について

エラーの発見が実行時になる

静的型付け言語であればコンパイル時にエラーが発見できるが、
動的型付け言語の場合は実行されるまで発見できない。

対処方法

単体テストをきっちりやる。
ちゃんとテストする習慣が定着していれば、静的型付け言語のようなコンパイル時のチェックが無くてもコードの信頼性は下がらない。

感想

テストをきっちりやることはとても重要。
問題があるとすれば、みんながみんなテストをきっちりやっているとは限らない という点か。

プログラムを読解する際のヒントが少ない

静的型付け言語であれば引数や変数の型がプログラム読解のヒントになり得るが、
動的型付け言語の場合は読解のヒントになる情報が少ない。

対処方法

ドキュメントを整備する。
Ruby には RDoc という標準ライブラリが用意されていて、Ruby で書かれたソースコードからドキュメントを自動生成できる。

library rdoc (Ruby 2.7.0 リファレンスマニュアル)
RDoc による自動ドキュメント生成

感想

正直な話、動的型付け言語だから読解に困った という経験が無い。
あった方が良いのは間違いないけど、デメリットと言うほどのものなのかどうかはよく分からない。

型云々の話ではないけど、プログラム読解についてはもっと別のところにポイントがある(変数に再代入しないとか)と思う。

それよりも気になったのが、ドキュメントの自動生成について「Ruby ドキュメント 自動生成」で簡単に調べてみたが最近の情報は出てこなかった。
特に目新しい情報が無いからなのか、ドキュメントの自動生成という対処方法自体が主流じゃなくなったからなのか…。

実行速度が遅い

同様の処理を行った場合、静的型付け言語と比べると動的型付け言語の方が実行速度が遅いことが多い。
実行時の型チェックのコストも影響していると思われるが、言語処理系がインタプリタコンパイラかという部分の影響が大きい。

対処方法(ではないけど)

昔よりもコンピューターの性能が向上しているので、大抵は実行効率よりも柔軟性や生産性の方が重要。

感想

動的型付け言語のメリットである、「柔軟性」と「生産性」はとても良いと思う。
ただ、システムを開発する上ではユーザビリティを考えると実行速度もあった方が嬉しい。

この辺りは2.6で実装されたJITコンパイルがもっと実用的になることに期待する。

まとめ

動的型付け言語にはデメリットもあるが、ちゃんと対応すれば克服できる という内容が書いてあった。
自分は静的型付けと動的型付けのどちらも好きだけど、言語としてはRubyが一番好きなのでこれからもRubyを使っていきたいと思っている。