はじめに
Ruby対Scala, 動的型付言語は使い物にならないという興味深いWeb記事を読みました。
はじめに断っておきますが、おいらは別にRubyが嫌いなわけではないですし、「動的型付言語は使い物にならない」と思っているわけではありません。
そもそもRubyや動的型付言語での大規模開発経験がないので、良し悪しを正当に評価できません。
ましてやScalaなんて文法すらまともに知らないので、Scalaバンザイ!なんて言えるわけもありません。
ただ、おいら自身も「Rubyとかで開発したらこんな問題が起きるかも〜」と想像していたことが、結構そのまま書かれていたのが印象的でした。
これまで中規模〜大規模なシステムはJavaやC#で開発してきたので、IDEやコンパイラの支援はたっぷり受けてきました。
Ruby on Railsで開発してみたい!という憧れはありますが、IDEの入力補完やリファクタリング機能、コンパイラによる構文チェックや型チェックがなくなると思うとかなり不安だったりします。
動的型付言語 = スクリプト言語?
ところで、動的型付言語はしばしば「スクリプト言語」と呼ばれることがあります。
で、「スクリプト」はおいらの中で「手作業でやるには面倒な処理を自動化してくれる簡易プログラム」というイメージです。
しかも、スクリプトを書く人は自分で自分のために小さなコードを書くので、やっつけ的なコードでもいいから手軽に書きたいと考えます。
わざわざ重たいEclipseやVisual Studioを起動するより、テキストエディタでさらっと書いて、実際に動かしながらデバッグする、そんなコーディングスタイルの方が合っています。
実際、おいらもVBScriptやJScriptを使ってそんな便利スクリプトを時々作ったりしています。*1
なので「動的型付言語 = スクリプト向け言語」と考えると、「自分で自分のために書く、多少のバグは許される小さなプログラム」には向いていても、「たくさんのプログラマが自分以外の顧客のために書く、バグのない大規模プログラム」には向いていないんじゃないかと思うことがあります。
動的型付言語の方がテストに有利?
また、静的型付言語であればコンパイラが検出してくれるエラーも動的型付言語では実行するまで発見されないがゆえに、自動化されたテストがないと精神的に非常に不安になると思います。
もっとも静的であれ動的であれ、自動化テストは習慣として作成すべきですし、動的型付言語の方が「実行しないと不安、だからテストを書こう」という強い動機をプログラマに与えてくれるかもしれません。
実行速度については今回無視
元ネタの記事では実行速度についても静的型付言語の優位性を述べていますが、この点については個人的にはあまり気にしていません。
仕事柄、そこまで高パフォーマンスを要求されるシステムを作る機会もないですし、静的型付言語であってもヘタなロジックを書けば遅くなるからです。また、ボトルネックがデータアクセスなど言語以外の部分に存在することも良くあります。
実際に作ったわけではないので断言はできませんが、同時アクセスがそれほど頻繁に発生しない社内システム程度であれば、動的型付言語であっても十分なパフォーマンスが出るんじゃないかなあと予想しています。
静的型付言語のダメなところ
ただ、おいらはずっとJavaやC#をメインで開発してきましたが、静的型付言語にも不満はあります。
それはIDEの重さとコンパイルの遅さです。
最新のIDEはその便利さと引き換えに非常に重いです。
爆速なPCをホイホイと買い与えてくれるリッチな職場ならいいですが、前の会社も今の会社も「もっと速いマシンが使えたらなあ」と妄想するばかりです。
IDEを起動するまでに時間がかかったり、メモリの使用量を気にして他のアプリを閉じたりするのはストレスが溜まります。
また、システムの規模がある程度大きくなってくるとコンパイルの時間もだんだんと伸びてきます。
テスト駆動開発ではコーディングやテストの実行を頻繁に繰り返すので、毎回コンパイルで5秒以上待たされたりすると非常に非効率です。
Railsみたいな動的型付言語を使ったシステム開発への憧れは、このIDEの重さとコンパイルの遅さに対する反動だったりします。
エディタでサクサクコードを書いて、即座にテストを実行!みたいなことができるんじゃないかと期待しているわけです。
動的言語ならではのメリット?
また動的型付言語は柔軟性が高いので、その柔軟性を活かしたプログラミングテクニックも活用できるはずです。
まあ、おいらは動的型付言語の達人ではないので、目からウロコな具体例を示すことはできないんですが・・・。
でもRailsみたいなフレームワークをJavaやC#で作ろうとしたら、きっとRubyより大変なはず・・・ですよね?
動的型付言語がうまくいく場合(推測)
元ネタでは「巨大なソフトウェア作成では、動的型付言語は使い物にならない」と結構過激な発言が飛び出しています。
しかし冒頭でも述べたようにおいら自身は使い物にならないとは思っていません。
動的型付言語でも使い物になると思います。うまくいけば静的型付言語以上に速く作れるかもしれません。
ただ、そのためには「スキルの高い少数のプログラマで、アジャイル開発を採用した場合」という条件がつくんじゃないかな〜というのがおいらの妄想です。
要するに、いいコードを書けるメンバーがコミュニケーションを密に取りながら開発すれば、動的型付言語のデメリットは克服できると思います。
そして静的型付言語にはない動的型付言語のメリットを活かせば、静的型付言語の生産性を超えられるんじゃないかと予想しています。
静的型付言語なら完璧、か?
そうなると今度は反対に、「静的型付言語を使うとスキルの低い大人数のプログラマで巨大なソフトウェアを開発ができるのか?」という変な疑問が出てきます。
それはそれで実現しなそうですよね・・・。
ただ個人的な経験として、ヘタクソなコードでもコンパイルが通るなら少なくとも構文エラーはないんだろうなということが確認できますし、IDEの機能を使って変数やメソッドの定義にジャンプしたりできるのはコードを解析する上で便利だったりします。
そういう意味では動的型付言語よりも多少扱いやすくなるのかもしれません。あくまで「多少」だと思いますが・・・。
おわりに
というわけで、よく分からない個人的な動的型付言語 vs 静的型付言語論を繰り広げてみました。
繰り返しになりますが、おいらは動的型付言語での大規模開発経験がありません。なので経験に基づいた比較はできません。
また、Rubyや動的型付言語が嫌いなわけでもありません。むしろもっと仲良くなりたいぐらいです。
正直言って、どっちがいいとかよく分からないですし、たぶんどっちが良いかはケースバイケースだと思います。
最後に今回の話に関連しそうな、昔書いたエントリを紹介しておきます。
特に「ダメエンジニアの使い道」については、動的派、静的派を問わず必見かもしれません。(おいらの戯れ言ではなく、Matz先生のお言葉が、です)
2011.9.15 追記
昨日はなんかtwitterのタイムラインに動的、静的といったキーワードがやたら登場する一日でした。
その中でMatz先生ご自身による興味深い考察があったので、ここに転載させてもらいます。
なんか静的言語賛成派のうち、「実行性能」、「コンパイル時型チェック」、「多人数開発」などに幻想をいだいている人が結構いそうな気がする。もちろん、ちゃんとしたトレードオフを考えて静的型を正当に評価している人もいるけど
— Yukihiro Matsumoto (@yukihiro_matz) September 14, 2011
特に「開発者が多人数で玉石混交な環境では動的言語でまっとうなソフトを開発できない」という主張を見ると「静的言語でも無理だろ」と突っ込みたくなる。それとも私が知らないだけでJavaとかだとそういう環境でも「良いソフト」が開発できたりするのかな。
— Yukihiro Matsumoto (@yukihiro_matz) September 14, 2011
私が理解している限り、「良いソフトウェア」を開発するためには「小さいチーム」と「優秀な開発者」が最重要で、それらの欠如をIDEやら静的型言語やらで埋めることはできるというのは幻想。動的型言語は最初からそんな幻想を提供しない
— Yukihiro Matsumoto (@yukihiro_matz) September 14, 2011
あ、「埋めることはできない」ってだけで、「メリットがない」って意味じゃないですよ。
— Yukihiro Matsumoto (@yukihiro_matz) September 14, 2011
@yukihiro_matz 役には立つ(ここまでは事実に基づいて話ができる)がそれですべての問題が解決する(ここが幻想)わけではないと言うことでしょうかね。静的型づけも同じくで役に立つ場合があることは嘘ではないが、それで全て問題が解決したと思う部分が幻想のはず。
— 椎路ちひろ (@ChihiroShiiji) September 14, 2011
@ChihiroShiiji 完全に同意します。「動的言語は使えない」の裏には「静的言語なら使える」という仮定があるわけで、その仮定が「幻想」に基づいていればFUDです。仮に私が「静的言語は要らない」とか言えば、それも「幻想に基づいたFUD」でしょうね。
— Yukihiro Matsumoto (@yukihiro_matz) September 14, 2011
*1:仕事はほとんどWindows環境なので、VBScriptやJScriptの登場頻度が高いんです。。。