動的型付け

私は、プログラミング言語における静的型付けと動的型付けの論争について、何かを寄稿することを長い間ためらってきました。これは、人々が耳を傾けるよりも議論に駆り立てられるような、感情的な話題の一つです。しかし、何度か質問を受けたので、私自身の経験を寄稿します。誰かを何かで納得させようとしているわけではありませんが、誰かがその中に何か考えるきっかけを見つけてくれればと思います。

私が最初にこの区別を意識したとき、私はすぐに静的型付けの利点に納得しました。私の初期のプログラミング経験は、型付けが制限されていたBasicとFortran IVでした。その後、Pascalに移り、すぐにPascalが私がプログラミングを楽しむ言語になりました。

オブジェクト指向に移行したとき、私はC++とSmalltalkの両方で作業しました。しばらくの間、私はSmalltalkの動的型付けを不利な点だと考えていました。プラットフォームの素晴らしい生産性に対して支払うべき小さな代償だと。

私がこの考えに疑問を持ち始めたのは、ある程度の規模のSmalltalkプロジェクトに関わったときでした。静的型付けの一般的な議論は、見つけにくいバグを捕捉することです。しかし、自己テストコードが存在する場合、静的型付けで捕捉されるであろうほとんどのバグは、テストによって同じくらい簡単に発見されることがわかりました。テストは型エラーよりもはるかに多くのものを見つけるため、静的型付け言語でも動的型付け言語でも必要でした。したがって、静的型付けはほとんど利点を与えません。

他の人がこの発見の道筋をたどるのを見るのは興味深いことでした。ロバート・マーティンとブルース・エッケルは、C++からPythonに移行した際に同じことを発見しています。

しかし、バグの捕捉だけが静的型付けの利点ではありません。私が最近より顕著だと感じているのは、その他の利点の一部です。

ある日、私はよく書かれたRubyのコードを理解しようとしました。パラメータの型情報がないことが、非常に困難であることがわかりました。私は「ここで正確に何を持っているんだ？」と自問し続けました。Smalltalkでは、この問題をそれほど感じませんでした。その理由は2つあります。優れた環境のおかげで、デバッガーを起動して何を持っているかを簡単に確認できること、そして2つ目は、引数に型にちなんだ名前を付けるのが一般的な慣習であることです。（Smalltalkは位置パラメータではなくキーワードパラメータを持つため、キーワードはパラメータが果たす役割を説明するため、これは理にかなっています。）

静的型付けが役立つもう一つの領域は、プログラミング環境がはるかに役立つようになることです。ここでの啓示（多くのことと同様に）はIntelliJでした。このようなIDEを使用すると、型システムが本当に役立っていると感じました。オートコンプリートのような単純なことでさえ、静的型によって大幅に助けられますし、最先端のIDEはそれ以上のことができます。

それにもかかわらず、SmalltalkやRubyのような言語でプログラミングすることには、特別な満足感があります。そして、それは動的型付けと大いに関係があると思います。キャンプ4コーヒーでブルース・エッケルと話していると、静的/動的型付け論争で最も不満なことの一つは、動的型付け言語で作業する利点を言葉で表現するのが非常に難しいという点で、二人とも合意しました。私がIntelliJではなくemacsでRubyを使用しているときでも、その環境でプログラミングしているときは、なぜか物事がよりスムーズに進むように感じます。（もちろん、Smalltalkには言語と素晴らしいプログラミング環境の両方があります。）

この理由の一部は、言語の簡潔さによって、言語内でドメイン固有言語を作成するなどが可能になることだと思います。JavaやC#のような言語を使用していると、何が起こっているのかを理解するために、テキストを飛ばす必要があると常に感じます。

理由が何であれ、このより良い流れは、たとえ劣悪な環境であっても、より楽しいプログラミングにつながります。プログラマーが楽しんでいるかどうかなど、あまり重要ではないと思うかもしれません。しかし、私はプログラミングを本当に楽しんでいるので、気にしています。私は、自分の思考と実行コードの間にある無駄なことに時間を費やすことなく、迅速に物事を実行することを楽しんでいます。私にとって、それがSmalltalkとRubyの喜びであり、個人的なプロジェクトでこれらを選択する理由です。そして、楽しさにはビジネス上の価値があります。結局のところ、モチベーションはプログラマーの生産性における主要な要因だからです。