生産性について - プログラミング言語のドメイン

Other

一人ブレスト。ややカオス。

前回のはどうやら釣られただけのようですが、それでも「JavaはRubyより生産性が云々」という議論はよく聞きますよね*1。私はRubyを文法と設計思想でしか知らないので多くを語ることはできないのですが、そもそも一般論で比較する内容じゃなくね？

極端な例だと、SQLとXPathで勝負しているようなもんです。

  • SQLは(RDBの検索で)使いやすい
  • XPathは(XMLの検索で)使いやすい

上記の2つで勝負したら、明らかにドメインが直交している(かぶらない)ので不毛な戦いになることが予想されます*2。

しかし、困ったことにJavaとRubyはどちらも汎用プログラミング言語という、ドメインの分割がしにくい言語です。さらに、特徴が静的/動的型付だったり非LL/LLという(宗教的には)それなりの差異があります。

そうすると、戦いはバックグラウンドまでもつれ込みます

ここで、フレームワークという言葉を使いましたが、現在のほとんどの開発ではこのフレームワークを使っていると思います。私のフレームワークに対する理解は、

というものです。これには、2つの方法があります。

  1. 得意でないドメインは別の方法で処理し、ブリッジを提供する (S2Dao+SQL的)
    • o 問題を完全に分割できるので、分担作業がしやすい
    • o ブラックボックスがブリッジ部分だけ
    • x 問題を分割しただけなので、別ドメインの知識が必須
    • x サポート機構 (別エントリで説明の予定) が完全でない場合がある
  2. 得意でないドメインを隠蔽して得意なドメイン上でエミュレートする (S2JDBC的？)
    • o 同じ言語内で書けるので、別ドメインの知識が弱くてもいい
    • o 既存のIDEでサポートできる
    • x エミュレーションに失敗すると、直感的でなかったりする
    • x ブラックボックスが別ドメイン全体

つまり、「分割して統治する」か「侵略する」かの違いだと思います。ただ、例に挙げたS2JDBCは構文がSQLそのもので、Where句に生の文字列リテラルを使ったりするところがあるので、ちょっと例としては適切でなかったかもしれません。

ちなみに私はブリッジの方法が好きです。Javaでコンパイラを書くときも

  • パーサをJavaで書く気にならないので、パーサジェネレータを使ってJavaを生成する
  • データ構造をJavaで書きたくないので、DSLを作ってJavaを生成する
  • テストデータをJavaで構築したくないので、DSLを作ってインタプリタを使う

といった感じに「DSL+ブリッジプロダクト」という形式で、Javaが不得意なドメインでは積極的にDSLを使うことにしています。総合的な生産性についてはよく分かりませんが、少なくとも書いててげんなりすることがありません。

DSLについての考察は、また別のエントリで。

*1:聞きますよね？

*2:データ構造のブリッジ作れば無理やりかぶせることはできるでしょうけど