比較 動的言語 vs 静的言語


結論

10,000行以上ならドメイン駆動モデルによる静的言語。
10,000行以下ならMVCモデルによる動的言語
 

注意
とても乱暴な数字ですが、イメージをつけやすくするために
10,000行とする考えを採用させていただきました。
 



表1.結論

項番 項目 静的 動的
1 開発速度(大規模) O X
2 開発速度(中規模) O O
3 開発速度(小規模) X O


 

開発速度としては、つぎのような感じで場合分けして軍配があがります。この人の記事は、使い分けも、含めて書いてくれてるのでありがたいです。

まとめ
JavaPython 両方使える人は

  • 小規模のとき Python
  • 中規模のとき
    • 開発スピード重視なら Python
    • 作り込みが必要なら Java
  • 大規模のとき Java

という風に使い分けてもいいんじゃないでしょうか。

Python と Java で AppEngine アプリを開発してみて - present

 

で、実際作り込みってどれくらいなんだろ(´・ω・`)

僕の立場を書くと、動的型付言語にメリットはあると思う、しかし構築するシステムの規模やチーム規模が大きくなるにつれてそのメリットよりデメリットが大きくなる。そしてそのメリットとデメリットのが反転する規模の分岐点は(常人が思っているより恐らくは)小さい、というものだ。具体的には10K行程度。

静的型付言語/動的型付言語のメリット/デメリットについて考えてみる - think and error

 

理由

規模が大きくなると静的言語のほうが有利になる理由は、
規模が大きくなるに従い...
2. 動的言語は、テストしずらくなる。
3. 動的言語は、リファクタリングしずらくなる。
6. 動的言語は、MVCのモデルが肥大化し、メンテナンス性がさがる。
から。
 


各論


表2.各論

項番 項目 静的 動的
1 実行速度 O X
2 テストのしやすさ O X
3 リファクタリングのしやすさ O X
4 可読性 X O
5 ドメインモデル
対応フレームワーク
O X
6 MVCモデル
対応フレームワーク
X O


 

1. 実行速度

特に、動的言語の場合、四則演算が遅くなる。理由は、演算の都度、型判定がはいるから。

 

2. テストのしやすさ

そして静的型システムは、動的型システムよりもテストの記述を少なくしてくれる。以下ではそれを示そう。

静的型付言語/動的型付言語のメリット/デメリットについて考えてみる - think and error

と、記載されているところ、以下の文章を読んでください。長いので引用は控えました。
 

3. リファクタリング

リファクタリングって何?
リファクタリングにありがちな誤解を解く
リファクタリング (プログラミング) - Wikipedia

動的言語Python 使ってますが、確かにリファクタリングしづらいかも。

データ構造を書き換えて大幅にコードも書き換えようとするときに、困りはしないけど不安になる。型が明示されてないものだからエディタ, IDE が補完してくれない。補完してくれないからこれで正しいのかな.. と。

Python は 3.5 以降、確かに型アノテーションが出てきたけど、vim の開発環境ではいい感じに補完してくれない。Pycharm ではやってくれるのだろうか...
 

4. 可読性

Ruby, Python を念頭に基本的には動的言語に軍配をあげたいと思います。理由は Ruby, Python ともに言語の設計思想として、プログラミングすることの楽しさ、読みやすさを理念に据えているからですし、実際に自分もそのように感じています。

この記事面白かったので(´・ω・`)つ
Rubyの生産性の高さはどこまで本当か? - 分裂勘違い君劇場 by ふろむだ
 

5. ドメイン駆動モデル

Resource -> Domain -> Service -> Interface の4層構造です。

ドメイン駆動モデルの動的言語フレームワーク

ドメイン駆動モデルの動的言語フレームワーク

 

6. MVCモデル

Model -> Controller -> View の3層構造です。JavaSlim3 のように静的な言語で強く MVC に沿う静的言語のフレームワークもあるようです。

MVCモデルの動的言語フレームワーク

  • Java ... Slim(GAE)

MVCモデルの動的言語フレームワーク

 

MVCモデルで規模が大きくなっちゃうと

ただ、それを忠実に実践していった結果、モデルが肥大化し
メンテナンシビリティやテスタビリティが低下する
という問題も多く指摘されています。

Railsでサービスとフォームを導入してみる話 - assertInstanceOf('Engineer', $a_suenami)

 

Django(Python) での対処の仕方。Service Layer みたいなのを作ってあげて、モデルをラップしてあげる。もちろん暫定対処で、ほんとうに大きくなったら、Spring とかへの移行を考えたりしないと行けないのかな...どうなんだろ。python - Separation of business logic and data access in django - Stack Overflow

from library.models import Book

def get_books(limit=None, **filters):
    """ simple service function for retrieving books can be widely extended """
    if limit:
        return Book.objects.filter(**filters)[:limit]
    return Book.objects.filter(**filters)

 

補足①

動的言語=MVCモデル, 静的言語=ドメイン駆動モデルという訳ではないのですが、動的言語の有名なフレームワークMVC モデルに、静的言語のフレームワークドメイン駆動モデルに沿うことが多いような気がするため、このように表記しています。

ドメインモデルに分類したフレームワークであっても、MVCモデルのように記述することもできます。例えば、Spring には Spring MVC という機能があります。また、MVCモデルのように分類したフレームワークであっても、リンク先に書かれているように Django, Railsドメインモデルのように記述することができます。
Webフレームワーク比較してみた - やさしいデスマーチ

補足②

Ruby にオプショナルで静的型付を検討したこともあるようですね。一緒に Python についても書かれたリンクもあります。
やっぱ将来Rubyに静的型は導入するのやめようと思った。 たとえオプショナルでも。| Matzにっき


アノテーション

結局ウェブアプリも大規模化してきて、型を明示するような流れになりつつあります。この記事は死ぬほど面白かったです。

注意してほしいのは、ここでいう型宣言の需要は、人間のために書く、ドキュメントとしての型アノテーションで、コンパイラに効率よくランタイムを生成してもうらための型ではありません。これを混同している人が多いですし、「高水準な、良く設計されたプログラミング言語」はそれらを区別せずにプログラマに書かせようとしてきます。(Rust などは低水準を目指しているので明示的に区別します)
ttp://mizchi.hatenablog.com/entry/2018/07/05/180219