DSLを使用する利点の科学的証拠を探している

Question

グレッグ・ウィルソンの講演「証拠のビット」 （ http://www.slideshare.net/gvwilson/bits-of-evidence -2338367 ）では、Martin FowlerがDSLを使用する利点として進歩したという次の主張の背後にある証拠の欠如について説明しています。

＆quot; [ドメイン固有の言語を使用する]には、主に2つの利点があります。最初の最も簡単な方法は、プログラマの生産性の向上です。 2番目は...ドメインエキスパートとのコミュニケーションです。 -Martin Fowler、 IEEE Software July / August 2009

質問：プログラマーの生産性の向上またはDSLを使用することによるドメインの専門家とのコミュニケーションの向上の証拠を提供する実証研究はありますか？

DSLを構築している多くの人々は、「なぜDSLを構築しているのですか？」に対する合理的な答えを提供できません。 ＆quot; DSLはなぜ優れたオブジェクトモデルよりも役立つのか？＆quot;

「かっこいいし、他のみんながやっているから」「たくさんやっているよ」 -これは合理的な答えではありません。

DSLは少なくとも時には役立つと思いますが、「銀の弾丸」になる可能性は低いと思います。それを無差別に使用する必要があります。経験的研究に基づいて、DSLをいつ使用するべきか、使用すべきでないかを説明する科学的な研究をいくつか見たいと思います。

Answer 1

ちょっとグーグルで、いくつかの興味深い論文を見つけました：

実際のドメイン固有の言語：成功要因に関するユーザー調査

ドメイン固有言語とオブジェクト指向フレームワーク：金融工学の事例研究

設計後のドメイン固有言語埋め込み：ケースソフトウェアエンジニアリングドメインでの学習

そして、Google Scholarから始まるより良い参考文献を見つけることができると思います...

Answer 2

DSLが何であると考えるかに依存します。

たとえば、cssはDSLですか？そう思うと、HTML 3ではアレンジメントにテーブルを使用し、現在は柔軟性がなかったので、明らかにページのスタイルを簡単にすることができます。

学生が原子記号（H20）のみを使用して分子を設計できるようにDSLを使用している場合、記号と種類を指定すると分子構成をすばやく確認できるため、コーディングを自分で行うよりも簡単ですボンディングなど。

なんらかの方法を示す論文は知りませんが、対象読者がプログラマーでない場合はDSLが理にかなっているので、会計士が用語を使用するのではなく、用語を使用してアプリケーションを作成することができます開発者に要件を与えます。

DSLは長い間存在していましたが、現在では人気が高まっているため、いつ使用するのが最適で、実際に有害であるかについて、良い使用と悪い使用の例がいつあるかがわかります。たとえば、DSLで医療監視ソフトウェアを作成することはありません。

Answer 3

「科学」の前提全体この場合、疑わしいです。 「再現可能」、「コントロール（グループ）」の基準を保証する方法はありません。実証研究に必要です。

Answer 4

ビジネスプログラミング全般において、何かが使用される前のメリットについての深刻な実証的研究はありません。 SQL、オブジェクト指向言語、関数型言語、ガベージコレクションなどであるかどうか

これらのことは、時間の経過とともに市場によって決定される傾向があります。

これが事実である理由は、おそらく2つの理由の組み合わせです。 1つは、優れた経験的研究を得るのに非常に費用がかかり、経済的な観点から試してみるだけではるかに安くなることです。もう1つは、各状況が異なるため、経験的研究は、DSLを使用する場合と使用しない場合を適切に比較するために、研究中の問題を非常に狭く制限することから開始する必要があり、研究の最終結果はそれほど大きくない選択された特定のタイプの問題を超えて役立ちます。

私は経験から安全なことを言うことができると思います。何も特効薬ではなく、アプローチの正当な理由を主張することで解決策が改善されます。あなたはそれをやっている、あなたはあなたがそれを正しくやっているかどうかわからないだろうし、全体の恩恵を見逃してしまうかもしれない。

Answer 5

これは賢明な質問であり、「DSLとは何か」などの定義上の問題があると思います。バズワードが「ホット」になるとマーケティングの機会になり、基礎科学がある場合はそこから離婚します。

数年前に、私はプログラム（Building Better Applications、ISBN 0-442-01740-5、長い間絶版）を書き、プログラムだけでなくプログラマーのパフォーマンスを調べようとしました。情報理論を使って見ようとしました。

保守性の大まかな尺度を思い付きました。問題は誰かの頭の中の知識構造として存在し（AIの人にはそういう問題はありません）、その解決策は機械によって処理されるテキスト構造として存在します。私が見ているのは、これら2つの構造の関係です。たとえば、精神的な問題の説明に変更が発生した場合、それをプログラムテキストに正しく転送するには、ソースコードの変更がいくつ必要ですか。それを測定する簡単な方法は、前と後のコードを比較することです。さて、可能性のある変更のスペース全体の測定値を平均し、平均値が低いほど、ソースコードの保守性が高くなります。

私の論文では、その手段によって、コードのメンテナンス性が高いほど、ドメインのメンタルモデルに似てくるようになるため、「問題指向」と呼ぶ方が合理的です。以上の「ドメイン固有」。 このようなコードに気付いた特徴の1つは、問題の解決策ではなく、問題のステートメントである傾向があることです。ソリューションは言語ではなく、言語の実装、サブ構造にあります。 これは、「宣言的」という概念との直接的な合意ではありませんが、エコーです。 vs.「命令的」言語。

だからあなたの質問に答えようとするとき、私は人々が「DSL」を望んでいるかもしれないものから逃げましょうつまり、少なくとも中程度に明確な定義を見て、代わりに見てください。

そのアイデアの開発の一環として、私はいくつかのテクニックにつまずきました。そのうちの1つは Differential Execution 。UIのコーディングに優れた保守性を提供すると思われ、またソースコードのサイズを約1桁削減します。私の理論では、それはDSLの成功例です。

私は、メンテナーが学習曲線を登らなくてもメンテナンス性が達成できると主張していません。本当の保守性は、プログラマにとっては理解しにくいかもしれないが、一度把握すれば望ましい価値を持つものを学ばなければならないという代償を払って来ると思います。

Answer 6

言語学者のSaphirとWorfから、言語の文法的な特徴が思考に影響を与えることがわかります。DSLを作成すると、ドメイン固有であり、おそらく汎用性が低くなると考えられます。汎用プログラミング言語がマシンから抽象化する傾向があるのと同様に、抽象化がすべてです。そのため、命令セット、アドレッシングモード、レジスタサイズなどよりもアルゴリズム、構造、設計に重点を置くことができます。

Answer 7

必要な範囲で誰も研究を行ったかどうかはわかりません。 私の経験では、DSLはそもそも作成するのにコストがかかる可能性があります（おそらく、同じことをするための単純なオブジェクトモデルよりも2倍以上の労力がかかります）。 しかし、作成された開発者は、モデルよりもDSLの方が迅速に処理できるため、すぐにメリットが得られます。

問題の問題は、すべてのDSLを同等に扱っていることです。実装が簡単なものもあれば、より困難なものもあります-Fluent Interfaces / Internal DSLを実行する場合でも、外部DSLを実行する場合でも、実装に異なる時間/コストがかかります。

そのような研究ではカバーされないかもしれない主な利点の1つは、DSLがコードの表現と実装につながる容易さです。また、他の人がコードの意図を簡単に理解できるようにします-ソフトウェア開発ライフサイクルのメンテナンスフェーズはSDLCの非常に大きなコンポーネントであるため、DSLの作成で最初に失われるよりもはるかに大きなメリットにつながる可能性があります。